Open Shading Language

[max@mfx]

Could you consider implementing Sony Imageworks Open Shading Language (OSL)? It would be a great addition.

Maybe it's to tied to RenderMan-type renderers, but it would still be great with programmable shaders without using the C++ API.

Here is a link: http://code.google.com/p/openshadinglanguage/

Best Regards,
Max

[bigbossfr]

Hi,
You have a thread on SL here : http://www.chaosgroup.com/forums/vbu...ghlight=metasl

[vlado]

It is not particularly difficult to implement OSL if needed and we have actually looked into that possibility. I should note though, that most people that we asked were not actually too keen on writing shaders.

Best regards,
Vlado

[max@mfx]

Thats great! I hope you decide to implement OSL, I think it's a really modern take on the concept.

Too bad not many are willing to write shaders, I think that is something you need to add to compete with RenderMan and other heavy production renderers. I just wrote a 700 line C++ texture for VRay and even if it came out ok, it was way too involving as it became "real" programming with all the ins and outs of C++. To sit in a text editor in Maya would have been so much easier, now I had to restart/reload the .so after every compile..

I definitely think you should go offensive toward bigger production pipelines, VRay have so much to offer that is hard to get in RenderMan for example.

/Max

[instinct]

While Higher Level approaches like OSL or MetaSL are very convenient there is sadly still a performance letdown and some other issues. From the google code wiki of OSL:

But we are NOT yet ready for full lighting and rendering production. In addition to some missing (very minor) functionality in the language itself, OSL's shading performance is still much slower than our previous C-language shaders (we're aiming for approximate parity with our old shaders). We are making rapid progress and hope to hit our performance targets in the next 3-4 weeks. In fact, we HAVE to, since our own shows will need full performance as they get into full production within the next few months.

These 3-4 weeks are long since gone. Got no idea if it worked out. There's quite some interesting info here (esp also the state of the project part)

http://code.google.com/p/openshadinglanguage/wiki/OSL_Introduction

Regards,
Thorsten

[max@mfx]

Yep I read that, I read the full spec as well, and the source code. The thing is that they moved over to Github so the info on that page may be slighly outdated. If you look at the changelog on github they released the 1.0 version this october so I definitely think they have a lot of stuff going on. On the other hand it's a bit RenderMan centric, but it still looks general enough to be used in any modern renderer.

The performance issues is sad but also very natural I think, and in many cases the flexibility to be able to author a custom shader that does the job is worth more than the speed decrease compared to the same shader in C++ or done in the the hypershade.

Vlado, do you have any numbers on the performance of a hypershade network with about 10 nodes and 4 textures compared to a C++ shader that does the same task?

/Max

[vlado]

A specific shader is always going to be faster than a shader network; this is one of the advantages of OSL - it takes an entire shading network, compiles it into a single piece of code and optimizes the final result. This allows a lot of dead code to be removed (all those options that are there, but may not be really used in the particular case, like texture color and alpha gain etc) and the rest to be tightly optimized for the specific shader. In fact, from what I saw at the SIGGRAPH presentation this year, at Sony OSL was mostly used to speed up rendering, rather than for writing shaders. A downside is that you have to wait for the shader networks to compile prior to rendering. Another downside is that OSL is not very well suited for advanced stuff that requires things like external file accesses (other than textures, that is), OS calls or more complicated data structures like binary or octtrees and such.

In any case, if you are interested in our GLSL plugin for V-Ray for Maya/Standalone, drop me a line and I will get you what we have so far.

Best regards,
Vlado

[max@mfx]

Yep, I see your point.

Is the GLSL in the latest nightly? In that case I can grab it there instead..

/Max

[instinct]

Thanks for the insight vlado. Great read as usual!

@max: i beg to differ on the "flexibility vs. rendertime" issue. I am currently looking into a lot of "micro improvements" as a few seconds per frame add up to imense time loss (and money beeing spend on power/ac etc) very quickly with decently sized farms.

Regards,
Thorsten

[max@mfx]

Thorsten, sure that is of course very important. But in some cases it's just plain faster seen over the whole production to write a piece of shader. As an example is a very flexible cloth shader I wrote which is extremely simple to tune to get the desired results. The other only way to do the same task would be to paint several textures for each cloth pattern (which are really complex) and hope they don't get visible tiling, a really boring and hard task for 50+ cloth variations... So in that case, a custom shader was the only way to go, and it took me two weeks to complete. If it could have been done in one week and render 5% slower it would stil have been the best choice. So I guess the flexibility vs render time issue is completely dependent on the project.

My point would not be to remove or have all shaders rewritten in OSL, just to have a way to tailor a really specific shader for a task. And as Vlado says, this could really pay off due to the minimal approach with only the needed calculations being included. Then again; I don't know if OSL could handle all features needed in VRay, like external files as Vlado mentions, but I sure like the idea of a more universal DSL for shading so there can be more sharing of knowledge of procedural shader construction. There is extremely sparse with info about RSL considering how long the system have been around (30+ years)!

/Max

[instinct]

Good and valid points. Re-reading what i wrote i realize that came across as if i was against getting OSL on board. I am most definitely not and would love to see it! Just wanted to point out some relevant pitfalls. In the given example i guess a good approach would be prototyping in metaSL/glsl/osl whatever, tune and tweak the featureset, and if there is a severe slowdown to be expected develop a native compiled version for optimisation. There is quite some nice possiblities to ease creation of native plugins too. Agreed that it can be pretty time consuming during development, it is still a viable route to go after all details/specs/POCs etc have been done in a highlevel version. I gotta say i love the idea the more i think about it hehe

Regards,
Thorsten

[max@mfx]

Great to hear Thorsten!

/Max

[vlado]

Here are some examples as we get closer to a more complete implementation:

[vlado]

Some more:

[vlado]

Part 3:







Best regards,
Vlado