OctaneRender for Modo (Windows) 1.52 [STABLE]

[face_off]

Re: Limitations/Warnings - I have added detection of a lot of limitations, and added them as warnings, and these limitations are also in the manual. So if in doubt, check the Modo Event Log (from the next version - available in the next day or so). I can easily modify/enhance/etc this over time if people identify issue that need a warning. I might even add an "Expect Mode" in the Preferences which if OFF pops a dialog saying there were warnings in the Event Log.

Re: Support for material assignment by Selection Set - I put this to the Modo devs, and they have got back to me with a potential solution. However, I'm not sure it is viable for Octane, it will take more memory, and is not trivial to implement, so I will put this on the back-burner for the time being and re-visit once everything is done in a month or two.

The Octane viewport in Preview mode doesn't seem to respect either the horizontal or vertical FOV of the MODO render.

You currently need to have the Modo camera -> Film Back -> Film Fit set to “Overscan”? I will be looking at a solution for this, but in summary, if you are not in Overscan, Modo is adjusting the "fov" when rendering, but not adjusting the "Angle of View" property, so the plugin cannot easily pickup the "fov" to use.

Can you tell me, is it expected that I should have to create overrides for most materials?

If the default "on the fly" material conversion is working for a particular material, there is no need to add an Octane Override.

I was trying to do a test for each of the basic types of materials and could not get metal to work. The IOR is inaccessible unless the shader is transparent, and Octane requires the IOR on glossy materials to make metallic shaders?

If you feel the plugin is not converting the material correctly, let me know the conversion parameters (ie. which Modo properties covert to which Octane material pin values) and I will code accordingly. The current material conversion rules are in the manual http://render.otoy.com/manuals/Modo/?page_id=35. For a metal material, you will probably want an Octane glossy with a hgiher than default "index". Check the LiveDb for Metal material samples.

Also can we please have a reset zoom button? And a resize window to fit render size?
The render window is so frustrating to inspect the image with, that I simply avoid navigating in it.

Can you provide more details pls? I'm not sure which "zoom" you are referring to. And which "window" do you mean? Is "render window" the Modo render window, Modo preview window or Octane Viewport?

Thanks

Paul

[cakeller98]

Paul - You're AWESOME!

Render Window:

1) Zoom Reset Button to reset the zoom of the render window to 100%
2) When Resetting the zoom as above, it'd be nice if the window size (frame) was automatically resized to fit the render size. (otherwise you have to resize the window to reveal the entire image.

It often just feels finicky to have to mess with re-sizing the render window.

Also is the render window's zoom limited to power's of 2? feels very coarse when zooming in and out.

Anyway thank you so much - all your responses make me HAPPY as a clam.

[face_off]

1) Zoom Reset Button to reset the zoom of the render window to 100%
2) When Resetting the zoom as above, it'd be nice if the window size (frame) was automatically resized to fit the render size. (otherwise you have to resize the window to reveal the entire image.

1) Resetting the zoom is easy to implement, but resetting is always 2 mousewheel rolls away - and the Viewport indicates what your current zoom level is - so it adding another control to reset the zoom going to make your workflow faster?
2) Setting the Viewport window size to the render size can be hazardous, because if you are rendering to a resolution of 5000 x 5000, the viewport will fill your screen and may prevent access to the other windows. I've had a few support issues with the Viewport size being too big on other plugins, so a little nervous about implementing this. But is people things it's important, it can be done - but you would need to provide the rules for how the plugin would handle the situations where the Viewport is too big, off the screen, etc.

Paul

[cakeller98]

1) Zoom Reset Button to reset the zoom of the render window to 100%
2) When Resetting the zoom as above, it'd be nice if the window size (frame) was automatically resized to fit the render size. (otherwise you have to resize the window to reveal the entire image.

1) Resetting the zoom is easy to implement, but resetting is always 2 mousewheel rolls away - and the Viewport indicates what your current zoom level is - so it adding another control to reset the zoom going to make your workflow faster?
2) Setting the Viewport window size to the render size can be hazardous, because if you are rendering to a resolution of 5000 x 5000, the viewport will fill your screen and may prevent access to the other windows. I've had a few support issues with the Viewport size being too big on other plugins, so a little nervous about implementing this. But is people things it's important, it can be done - but you would need to provide the rules for how the plugin would handle the situations where the Viewport is too big, off the screen, etc.

