OSL in Vray 3.0and Cycles, the differences

Hello all !

I just start to use OSL with VRay 3.0, to see the differences between Cycles and VRay.:confused:

A try to make a multi-channel RGB Ambient Occlusion shader as exemple.

Even if OSL is the same shading language, there is a some differences between the two softwares.

At first, it’s the first integration of OSL in Vray ! So, be fair and forget all the things not available yet… Time will come !

OSL is not standard across renderers for closures, so I’ll not talk about them.

  1. VRay limitations :

    • 1.3 OSL specification.
    • Just one output for a shader. If you there is many, you have to choose the active one in VrayOSLMtl UI.
    • No Closure Input, but you can fool it by a ‘string’ input which will call a shader…
    • getmessage doen’t work.
    • No bump, no displacement, no volume…
    • No OSL with VRayRT (GPU)
  2. Vray cool stuffs :

    • Metadatas are working, and you can have shader interface with chackbox or file request.
    • Use of Embree with OSL, getting at least 30% faster !
    • Lot of keywords added to standard closure, to get advantage of VRay specification while staying compatible with other renderers.

In one word, Vray is less advanced than Cycles. So, near every shader written for OSL/VRay would work without any modification in Cycles. :smiley:

The limitations of Vray would appear strong for anyone with OSL/cycles experience.

  1. So, I tryed to make triple AO shader, using RGB to store the 3 AO.

The first differrence I notice is that VRay is not a real path tracer. So, the render rays are limited by Anti-Aliasing, and there is often just one ray per pixel. You can set the renderer to progressive (wich is damn fast with Embree !), wich is closer to Path tracing, but not exactely the same.

So, I have to add a Tracing Loop and some random parameters to make the AO to work with one render occurence per pixel.
Indeed, this loop works very well with Cycles, and make a better quality AO.

Vray doesn’t understand getmessage results. That is a big limitation for my AO. I use the length of the AO ray to set the AO color.

With Cycles, I trace one ray, and, according to distance, I make three differente AO level for R, G and B.

As it’s not possible to have such information in VRay, I have to trace 3 rays, with 3 distance limits. It makes the VRay/OSL shader about 30% slower.

Also, I can’t make a nice AO gradient according to distance. So VRay/OSL AO is more rough, and need more Anti-Alias, or rays, to be clean. So it’s even slower…:no:

  1. What I think about this first experience :
    Limitations are often frustrations ! But all is not bad.

Using OSL in 3DSMax is less easy than in Blender. No text editor, error message often as simple as ‘impossible to compile shader’. And sometimes, your object renders black, or just disappears without any explanation.

The Blender node editor is miles ahead of 3DSMax Slate Material Editor, and many things possible in Blender would not be possible without big change from Autodesk.

But the results are here! We can make shader for both VRay / 3DSMax and Blender. In fact, most of my ‘color’ (not closure) shaders worked in VRay with just minor or no modification.

My Vray AO shader is slower than the one really using OSL and ok for Cycles. But the Progressive / Embree mode of Vray is so fast that it run faster (or cleaner for same render time) than Cycles.

5) Future… ?
I really hope that OSL integration in Vray will be better and better, but Cycles is already one year and half ahead!

Now, I’m waiting VRay 3.0 for Maya, and for Blender, to get ride of 3DSMax limitations.

When VRay 3.0 will be available for it, Blender will become the first 3D software with two OSL renderers ! :stuck_out_tongue:

I think OSL in VRay is a big step. I hope it would open many doors for this wonderful shading language !

Here is the result :


You can download the shaders here : Multi-Channel OSL AO

Enjoy !

thanks! nice explanation (and nice AO shader)

Hey,
nice overview. :slight_smile: They indeed have some limitations: http://help.chaosgroup.com/vray/help/300R1/vrayosl.htm

I was quite surprised about that though. I mean, they said at Siggraph 2012, that they already have it working: http://www.fxguide.com/featured/more-from-siggraph-2012/ That was about 4 months before we released Blender 2.65, first time with OSL. To be fair though, Cycles was designed for OSL from the beginning (2011).

We also use Embree code for BVH traversal and BVH build, probably we can utilize more here though. :slight_smile: Also make sure to test with Blender 2.70 RC (or a current daily build), OSL became 10-30% faster since Blender 2.69.

But cool to see OSL in more render engines, Appleseed also integrates it atm.

Cheers,
Thomas

I’m surprised, Chaos Group is usually pretty good on being on top of things when it comes to rendering technologies, and I don’t see why they would have crippled OSL support for 3.0 unless they’re just testing the waters or were starting with a codebase that was rather OSL unfriendly (perhaps in part the latter since DingTo has emphasized that Cycles was developed from the get go to eventually support it).

Our Embree base is very old, I think. 1.0? There have been some impressive speedups in the Embree core since then.