Transmission In Vex

[symek]

Do you have any idea (sure you do) what are the closest possible relative VEX functions to RSL's transmission() or traverse() ?

Let's leave traverse(), its seems to be a small piece of art but I can't find any transmission one... Except filtershadow() which seems to serve similar functionality (or differs in terms I can't understand now).

Sorry for a noob question. Up to know I was so delighted with Mantra possibilities of micro-poly that I've never wrote single line of code using ray tracing. Really.

But things have changed. I play with transmision() and subsurface() (which is crazy fast) calls in 3delight and read some stuff about PRMan ray trace engine.

Could anyone write a few words about this specific issues?

Thanks.

Simon.

Edited February 24, 2008 by SYmek

[Mario Marengo]

Do you have any idea (sure you do) what are the closest possible relative VEX functions to RSL's transmission() or traverse() ?

Hey SY,

I don't have either the rsl or vex docs in front of me at the moment, but I'm pretty confident that yes, the equivalent VEX function to RSL's "transmission()" would be "filtershadow()". I seem to remember that RSL took two points instead of the point+vector (where the length of the vector implies the second point) of VEX, but the functionality is pretty much identical -- i.e: they both accumulate opacity (up to some threshold) along the ray given by the point,point or point+vector parameters. RIB needs some love to define which primitives have what type of opacity, but vex just uses the familiar masks (plus, now we have "categories" in H9.x).

As far as the speed of 3Delight's sss solution goes, please keep in mind that it is *pre-computed*, not done on the fly -- i.e: it's comparable to prman's pfilter process.

Anyhoo.... going from memory on all this, so I could be wrong about some of it.

Cheers.

[symek]

Thank you Mario!

I spent some time lately and things start to become little cleaner now. Also thanks to your shaders actually.

traverse() is something that still bothers me though.

As far as the speed of 3Delight's sss solution goes, please keep in mind that it is *pre-computed*, not done on the fly -- i.e: it's comparable to prman's pfilter process.

hmm. I don't know for sure. I don't have 3delight right now under my fingers but I don't remember any pre-pass in example I run. Maybe it was baked in geo... I also remember description of subsurface() which states it's a pure ray trace method. Can be wrong here of course...

cheers,

Simon.

[Mario Marengo]

traverse() is something that still bothers me though.

I'm looking at both the PRMan and 3Delight docs right now and I don't see any function called "traverse()" or similar... are you sure this is not some user function? Where did you see it being used?

hmm. I don't know for sure. I don't have 3delight right now under my fingers but I don't remember any pre-pass in example I run. Maybe it was baked in geo... I also remember description of subsurface() which states it's a pure ray trace method. Can be wrong here of course...

I remember (from tests I did about 2 yrs ago) that all the parameterization was done via RIB. IOW, it did something very similar to ptfilter (with almost identical parameters) except as a pre-pass at render time (instead of the user having to run ptfilter separately). And there was the expected delay while it built the octree and calculated the values before the frame started rendering. The smaller the mean free path, the longer the calculation.

As I said though, this was about 2 years ago, so maybe things have changed since then.

Cheers.

[symek]

Just to confirm that you were, Mario, of course right about SSS in 3delight. Their own Help appeared helpful here.

As to traverse() I cannot find it also but it's surely mentioned in introduction to ray tracing in PRMan in Siggraph Course, 2003... maybe was removed later...

thanks again,

Simon.