OctaneRender for Modo (Windows) 1.52 [STABLE]

[funk]

In standalone (and lw plugin), the default environment is set to texture with an RGB color input (it allows you to quickly change the color of the background).

In the modo plugin there's no way to set this up. Setting environment to texture should pick up the color in modo's environment material. I tried the following:

1. I set environment type to constant, and set the zenith color to purple.
2. I tried adding a "constant" layer above the environment material.

Both those methods should work to match the modo renderer and standalone functionality.


UPDATE: I see that you actually have channels for "Texture (Octane) R/G/B" in the environment channels, but this isnt exposed anywhere in the GUI (why not?).

I can actually hook up the zenith color channels to the octane texture color channels to make this work. Only problem is that it doesnt update in real time. I need to refresh the renderer

[funk]

Instances of octane overrides arent updating correctly in the render viewport

1. Add 2 sphere items
2. Give each a different material (ball1 and ball2)
3. Select ball one in the shader tree and add an octane override
4. The setup window pops up, so reselect the override in the shader tree then press "instance octane override" in the setup window
5. In the shader tree drag the new instance to the ball2 material
6. Open the octanerender viewport. Everything looks ok (2 identical spheres)
7. Select the original override in the shader tree and change the settings on the glossy material

BUG: Only 1 sphere updates in the render viewport. You need to force a reload to see changes to the instanced override material

[funk]

Small errors in "Octane viewport controls" tooltips:

* Reload all texturemap files... The Viewport most... should be must
* Save to OCS format... The Viewport most... should be must
* Save Render has no tooltip

[riggles]

BUG: Only 1 sphere updates in the render viewport. You need to force a reload to see changes to the instanced override material

Yea, it's interesting because the RGB Color nodes will update both automatically, but not the material settings.

[funk]

Disabling material masks in the shader tree is not working correctly. The material in the mask is still being displayed by octane

[funk]

There's a couple of issues with animation saving

Problem 1:
eg. I set my range from frame 0 to 60 (thats actually 61 frames)
Octane saves filenames modo_animation1.png to modo_animation60.png (it only saves 60 frames), so the last frame of the animation is missing.

Problem 2:
The naming convention should use the modo frame number and start at 0 to avoid any confusion. This would also allow us to re-render specific frames if needed while keeping the correct file name (instead of auto restarting from 1). It would also be nice to use zero padded numbers. It would be even nicer to use modo's output pattern under the render item > output pattern.

Problem 3:
There is no way to set an output path per scene (only a global setting in modo preferences). Octane overwrites previous frames in that directory too.
This makes it very easy to accidentally overwrite animation frames from another scene... ouch

[riggles]

Lookout, funk is on the case!

