OctaneRender for Modo (OS X) 1.55 [OBSOLETE]

[riggles]

Couple of oddities with 1.53.1.67, and I'm guessing it's coming from the unfinished viewport navigation code?

When clicking on the autofocus, material select, and white balance select buttons, I get a dialog box asking if I want transfer the Octane camera position to MODO. Probably should only be getting that dialog if I've got viewport navigation enabled (which I don't) and after having moved the Octane camera around in the viewport (which I haven't). Also, saying 'No' to the dialog box still causes my render to restart.

[face_off]

When clicking on the autofocus, material select, and white balance select buttons, I get a dialog box asking if I want transfer the Octane camera position to MODO. Probably should only be getting that dialog if I've got viewport navigation enabled (which I don't) and after having moved the Octane camera around in the viewport (which I haven't). Also, saying 'No' to the dialog box still causes my render to restart.

Yes - this is now fixed in the next release, which I will post today.

Paul

[face_off]

I have refreshed the installer at the top of this thread with:

1.53.1.69
- Resolved issue where texturemaps were being converted from the Modo Shader Tree to the Octane material even when they were below the Modo Material in the Shader Tree
- Fixed issue where moving items into the root of the Shader Tree was not refreshing all materials
- Fixed issue where changing the visibility of a Modo light which has had an Octane light created for it was not changing the visibility of the Octane emitter geometry
- Fixed crash resulting from Undo'ing after creating an Octane Override
- Fixed crash resulting from Undo'ing after deleting an Octane Override. This situation is not handled flawlessly, and it is possible to confuse the plugin, by partially undo'ing the Override delete, and then creating another Override - but the crash should be resolved

1.53.1.68
- Fixed Viewport Navigation popup erroneously displaying when changing "Pick" modes

Paul

[riggles]

In Standalone, when the render is paused, making changes to materials even in heavy scenes is fine. In the plugin, making any change to a material override causes my system to hang while it applies the change. It seems to take as long as the whole scene takes to load into Octane render when first starting the render. I'm working on a heavy scene currently, so making one material change (again, while the render is paused) still gives me a beach ball for a minute or two while it applies the change. Seems like this shouldn't be happening until I restart the render. If this is how it's supposed to work, that makes it pretty hard to use with heavy scenes.

[face_off]

In Standalone, when the render is paused, making changes to materials even in heavy scenes is fine. In the plugin, making any change to a material override causes my system to hang while it applies the change. It seems to take as long as the whole scene takes to load into Octane render when first starting the render. I'm working on a heavy scene currently, so making one material change (again, while the render is paused) still gives me a beach ball for a minute or two while it applies the change. Seems like this shouldn't be happening until I restart the render. If this is how it's supposed to work, that makes it pretty hard to use with heavy scenes.

In Standalone, only one pin of one node is being updated when you make a change. But in the plugin, you might make a change to the Modo Shader Tree which actually impacts all Octane materials in the scene - which in this case causes all materials to be reloaded. If your materials all have Octane Overrides - then changing a node pin value (like the diffuse color) should only update that pin so should be as fast as Standalone. But if you update the diffuse color on a Modo material, all scene materials are refreshed.

So in summary, at the moment, adding Octane Override will result when you update materials the update will be instant. Whereas on-the-fly conversion from Modo Materials means updating is slower.

I will investigate if the plugin can detect if the render is paused and the "commit" the material changes in a fashion which is much faster.

If you have a scene which demonstrates this problem - if you send it to me it will make investigating the above improvement easier for me.

Paul

[riggles]

In Standalone, only one pin of one node is being updated when you make a change. But in the plugin, you might make a change to the Modo Shader Tree which actually impacts all Octane materials in the scene - which in this case causes all materials to be reloaded. If your materials all have Octane Overrides - then changing a node pin value (like the diffuse color) should only update that pin so should be as fast as Standalone. But if you update the diffuse color on a Modo material, all scene materials are refreshed.

So in summary, at the moment, adding Octane Override will result when you update materials the update will be instant. Whereas on-the-fly conversion from Modo Materials means updating is slower.

I will investigate if the plugin can detect if the render is paused and the "commit" the material changes in a fashion which is much faster.

If you have a scene which demonstrates this problem - if you send it to me it will make investigating the above improvement easier for me.
Paul

After I finish this job over the weekend I can can email you the whole scene (its about 12M non-instanced faces). I am using Octane overrides for all materials, but when changing the node structure of one override, it takes a very long time to apply.

Also, when turning off visibility of a group (in the Groups list) the items in the group still get loaded into the Octane viewport and get rendered. They're shown as turned off in the Item List, too, but still render. If I turn the group visibility back on and then turn the items off individually in the Item List, they are removed from the render.

EDIT: Also, Loading the scene onto the GPU with all other assets but a simple logo and floor still takes a while. I haven't done any real testing yet, but it appears that if only selected items in a group locator are turned off but the group locator itself is on, all of the geometry in that group locator folder are loaded onto the GPU — even if only a few of those items are visible and being rendered. That's just what the loading times seem to indicate.

[face_off]

Thanks John - there should all the relatively easy to fix once you send me the scene.

Paul

[riggles]

I think we need separate 1, 2, and 3 channel floats (or at least 1 and 3). I'm trying to drive two material settings from the same float value (X), but when I connect the float to the second input, it takes the value of Y instead of X. We need to be able to drive multiple channels from the same float value.

EDIT: Hmm, it may or may not be the float causing the issue. It may be an issue with the dirt texture not updating properly. I'll attach a sample scene.

Octane dirt cell edges.lxo.zip

(13.68 KiB) Downloaded 258 times

p.s. It would be cool if OTOY allowed direct upload of .lxo files so we didn't have to zip/unzip.

[face_off]

John - that scene is working OK for me on Win 1.53.1.70. I will upload an OSX build for that release later today, which will hopefully address this issue for you.

Paul

[face_off]

I have refreshed the installer at the top of this thread with:

1.54.1.71
- Compiled against Octane 1.54
- Minor fixes to the Live Geometry Update processing
- Fully implemented loading the Modo Mesh Cage - useful for rendering Reference meshes, and for Octane 2
- Added ability to save the ABC alembic animation into the ORBX file (refer to http://render.otoy.com/manuals/Modo/?page_id=998 for details)
- Fixed bug causing Camera > Reset to Default to not work
- Modo801 Reference meshes will now render if you enable Load Cage for the reference mesh

1.53.1.70
- Fixed issue where Environment IBL rotations were not animatable
- Any Shader Tree material group which has a Polygon Tag Type of "Selection Set" will now be ignored (rather than override all materials below it)
- Creating Octane emitters for Modo Area and Photometric light may sets the created geometry to invisible to the Modo renderer
- Changed the "Delete Unused Nodes" to only delete unconnected Octane nodes, rather than any unconnected Modo change modifier
- Fixed issue were Octane nodes were being misnamed on Modo801
- Fixed issue where the Octane Override for a light was not being correctly selected in the Schematic after creating an emitter on Modo801
- Changing the visibility of a replicator item will now pop a message saying the Viewport needs to be refreshed in order for the change to be seen
- Replicators now work correctly is their source mesh items are not visible
- Improved the scene loading progress monitor accuracy
- Many performance improvements when checking for live update geometry changes
- Replicators now load correctly when the replicator item property "Use Source Transform" is enabled
- Changing the Mesh item "Live Geometry Update" property now requires a scene refresh to take effect. This resolves a number of performance issues on very large scenes
- Fixed bug when running under Modo801 where dragging an image onto the Schematic was not picking up the filename. This is now working, however the Modo801 root cause is still there.
- Fixed issue where the IES filename was not being picked up when using Create Octane Emitter for a photometric light
- Added button to disable all live geometry updating - use this on scene with a large number of mesh items to stop lag caused by the plugin checking for geometry updates
- The Specular Amount Shader Tree effect texturemaps are now treated in the same way as the Specular Color teturemaps and convert to the Specular pin of the Octane material

Paul