OSL / materialX support with importer/exporter
MaterialX is an open source standard to transfer shading, created by ILM : materialx.org/ .
Actually materialX is supported by arnold and renderman, redshift is working on, Adobe / substance too so it can be more than interesting that cycles handle it well
MaterialX is actually a part of the OSL initiative and USD, so it's in the continuity of what is already coming to blender with OSL support, so it's means more work on the OSL implentation.
the point is to make shading more independant from the model and the scene, so basically you can publish an update of the shading that scenes reads at lighting and/or rendering stage, with or without tweaking
importer :
- import mtlx files
- readnode for shading (without graph)
- override values to customize the shader a little for the scene (ex: specular intensity)
- convert mtlX shading to node graph (rebuild the entire graph for editing)
exporter :
- convert shading graph to materialX standard
- create mtlX file
7 Comments
I know this one is old, but this is really such a good idea all around even if it won't work for certain imports, and may limit features that can be used for export.. If we know the limitations, then we can work within that realm. Would enable being able to use freely available MaterialX shaders in blender as blender nodes, then work from there (where you're already familiar). And on the export side, once you go to MaterialX, it's easy to export to GLSL or other -- even if some features wouldn't work, that's ok - just warning or error message there. Convert the rest, user can fix issues on other side, but already has most setup for them. Just a consideration. On the export side would be a HUGE plus for game devs that use blender.
One thing worth considering is the fact that (as far as I know), MaterialX doesn't support all of the features available in Cycles. An export (and possibly an import) from Blender may not have a 1-to-1 correlation so the results won't look exactly the same. How would you propose that this be handled?
* @Jason van Gumster * what features do you refer to ? does these features are supported by OSL ? if yes, It seems that it can be ported fastly to MaterialX
actually even other renderer doesn't fully support materialX but it's working in a majority of case right now the missing features can also be submitted to the MaterialX dev team as new update comes like all 3 months on official github
To me it's quite like USD, that is still missing some parts but cover most needed features and permit to studio preparing a rebuild of the pipeline
* @William Eguienta * That's fine, but it doesn't really answer my question. We can't assume that the MaterialX dev team will include all of Cycles' features... or do so in a timely manner. So when the situation arises where there's no 1-to-1 correlation, how do you think that should be handled in the importer/exporter? Should there be an error message to the user? Should that material be skipped? Should there be an approximation? How would that approximation be created?
These are the considerations I'm asking you to respond to.
* @Jason van Gumster * yes my answer was off, sorry
i think that a pop up message should appear at exporting to inform users that this shader cannot be properly done in materialX and specify what part of the nodegraph can't be translated. a meta description can be in the file too
To me we have 2 possible workflow here
the exporter/importer should not try to approximate the result. The readnode cant read an incomplete shader so it return an error message. the importer/graphbuilder can rebuild the doable part of the graph and let the user complete it manually for missing features (with osl nodes). The error at import can be messaged too, describing the missing node, it's input and output
The problem of this is that it will kill the compatibility with other renderers and limit the support to blender only. (or means people needs to create a custom reader in other DCC) Anyway. if we follow this path, as materialx files are just xml files, we can have some custom data in it that can help the rebuilding. At building the unsupported node can be rebuild by OSL nodes and connected to the materialX graph. Cycles will render it as OSL, as materialX is a part of OSL. If the missing shading feature is not doable in OSL and we still want to force rebuild, it's starting to be more tricky. The exporter/builder can add the real cycle node info to rebuild it as is was before importing. actually I'm not not aware if it's possible to combine OSL to any cycles nodes, so I'm not sure at all if it's doable or not. not sure it worth the effort too...
A way to just extract the textures maybe
This is old, but it seems that other MaterialX implementations just create custom nodes for the specific renderer. As long as there is a cross-platform subset it makes reapplying experience and translating easier. No reason there couldn’t be if-nodes in a MaterialX graph that check the renderer to change behavior.