[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+

Hi Funk. Good suggestion. I actually added this to the cfg a month or so ago (to make SP4 a requirement), and the XML gave problems on OSX, but it should be on the Windows version. I will actually use

Code: Select all

and="ver]66614"

, since anything less than SP4 does not work well.

the default environment is set to texture with an RGB color input (it allows you to quickly change the color of the background). In the modo plugin there's no way to set this up.

This is planned for implementing in the next release or two. It is probably less confusing if there is an RGB color in the Octane Texture Environment properties, rather than picking it up form the Modo environment.

UPDATE: I see that you actually have channels for "Texture (Octane) R/G/B" in the environment channels, but this isnt exposed anywhere in the GUI (why not?).

Editing the Octane Environment channels in the Schematic is not currently supported - but may be implemented in the future. I'm not sure whether having the Environment as a node where you can plug anything into it is better than having a (more) complete "Octane Environment" properties pages (as is currently implemented) yet.

1. Add 2 sphere items
2. Give each a different material (ball1 and ball2)
3. Select ball one in the shader tree and add an octane override
4. The setup window pops up, so reselect the override in the shader tree then press "instance octane override" in the setup window
5. In the shader tree drag the new instance to the ball2 material
6. Open the octanerender viewport. Everything looks ok (2 identical spheres)
7. Select the original override in the shader tree and change the settings on the glossy material

You are right. I think this is because the feeder node (diffuse material) of the source override is being deleted and then recreated (as a specular material) and this is all automated and tripping up the Modo instancing system (since it only the OVERRIDE which is instanced - all the other nodes are actually one set of nodes connected to the input of the source and instance Override). This is definitely something I never considered. The intended workflow is you change the diffuse to a specular, THEN instance the material, rather than instance then change the material type. There is not a simple fix for this - but I will look into it in more detail to see what can be done.

Small errors in "Octane viewport controls" tooltips:

Fixed in the next release.

Disabling material masks in the shader tree is not working correctly. The material in the mask is still being displayed by octane

Fixed in the next release.

Problem 1:
eg. I set my range from frame 0 to 60 (thats actually 61 frames)
Octane saves filenames modo_animation1.png to modo_animation60.png (it only saves 60 frames), so the last frame of the animation is missing.

I will fix this. I'm enhancing the animation system so a popup panel opens to indicate an animation is rendering, and the number of frames progressed so far, so I will do the above change at the same time.

Problem 2:
The naming convention should use the modo frame number and start at 0 to avoid any confusion. This would also allow us to re-render specific frames if needed while keeping the correct file name (instead of auto restarting from 1). It would also be nice to use zero padded numbers. It would be even nicer to use modo's output pattern under the render item > output pattern.

Ys, I will change it to be 0 based. The output pattern is not a simple thing to implement, so I'll add it to the long-term list.

Problem 3:
There is no way to set an output path per scene (only a global setting in modo preferences). Octane overwrites previous frames in that directory too.
This makes it very easy to accidentally overwrite animation frames from another scene... ouch

I could move the output path out of the preferences, and into the Kernel properties - then it would be specific to each scene.

I am also working on rectifying some other issues. So you know what's already in the next release, the notes so far are:

1.33.0.48
- Added Octane Camera option to use the Modo focus distance to set the Octane focus distance, and the Modo Fstop to set the Octane aperture

1.33.0.47
- Texturemap filenames with special characters will now load correctly into the Octane scene
- Shader Tree groups which are disabled (ie. not visible) are now correctly ignored by the Octane scene
- The plugin now supports Octane and Modo materials in the Shader Tree Library folder.
- Fixed issue where material tags were not being processed correctly when converting materials
- Limitation - changing the Polygon Tag on a material group does not cause the material to be reloaded in Octane. This is scheduled to be fixed in the next major release of Modo.

There is also an issue with replicators with "Incl Child Items" ticked, and with material groups within groups not working correctly, which have a high priority at the moment (since they are bugs rather than enhancements).

Paul

[funk]

1. Add 2 sphere items
2. Give each a different material (ball1 and ball2)
3. Select ball one in the shader tree and add an octane override
4. The setup window pops up, so reselect the override in the shader tree then press "instance octane override" in the setup window
5. In the shader tree drag the new instance to the ball2 material
6. Open the octanerender viewport. Everything looks ok (2 identical spheres)
7. Select the original override in the shader tree and change the settings on the glossy material

You are right. I think this is because the feeder node (diffuse material) of the source override is being deleted and then recreated (as a specular material) and this is all automated and tripping up the Modo instancing system (since it only the OVERRIDE which is instanced - all the other nodes are actually one set of nodes connected to the input of the source and instance Override). This is definitely something I never considered. The intended workflow is you change the diffuse to a specular, THEN instance the material, rather than instance then change the material type. There is not a simple fix for this - but I will look into it in more detail to see what can be done.

I think there is some confusion (and please excuse me if I'm the one misunderstanding here). I didnt change the material type from diffuse to specular. I left everything the way the override creates it (it created a glossy material). Both overrides are being fed by exactly the same nodes. I just instanced the override and placed it in another material mask.

Here are clearer steps (I hope):
1. In the model tab, in item mode, shift+click a sphere item and rename it to "sphere1".
2. Press m and give it a material "mat1" (using the default color=1,1,1 diff=80% spec = 20%)
3. shift+click a new sphere item, rename it to "sphere2" and move it +1m X
4. Press m and give it a material "mat2" (using the default color=1,1,1 diff=80% spec = 20%)
5. Select mat1 in the shader tree and add layer > custom material > octane override (it should open the octanerender setup window and you can see an RGB color plugged into a Glossy material)
6. Press "instance octane override"
7. In the shader tree, drag the "mat1 (2)" instance above the material layer in the mat2 material mask
8. Click Open viewport. 2 White glossy spheres should render
9. Select mat1 in the shader tree, click the glossy material node, change INDEX = 1, specular = 1

BUG: One sphere becomes mirror/chrome while the other remains white. I dont think I'm doing anything unexpected

If you click the "reload the scene" button, it refreshes and fixes the viewport render so both spheres are chrome


EDIT: I think I understand what you were saying. Your original intention was to set up the material as you want it, THEN instance it and never touch it again... I just can't see any of us working that way because we are constantly changing our minds

[funk]

UPDATE: I see that you actually have channels for "Texture (Octane) R/G/B" in the environment channels, but this isnt exposed anywhere in the GUI (why not?).

Editing the Octane Environment channels in the Schematic is not currently supported - but may be implemented in the future. I'm not sure whether having the Environment as a node where you can plug anything into it is better than having a (more) complete "Octane Environment" properties pages (as is currently implemented) yet.

Would you consider creating nodes for the env/camera/kernel etc? In the standalone and lightwave plugin (which are node based), I can set set up multiple kernels, or imagers and easily plug in and out of them. In modo I have to go in and change the settings each time.

I often have 1 imager set up for linear workflow and another using a camera response curve and find it really handy to bounce between them. I can also set up a zdepth kernel, a material ID etc etc and easily plug in and out of them for different passes.

Maybe we could use modo's render passes for this too, but I would like the option of doing it the way the standalone does too.