In Theory.... Sending 3Delight RIBs to PRMan?

[3delight]

Hello,

Hi all,
In theory, should PRMan take 3Delight-generated .rib files and render them correctly?


Not only in theory but in practice too, until very recent versions of PrMan.
We really try to maintain 100% compatibility and some clients out there do use 3Delight to render prman generated RIBs.


Can anyone think of any potential issues that may arise?


The only problem is that if you want to use the most recent features of PrMan you will have to wait until 3Delight implements them. This is usually done in a quite short lapse of time though.
Note that the contrary is not true: not all the features of 3Delight are/will be supported by PrMan (I can think of automated subsurface scattering, network cache, inking, ...etc).

Thank you,
- 3Delight.

[Mauritius]

Martin,
In theory, should PRMan take 3Delight-generated .rib files and render them correctly?
Can anyone think of any potential issues that may arise?

as long as you're not mixing images from both renderers in comp... not many. ;)

Things that will be different for starters across all RMan-compliant renderers are the noise() and specular() shadeops.

As Aghiles pointed out, there are a few differences & 3Delight features not supported by PRMan that your RIBs/shaders may or may not rely on:


Light shaders use Ns (in sync to Ps), not N. N is reseved for the area light case in 3Delight. I think this might change (to be compatible with PRMan) in the next 3Delight release but it's good to be aware of it as PRMan's shader compiler doesn't know Ns.
subsurface() shadeop for fast & artifact free[tm] subsurafce scattering on-the-fly doesn't exist in PRMan. You will need to generate a point cloud in a pre-pass, filter that with ptfilter then look it up with texture3d(). This is much slower and prone to a funky "polka dots" effect and crazy colors under quite a few circumstances. I'm saying PRMan's built-in subsurface will give you something to worry about after getting used to the one in 3Delight. ;)
Overloaded indirectdiffuse() on environment maps (automatic diffuse convolution).
Importance-sampled ambient occlusion via occlusion( ..., "distribution", "myenvmap.tdl", ... ) uses a different interface in PRMan: occlusion( ..., "brightnesswarp", 1, "environmentmap", "myenvmap.tdl", ... ).
Exclusive or trace-group-based displays are not availble in PRMan. Afaik, 3Delight is the only renderer on the market with these features. If you render once in 3Delight and have e.g. four somehow 'exclusive' AOVs declared in your RIB, this means you need to render the same RIB five times with PRMan.
3Delight's network read/write cache has no counterpart in PRMan (might be a real issue if you have been relying on it in 3Delight).
Shutter efficiency (http://dctsystems.co.uk/Text/ShutterPresentation.pdf) is set through an Option in 3Delight but through a Hider parameter in PRMan. Pixar just added this feature in 13.5 and decided to use a different interface to it (it has been in 3Delight since over 2 years).
Attribute "dice" "hair" in 3Delight offers more control over RiCurves shading in the u-direction than PRMan:

0 = use shadingrate (like PRMan)
1 = 1 shading sample (like PRMan)
n (n > 1) = use shadingrate but not less than n samples across u
-n = force n shading samples, regardless of shadingrate (undocumented)

RiPoints can render as RiSpheres, RiDisks, RiPatches (sprites) or RiBlobbies. This is not supported in PRMan (can be solved by a Rif filter, unless these points come from a DSO calling another DSO in which case Rif filters don't work anymore in PRMan).
Texture maps need to be created with the -separateplanes switch in tdlmake to be useable by PRMan (then they are 100% compatible and can be shared between both renderers).
3Delight allows you to call RiProcDynamicLoad() directly (without RiProcedural), thereby omitting the hidden saving/restoring of the attribute stack. This allows one to modify the attribute stack through a DSO. In PRMan this is only possible with Rif filters or calling a program with RiProcedural RiProcRunProgram (which curiously doesn't save/restore the attribute stack -- at least it didn't in PRMan 11.5, when I tested this last). If your pipeline depends on this (and a modern pipeline would because Rif filters are kinda lame compared to this option), you will have to come up with a plan b to get the same happening in your RIB in PRMan. :D
Other noteworthy stuff:


3Delight uses a different, from my experience often more efficient way of dealing with large and/or complex scenes & ray-tracing/GI than PRMan, so the parameters that control how lookups into PRMan's irradiance atlas etc. are done don't exist in 3Delight. I.e. you would need to add them to your shaders/RIBs when rendering with PRMan.
Anything that PRMan doesn't like usually makes it barf with an error message, then abort with a signal 11. 3Delight on the other hand always tries to render a frame, no matter how many errors it encounters. This means that RIBs & shaders from a pipeline designed with 3Delight's forgivingness in mind might give you a lot of unexpected trouble with PRMan.
The RiSubdivisionMesh creases & corners implementation in 3Delight uses a different algorithm than PRMan, due to the latter's being patented. The results are similar enough that most unbiased viewers couldn't tell the difference. However, a senior modeller definitely could. So if you rely on these, your models might change shape 'oh-so-slightly' when switching renderers.
3Delight's deep shadow maps offer slightly more control over quality than PRMan's. Certain values choosen to work in 3Delight might need revisiting when rendering in PRMan and some parameters won't apply.
The toon outline inking options have no counterpart at all in PRMan. Not a biggie unless you rely on the renderer doing NPR stuff itself.
In general I found that 3Delight outperforms PRMan in many disciplines. I only mentioned ray-tracing, but there are others. Just be prepared for increased render times when switching renderers in this direction.
Hope that helps.
All in all it is fairly painless to mix both renderers (and more beneficial than going with just either one of them for sure). I also have some utility that converts 3Delight point clouds to PRMan (e.g. to use 3Delight's nice & easy subsurface scattering in PRMan). Drop me a line and I send you a copy.

Cheers,

Moritz

[mixermanic]

Fantastic - thank you so much for that info. It will take me a while to go through it all :D

One question that immediately springs to mind - does 3delight support Maya's ocean shader and other fluid effects (smoke/fire etc)? If not, is there a PRMan compliant renderer that does?

I plan to be use PRMan for the majority of my new project, but I think there will be several places where 3delight could help a lot (and it would be interesting to do some comparison renders as well!)

Thanks,

M

[jupiterjazz]

Fantastic - thank you so much for that info. It will take me a while to go through it all :D

One question that immediately springs to mind - does 3delight support Maya's ocean shader and other fluid effects (smoke/fire etc)? If not, is there a PRMan compliant renderer that does?


Not currently.
PRMan has an implicit surface plugin for fluids, but no matching shaders.
So you have to reverse-engineer the shaders.

I am pushing to convince AutoDesk to make opensource all the shading code that can be rendered by the Maya renderer, and this includes fluids.
I think since the Maya renderer is in maintenance mode this would be a wise choice and a good policy toward users, production and developers.



I plan to be use PRMan for the majority of my new project, but I think there will be several places where 3delight could help a lot (and it would be interesting to do some comparison renders as well!)
Thanks,
M

Definitely!


p

[mixermanic]

Ok thanks for that info.

But it is relatively simple to render out the ocean on a different pass with a different renderer (Maya soft or MR)?

I assume that would also affect the reflections of lights or objects in the ocean? Could I render out a reflection pass in PRMan (as the surface will deform correctly although not be shaded) or will that overcomplicate things?

Sorry, one final question off on a tangent - PRMan has no issues with nCloth right? As the shaders for cloth are normal shaders....

Thanks!

Martin

[jupiterjazz]

Ok thanks for that info.

But it is relatively simple to render out the ocean on a different pass with a different renderer (Maya soft or MR)?


Yes, because there is a set of shaders both for the maya renderer and mental ray.


I assume that would also affect the reflections of lights or objects in the ocean?


IN maning IN the volume? No, not volumetrically, the ocean shader is a surface shader, not a volume.


Could I render out a reflection pass in PRMan (as the surface will deform correctly although not be shaded) or will that overcomplicate things?


yes.


Sorry, one final question off on a tangent - PRMan has no issues with nCloth right? As the shaders for cloth are normal shaders....

Thanks!
Martin

No issues whatsoever. These are regular shaders.

p

[mixermanic]

Thank you!!


IN maning IN the volume? No, not volumetrically, the ocean shader is a surface shader, not a volume.


Sorry - I didn't explain myself very well. I was referring to the fact that if I rendered the ocean in (for example) MR with all the reflections of lights (for example the sun) and other objects (if for example my scene had a ship in the ocean, the ship would to an extent be reflected back in the ocean in distance shots), then the "look" of the lighting may vary from PRMan to MR, and therefore probably look incongruous when comped together.

But if a reflection pass of the ocean can be done in PRMan, that would solve that...

Cheers!

Martin

[jupiterjazz]

Thank you!!



Sorry - I didn't explain myself very well. I was referring to the fact that if I rendered the ocean in (for example) MR with all the reflections of lights (for example the sun) and other objects (if for example my scene had a ship in the ocean, the ship would to an extent be reflected back in the ocean in distance shots), then the "look" of the lighting may vary from PRMan to MR, and therefore probably look incongruous when comped together.

But if a reflection pass of the ocean can be done in PRMan, that would solve that...

Cheers!

Martin

Of course it can. renderman renderers have a production-proof raytracer that is called on-demand.

[Als]

Hope that helps.
All in all it is fairly painless to mix both renderers (and more beneficial than going with just either one of them for sure). I also have some utility that converts 3Delight point clouds to PRMan (e.g. to use 3Delight's nice & easy subsurface scattering in PRMan). Drop me a line and I send you a copy.

Cheers,

Moritz



Thanks Moritz,

that was great!





Als

[bazuka]

can we get some info for 3delight on update/new ver?

10x

cheers...

[Mauritius]

One question that immediately springs to mind - does 3delight support Maya's ocean shader [...]
Just an update on this: The latest 3Delight For Maya does have support for the Maya ocean shader (i.e. it converts Hypershade ocean shader nodes automatically).

There are only a few changes you need to do if you want to use the 3DFM SL source with PRMan. Particularly PRMan doesn't have several shadeops overloaded for component datatypes (e.g. there is no version of clamp() that takes a color in PRMan, you have to clamp each of the color's components separately).

.mm

[swag]

@Mauritius
"The latest 3Delight For Maya" - you mean a support version or the 7.0 version?

[Mauritius]

@Mauritius
"The latest 3Delight For Maya" - you mean a support version or the 7.0 version?
The 3DFM that ships with 7.0.0 has ocean shader support. So you don't need to be on a support contract or even buy the renderer to use it. :)

.mm

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.