OTOY Forums

face_off wrote: 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

Thanks Paul. You are doing a great job man

I was going to submit a few more bug reports but you already have them in your list which is great.

funk wrote: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.

Would this still allow the use of the Kernel and Camera dropdown properties? If you're not regularly using multiple kernels and imagers, like me, it's very convenient to adjust settings there without having to find the relevant nodes and load them into schematic just to change one setting. If the dropdown could control whatever the currently connected kernel/imager node is, then I think that might work.

Double post. Tapatalk is not my friend.

riggles wrote:

funk wrote: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.

Would this still allow the use of the Kernel and Camera dropdown properties? If you're not regularly using multiple kernels and imagers, like me, it's very convenient to adjust settings there without having to find the relevant nodes and load them into schematic just to change one setting. If the dropdown could control whatever the currently connected kernel/imager node is, then I think that might work.

Yes I agree completely. I think the way it works now is nice. I would just like to see more options to match the functionality of the standalone and other plugins. The dropdown panels could simply display the node that's currently plugged in.

Maybe a default "render workspace" could be created similar to the material workspaces you have now.

Octane runs a startup command to initialise a few variables. This marks the default scene as changed resulting in modo always asking you if you want to save changes when you exit.

There must be a different way to run a command on startup that doesnt cause this. MeshFusion runs a script and initialises variables on startup similar to octane but doesnt mark the scene as changed.

Paul, can you allow us to set the default kernel/cam/env ect settings? One thing I like about the lightwave plugin is that it allows me to set a default "render target" setup and also allows me to save out presets. Similar things can be done in the standalone by saving node graphs as orbx (use to be macros)

It can be a bit of a pain having to change the settings with each new scene (or converting old scenes)

Yes I agree completely. I think the way it works now is nice. I would just like to see more options to match the functionality of the standalone and other plugins. The dropdown panels could simply display the node that's currently plugged in.

Having thought about this some more - my preference is to add functionality/properties to the existing kernel, camera, etc properties panels rather than expose these via the schematic, since the former method will b much less confusing to users. The "Use Modo FStop" channel in the Camera properties of the next version being a good example of this. I can split the current camera/imager/postproc panel into 3 if things get too crowded.

Octane runs a startup command to initialise a few variables. This marks the default scene as changed resulting in modo always asking you if you want to save changes when you exit.

There must be a different way to run a command on startup that doesnt cause this. MeshFusion runs a script and initialises variables on startup similar to octane but doesnt mark the scene as changed.

The "scene changed" state is being triggered when the plugin adds the Octane channels to the Modo Camera and Render items. I have posted the question to the Modo devs on how to suppress this state change - may not be possible.

Paul, can you allow us to set the default kernel/cam/env ect settings? One thing I like about the lightwave plugin is that it allows me to set a default "render target" setup and also allows me to save out presets. Similar things can be done in the standalone by saving node graphs as orbx (use to be macros)

It can be a bit of a pain having to change the settings with each new scene (or converting old scenes)

Yes, all my other plugins allow the saving of a "default" rendertarget state. I have found a couple of ways to implement this with the Modo plugin - but none are fully automatic. I would appreciate peoples feedback on this. The current best (IMO) method is to save the Modo Render (and optionally Camera) item as a preset. Then simply load that preset when you start a new scene or load an existing lxo which has not had the plugin run on it previously. You can also automatically load that preset by adding a command to the config.cfg file, however that doesn't load the preset when you load an existing lxo which has not previously. I can also modify the plugin so that when it needs to add the package of plugin channels to the Render item, it loads a Render preset (containing your preferred setup) - although this has the potential to go wrong.

Also, keep in mind the Octane kernel/resolution settings are attached to the Modo Render item, and the camera/images/postproc settings are attached to the Camera item. So the default settings are split across the Render and Camera items.

The other consideration is that when you load a Preset, it loads ALL Render/Camera settings, not just the Octane settings - so you run the risk of unintentionally overwriting Render/Camera settings.

The other solution to this is to have a blank Modo startup scene - which contains the Octane default settings.

And yet another solution is for the plugin to pull the default settings from an XML file, however you would need to manually edit that file when you want to change the default settings, which may not be that convenient.

Anyhow, would appreciate your feedback on this topic.

Paul

Well all those options seems to have issues I'd rather not deal with, but if we have to make a choice:

PRESETS:
Yes, camera and render item presets overwrite ALL current settings (eg. cam position, focal length, resolution etc), so its a hassle using them on existing scenes. Sounds OK for new scenes though, but you need to load 3 presets (camera, render item and environment). I guess we can start doing this now since it doesnt need any additional coding on your side.

DEFAULTS:
Having the defaults in an XML file would be nice. It would be even nicer to have a menu item "Save current settings as default" that saves the XML for those who dont want to edit by hand


Side note: I wondered how settings are handled with multiple cameras in the scene. It seems each camera can have different settings, but the octane UI doesnt update when you change cameras unless you close and reopen the popup

DEFAULTS:
Having the defaults in an XML file would be nice. It would be even nicer to have a menu item "Save current settings as default" that saves the XML for those who dont want to edit by hand

After thinking about this some more - I agree that this is the best solution. But not a trivial change so might take a week or two before I get to it - I currently have a long list if fixes to do .

Side note: I wondered how settings are handled with multiple cameras in the scene. It seems each camera can have different settings, but the octane UI doesnt update when you change cameras unless you close and reopen the popup

Good pick-up - this looks broken to me. You can adjust the camera properties in the item channels list, but the properties panel that pops from the OctaneRender Setup window appears to be only displaying the "first" camera, which may not be the current render camera. I will fix this.

Paul

Some quick thoughts about auto material conversion:

1. Roughness
Roughness * Anisotropy = Glossy Roughness
Just use modo roughness. Multiplying by anisotropy just makes us adjust 2 values for nothing (since aniso is almost always 0% in most scenes, it means our octane roughness becomes 0). Octane doesnt use anisotropy. It also doesnt match the look of modo when roughness and aniso = 100%

2. Auto emission
Luminous intensity should create a diffuse + texture emission material. Luminous color would be the RGB color plugged into texture. There might be some issues matching luminous to octane power, but even if it's not perfect, it saves me having to create an unnecessary override

3. Glossy material conversion
The way this works right now doesnt match modo because octane's reflectivity is based on IOR (unless IOR is set to 1). So I could have 100% reflection/specular in modo (mirror) and it looks like shiny plastic in octane (spec = 1, IOR = 1.3).

What we should be doing is setting octane specular to 1 (or RGB color = modo spec/refl color) and adjust the octane IOR based on specular amount. This means we need a way to convert spec amount to IOR. I have an idea but my math is terrible so I'm not sure if its possible. We need to calculate IOR from spec amount, but I only know how to do the reverse

We can calculate spec amount from IOR like this: spec amount = ((1-IOR)/(1+IOR))^2

Can we reverse this formula if spec amount is known?