I’ve completed a first stage implementation of MaterialX in Blender.
MaterialX is a data interchange format created by ILM. with Autodesk and The Foundry as partners. It is
an open standard for transfer of rich material and look-development content between applications and renderers.
Please head to www.materialx.org to get more background information.
As of right now, the code base is still highly experimental and lacks feature parity with the MaterialX Library. In general, there are a number of issues that need to be fixed in order for this implementation to serve any real purpose going forward. I’ve documented the issues and other information on the website but will repost below to facilitate discussion.
The addon source code is well documented and easy to understand/parse through. I plan to continue to maintain, develop, and update this integration. If you would like to contribute, please read the contribution guidelines in the repository for details.
Code Documentation: User Installation and Usage Guide can be found here: http://materialx-blender.readthedocs.io/
Formal documentation of my codebase is forthcoming.
DEVELOPMENT TARGETS:
PLANNED UPDATES AND CHANGES:
Mac OSX Support
Support for Looks
Support for Geometry
Support for filename string substitutions
ISSUES:
BLENDER IMPLEMENTATION ISSUES
Cycles OSL
[LIST]
OSL in Cycles is 2x as slow as normal SVM render stack
Lack of robust OSL implementation in Cycles negatively effects the efficacy of this library.
To support data material data interchange between renderers, OSL support in Cycles must be modernized and usable.
[/LIST]
MATERIALX LIBRARY ISSUES
Unique Names
[=2]Currently, every named element in a MaterialX document must have a unique name.
[=2]This causes a plethora of issues when integrating MaterialX with DCCs as most software packages do not uniquely name every component of a node graph (i.e. Input and Output sockets).
[=2]MaterialX documents should respect heirarchical element components, such that uniquely named Node Sockets are completely unnecessary.
[=2]As long as a specific node is composed of uniquely named Sockets, element names do not need to be unique relative to other nodes in a node graph.
Code repository doesn’t seem to have anything, the documentation says ‘nothing here’ , maybe you didn’t mean to publish this post just yet?
but since you did… What are the issues you are having with OSL? What is not ‘robust’ or ‘usable’ about it? when you say it ‘must be modernized’ do you mean just an upgrade to 1.9 that ships with a bunch of materialX shaders by default? (master should compile against 1.9 btw) or something else all together?
The code is now publicly viewable, and the link to the documentation has been updated. Sorry for the confusion.
Regarding OSL, there’s a one key problem.
OSL in Blender is 2x as slow as SVM. This makes it completely unusable in a production environment. Sure, you can make nodes and patterns, etc, but a 2x slower render is still pretty terrible. For studios, that essentially means a shot will cost twice as much to render. In terms of “modernizing” the OSL implementation, an acceptable range of slowdown would be somewhere in the ballpark of 1.05-1.2x slower. The ability to have pattern generation/node-graphs that translate between render engines, and support for more complex shaders (thin film, etc) would then outweigh the increased render time costs.
Lack of GPU support is entirely okay. No publicly available render engine has true GPU support for OSL. Octane sort of supports it, but they just recently added the feature about a month ago. I would hesitate to say it’s a “complete” implementation of OSL on GPU. Helios seems really promising, but the two people who created it now work for Autodesk/Solid Angle/Arnold. Check out the links below for details.
Regardless, compiling OSL to GPU for Cycles wouldn’t actually solve any problems, you’d just have a 2x slower GPU accelerated render. Most production studios don’t use GPU render engines. Until GPU’s at scale are more cost effective and studios can fit extremely complex, large scenes on limited GPU memory, OSL on GPU is moot. Efforts should be made to fix the current speed problems before there is any attempt to get OSL working in Cycles on GPU.
I’ve got a solution for you then, we need to somehow make SVM 2x slower.
In all seriousness, I’m not ruling out that OSL integration could be sped up, but the library itself is the reference implementation. Blender developers can’t control how well (or poorly) it performs, nor how it stacks up against the much simpler SVM. In fact, getting rid of SVM and having just a few fixed shaders would speed things up as well. You get what you pay for.
Regardless, compiling OSL to GPU for Cycles wouldn’t actually solve any problems, you’d just have a 2x slower GPU accelerated render
GPU path tracing is absolutely not a must-have feature for a production renderer. Blender users seem to think it’s some kind of magic bullet that will let people make professional-quality CG shots at home. That simply isn’t the case. If it were that easy, every studio in the world would deal with the up-front cost TODAY for the increased show output it would provide them. There are far more serious issues with GPU rendering from a practical production standpoint (Yes, even GPU + CPU rendering) than the cost of hardware.
No one else’s OSL implementation is as slow as Cycles’ compared to their base material structures. In fact, Solid Angle is in the process of phasing out everything aside from their OSL shaders because they’ve managed to reach speed parity thanks to SPI and help from Larry Gritz himself. The developers of Cycles know that it’s an issue, and that the way OSL is maintained and slotted into the pipeline is far from ideal.
Or… no one else’s base material “structures” are as fast as Cycles compared to their OSL implementations.
Like I said, I’m not ruling out that there’s some overhead here that other renderers don’t have, but you can’t deduce it like that.
In fact, Solid Angle is in the process of phasing out everything aside from their OSL shaders because they’ve managed to reach speed parity thanks to SPI and help from Larry Gritz himself.
Well then all we need is SPI and Larry Gritz to give use a hand and we’ll be flying off with stellar performance!
Would you though? I implemented a subset of osl both in svm and as addona while ago that implemented most of the mathy bits of osl on the gpu , just because you add functionality doesn’t mean everything else suddenly gets to be 2x slower…
The bottom line is, developers need to be made acutely aware of the fact that there IS a problem and the fact that it needs to be solved going forward. OSL in Cycles is in bad shape because there wasn’t really a need for it to be in good shape. However, now that you have production studios adopting the software, and there is increased proliferation of Cycles in various pipelines, the OSL implementation should at the very least, compete with Arnold and Renderman. That doesn’t mean it has to be as fast or faster, it just needs to be somewhere in the same ballpark range of speed as the aforementioned render engines. Like I said, something around 1.05-1.2x slower would be entirely acceptable.
It breaks all logic to assume that because you put it on the GPU, the slow compilation of OSL at rendertime would just magically disappear. If you don’t change any of the underlying logic, then again, you just have OSL compiling on the GPU, with the same issues that it had before. Will it compile faster on the GPU? Sure, yeah. But that does not mean anything other than the GPU is accelerating the compilation. The GPU does not solve the inherent issue of a lack of optimization UPFRONT.
@all I’m too lazy tonight to find the right tracker thread, but the overhead comes from OIIO (it only happens when you use textures and OSL at the same time). Do the test of rendering a scene without texture with and without OSL, it will render max 1.05x slower with OSL. You can force bypassing OIIO by packing textures before rendering when using OSL, overhead will be more in the 1.4-1.5x range iirc. Theoretically, texture sampling could be then of lesser quality/have artifacts, but I personally completely kicked OIIO of my Blender builds and never had problems in a year. At least Sergey and I don’t like OIIO because “it’s a piece of crap”, with memory leaks all over the place the last time I had a look with ASAN on Linux. Also, the bugs I reported were classified as kind of “well, it’s bad bug, but we won’t fix it”.
And as Lazydodo says, a good enough subset of OSL could work on GPU at nearly no cost, it’s more a matter of politics/tracker work blabla.
Does Solid Angle have the same problem with the many apparent OSL bugs or do they use their own custom variant with the issues fixed?
If it’s the latter, then Blender may be better off if the devs. created a simple programming API for the SVM system (for custom procedurals and maybe even some ability to manipulate rays). OSL looked cool to begin with, but further development would obviously be in question if bugs do not get fixed.
That’s a good question. Unfortunately I doubt we can answer it (sending out a Brecht bird call :spin:).
SVM can probably be exposed via Python bindings (pybind11). A Python API is probably the best way forward in that case, as a C++ API for SVM would mean even more custom builds out in the wild.
However, the main issue with any API for SVM is that it doesn’t really help the situation. In fact that may open up another huge can of worms, as we would need a way to translate OSL to SVM without actually using OSL at all. MaterialX is essentially a standardized way of porting OSL code from one render engine to the next. However, it assumes that the render engine will translate the described OSL closure at runtime. In effect, we don’t even need an API, Cycles already does this. The rest of the industry is pretty sold on OSL, with working examples of solid implementations. Doubling down on SVM is almost antithetical to the stated desire of improving Blender’s position in a production pipeline.
You heard it, developers! Drop everything! “The industry” needs OSL!
Seriously, why do you even expect Cycles to be competitive within 5-20% of the market leaders that have all the financing behind them?
If “the industry” needs X, Y or Z, it can buy it. It will survive without the FOSS solution. Users insisting on FOSS can save money and be a little more patient…
Again, that’s not how it works.
OSL (in the reference implementation) is not compiled at rendertime, it’s compiled before rendering using LLVM-JIT, which isn’t that great to begin with. It’s not as good as what a C/C++ compiler can do with straightforward code. Blender developers can do nothing about that. Then you have the overhead of using OSL in a less-than-optimal way, which Blender developers may be able to improve upon.
You also have the option of re-implementing some or all of OSL on the GPU. Nobody writes compilers to run on GPUs, that’s a serial task you would perform on the CPU, once per shader. You could translate OSL into a GPU language (GLSL, OpenCL) that is compiled by the GPU driver. You could also implement all the OSL functions in GPU code and then run an interpreter for the shaders, quite similar to how SVM works. There are some parts of OSL that don’t match GPU programming well, but it’s possible in principle.
OSL compiled for the GPU may well be faster than interpreted SVM, but GPU compilers are notoriously unreliable. Artists are sure to push those boundaries beyond what’s manageable.