Paul

Understandable.

I'd like to propose something different than what I had suggested before. You're right - it's awkward to have the app resize the window, I guess.

However what about the following controls:

• 1:1 - resets the zoom to 100% and puts the center of the image in the center of the viewport.
• Frame Image - resets the zoom so that the entire image is completely shown within the viewport.
• Frame Region - resets the zoom so that the region of interest is completely shown within the viewport (default region of interest = whole image)
• Select Region of Interest (default is entire image)

the Frame Region and Select ROI will be good for now for examining the rendering as it's happening. However they will become critical features once Octane supports region rendering.

So the viewport anchor should be the center of the viewport
In the case that a 1:1 command is issued, a 5000x5000 image shown at 1:1 would have the image's center pixel in the center of the viewport... really who wants to look at the upper left corner of their rendering? - not i

My $0.02

[face_off]

However what about the following controls:

1:1 - resets the zoom to 100% and puts the center of the image in the center of the viewport.
Frame Image - resets the zoom so that the entire image is completely shown within the viewport.
Frame Region - resets the zoom so that the region of interest is completely shown within the viewport (default region of interest = whole image)
Select Region of Interest (default is entire image)

Thanks for the video you PM'd me. I'll respond here to avoid answering things twice

There are some challenges implementing this sort of viewport functionality. These are:

1) The viewport needs to be able to allow the user to "pick" the focus, material, white balance. Then the plugin needs to be able to determine the exact point the user clicked on. The calculation is OK if the zoom is a power of 2, but once you start fitting render images to viewports, this calculation will not be straightforward. I'm sure you will agree that the "pick" functions are critical to the plugin, so I cannot implement something which puts these at risk.

2) The viewport zoom/pan is implemented in with the basic Windows bitmap functions. These provides some very basic zoom functions, which work very well at powers of 2, but once you use other zoom factors, there is a lot of artifacts on the resulting bitmap. The solution to this is to use a different library - but this will mean rewriting a lot of what is current working well.

3) For all the functionality request above, I need to implement it in Windows, then implement in OSX (which is a completely different Viewport codebase, using different libraries, etc), and then I need to implement it in Linux, which is again a complete separate set of windows libraries. So the code needs to the written and tested 3 times, not just once. So it is a lot of work! Already the viewport functionality on the OSX version is different to that on Windows, because OSX had some limitations I couldn't get around. The most robust, bugfree plugin will come from having shared code between Windows, OSX and Linux - so when the plugin needs separate code for each OS, it also presents addition support load.

So you can see, the viewport zoom enhancements are not straightforward to implement. I am happy to look at them at a later date, but for the moment would rather focus on static and proxy meshes, procedural texturemap support, etc.

Paul

[face_off]

I have posted an "interim release" - in order to get a version out to assist people having authentication issues. A lot of the functionality in this release has not been tested to the level I normal do, so use with caution.

1.33.0.45
- Animation: You can now specify the file save format and filename prefix in the Modo preferences. The frame number rather than the frame time is now appended to the filename
- Progressive Save: You can specify that the current render will be saved at regular intervals. Set this up in the Modo preferences->Octane section
- Change Lock button has been added (next to the Preview button). This stops all changes from reaching Octane when activated, so the render should not restart regardless of the changes you make. Deactivating this button will mean your Octane scene may have not received some updates, so it is recommended that you Refresh. This button status in not remembered between Modo sessions. For this initial release, pls do not rely on this function, since some changes may not have been trapped using this button
- Added support for static meshes. Untested at this stage - so there may be issues
- Many changes to the geometry loader to better handle loading and live updating of meshes, mesh instances, replicators, replicator instances, static meshes and static mesh instances. Pls report any issues you find.
- Added logging to the Modo Event Log to help track authentication issues

Download link for those wanting to try this release is http://render.otoy.com/customerdownload ... _64bit.exe

I will be away for 2 days, so may take longer to respond to questions than normal.

Paul

[face_off]

I have refreshed the installer at the top of this thread to roll up a couple of small releases. The latest release is now 1.33.0.46.

