OSL and Octane 3.1

[calus]

OSL (OpenShadingLanguage) support in Octane 3.1 is a promise of high hope among plugin developers and many users,

But the truth is, it really depends the way it's implemented in Octane core.
Depending on the limitations, OSL can be either, just a new toy, or a revolution.


The Octane for Maya case :
OSL support can improve drastically the Maya plugin, basically giving a solution to lot of the major flaws of the plugin.
and bring back for studios the hope that Octane can be used in Maya as a production renderer.

At the moment only 1 % of the Maya nodes are supported by the plugin,
and that's a shame because many of the Maya builtin feature need some of these nodes,
(some temporary hacks are added to the plugin instead of adding support to the Maya nodes = bad)

A clever and open implementation of the OSL feature is needed in the Maya plugin:
- At render time when the Maya scene is translated to Octane, Maya nodes are translated to their OSL counterpart if they are provided in the OSL shader path.
- Lots of Maya nodes already have OSL translation.
- With this mechanism, any Maya external plugins can be supported by studios developing their own OSL shaders and providing them in the OSL path.
- For example even the Arnold 5 aiStandartSurface node can be supported by providing in the OSL path an OSL implementation of this material (can be developed based on the alShader OSL implementation)

But for this to work, OSL support in Octane Core must not be only a texture toy :
what will be supported ? OSL closure ? LPE ? agressive Optimization by compiling at render time ?
What limitations or additionnal render time ? will this prevent or defeat my point of how I expect OSL to be used in the Maya plugin ?

If really Octane 3.1 is supposed to bring a complete and efficient implementation of OSL,
plugins development should take this in consideration, no need to waste time by implementing temporary hacky features,
unless 3.1 release is going to take one more year... ?

[haze]

Pascal, thanks for your comments, unfortunately we can't currently comment on most of your questions at this time. OSL will be a rendertime feature, but will require some amount of work on plugin side to use, whereas mostly this is currently solved (also in max) by using previewMaterial renders straight to texture.

[itsallgoode9]

[Post removed]

[nuno1980]

Will birefringence (and multi-refractive index) be added for specular material on new v3.1?

[calus]

whereas mostly this is currently solved (also in max) by using previewMaterial renders straight to texture.

Hey Haze , thanks for the answer,
though I'm not sure to understand what you mean.

My questions are not about how OSL will work in the plug-ins but how it's implemented in Octane Core.
Then depending on that, the mechanism I propose in the Maya plugin could work or not.
Just to be sure, I'm not talking at all here about how a custom OSL node could work in the plugin UI.

Let me explain more:
In Maya everything is a node like in Octane Standalone, then most of the Maya builtin features use nodes under-the-hood.
The Octane For Maya plugin only supports its own nodes and a tiny subset of the Maya builtin nodes (see here: viewtopic.php?f=28&t=61075)
as a result a lot of the Maya builtin features are not supported,
or when they are supported this is in a limited black-box way.

My hope with the 3.1 core is that I can myself (or anyone capable) implement support for any arbitrary Maya Shading nodes trough OSL.

And on top of that I propose a simple mechanism in the Maya plugin to be implemented :

Until now at render time the plugin only consider the supported Maya nodes, translate them to an Octane scenegraph,
and just ignores any other node types in the Maya dependency graph.
I propose a mechanism where at Render Time a list of OSL files is parsed in a predefined OSL path,
then the plugin checks if an OSL file with the same name exists for any Node Type present in the Maya scene, ,
then translate the Maya nodes to Octane OSL nodes pointing to their matching OSL file, and copying values and connections.
and just ignore as usual any nodetype that is not supported directly or missing a matching OSL shader.

I don't ask if it's possible to implement this mechanism in the Maya plugin,
I know it's possible and easy to implement in Maya.
I'm asking if this mechanism is making any sens when considering the limitation of the OSL implementation in Octane Core.
I just need a simple YES or NO answer here:

If the answer is NO, I can just stop to wait impatiently for 3.1
and I don't even need details about the limitations that would prevent Maya builtin shading nodes to be supported trough Octane OSL.

On the other way, if the answer is YES, I can already start to implement or collect the OSL shaders for the maya nodes that I would like to be supported,
I don't need Octane 3.1 for that, I can already use any other OSL capable renderer for prototyping,
but I'm not against any recommendations for the rules or the structure I should respect for Octane OSL coding.

[coilbook]

Any eta on 3.1. It's been ages. Hopefully this year.