1.33.0.46
- The Octane Viewport buttonbar now opens when you open the Viewport, and follows the Viewport
- Some buttons removed from the OctaneRender Setup button bar and placed on the Viewport button bar (ie. export, reload texturemaps)
- Added new Viewport buttonbar button to open the OctaneRender Setup Window
- "Authenticating Octane" popup message changed to "Loading Octane" to avoid confusion.
* Due to some of the changes to the Viewport toolbar and OctaneRender Setup windows, if you have previously edited these layouts, you will need to delete your Modo701.cfg (and re-authenticate the plugin).

1.33.0.45
- Animation: You can now specify the file save format and filename prefix in the Modo preferences. The frame number rather than the frame time is now appended to the filename
- Progressive Save: You can specify that the current render will be saved at regular intervals. Set this up in the Modo preferences->Octane section
- Change Lock button has been added (next to the Preview button). This stops all changes from reaching Octane when activated, so the render should not restart regardless of the changes you make. Deactivating this button will mean your Octane scene may have not received some updates, so it is recommended that you Refresh. This button status in not remembered between Modo sessions. For this initial release, pls do not rely on this fucntion, since some changes may not have been trapped using this button
- Added support for static meshes. Untested at this stage - so there may be issues
- Many changes to the geometry loader to better handle loadig and live updating of meshes, mesh instances, replicators, replicator instances, static meshes and static mesh instances. Pls report any issues you find.
- Added logging to the Modo Event Log to help track authentication issues

1.33.0.44
- The Modo Image map "Invert" property now translates to the Octane material, so transparency map settings should now much better convert form Modo to Octane
- The Stencil Effect is now support, and treated identically to the Transparency Amount Effect
- Fixed issue where update the Modo Environment IBL was popping an Octane error
- Fixed issue where changing a Modo Shader Tree image map NOT placed in a material group was not propagating changes to the Invert or Gamma settings
- Changed the Authenticate window to stay open (so it's open if you taskswap out of Modo to get your OctaneLive details)
- Fixed the situation where sometime the "Activate" button would be enabled even if the plugin had already been activated
- Octane Mesh nodes are now named according to their respective Modo Mesh Item name, and Materials are named according to the Octane Override name - which will assist editing the scenes that have been exported to Octane Standalone
- Improved the "auto refreshing" for mesh items parented to other mesh items, or which are part of locators or group locators
- The plugin now supports Replicators with "Include Child Items" ticked
- Fixed issue where dragging an IBL image to an Environment would not update the Octane environment
- Added the following to the Limitations part of the manual : Only material assignments to polygons by “Material” Polygon Tag Type is supported. Material assignments by “Part” and “Selection Set” Polygon Tag Types are not supported. A warning is added to the Modo Event Log when a material is converted with a Selection Set
- If the Shader for a material has the Alpha Type set to Shadow Catcher, the material will be converted to an Octane Diffuse with Matte enabled (to become a shadow catcher material). NOTE: The Octane environment needs to have Importance Sample ON for this to work.
- Fixed crash resulting from resizing the Viewport
- Replicators with a Prototype set to a Group are not supported - and a warning will be added to the Modo Event Log when this is detected. Replicators must have a prototype set to a Mesh item.
- Removed the Maximize box from the Viewport (since that invalidates the Octane resolution in Preview mode)
- Changed Viewport window logo to the Octane logo (Windows version only)

Paul

[Dmi3ryd]

thanks for update Paul!

[face_off]

I am tagging the latest build 1.33.0.46 (above) as the STABLE release (so it will be the version people download from the Store). I will start a new thread for TEST releases 1.33.0.47 onwards, and will post here when the next TEST release is ready.

Paul

[funk]

face_off: I just installed the plugin and noticed it also tries to load in 601 with an error. You can make the following change to index.cfg so it only loads in 701+

Code: Select all

<configuration kit="OctaneRender" version="1.33.0.46" and="rel]601">

This is just saying "release is greater than 601". More info here: http://sdk.luxology.com/wiki/Kits under "Defining a Kit"

You could even be more specific and use build numbers since your plugin requires a minimum 701 sp4 (build 66614)

Code: Select all

<configuration kit="OctaneRender" version="1.33.0.46" and="ver]66613">

Many of us still have older versions and SPs installed. These changes will prevent any annoying errors popping up