gather() in mantra

[TheDunadan]

Hi,

i'm wondering if there is an equivalent function in VEX, that resembles the gather() function of prman ?!

surface gather_mirror (float samples = 1;

[Mario Marengo]

Hi Jens,

I saw in the manual, that the trace() call for Mantra allows as well to set an cone angle etc. I'm wondering if

Cf = trace(....);

in VEX would give me the same result.

Well... yes and no

Yes for the specific example you gave -- i.e. gathering surface color by tracing over a cone/hemisphere with a cosine distribution. In this particular case, trace() is equivalent to gather() (and it's likely more efficient too).

But the mechanics are different: gather() is a loop, whereas trace() is a function. This means that inside the gather() loop you can inspect each ray (that hit) and do stuff accordingly. Not so with trace().

So gather() gives you *per-ray* flexibility (you could send some/all to some cache according to some criteria, for example), whereas trace() goes off and does the summation plus whatever importance-weighting is applicable (cosine-dist by default) and gets back to you with the finished goods

Note that this means that you wouldn't need to divide the result of trace() by num-of-hits as in the prman example (not that you'd have access to the num-of-hits anyway )... besides, that would be a linear weighting and wouldn't account for the cosine distribution.

Another thing, I PRman allows rayinfo(), to allow a rather easy way to identify rays. Is there something similar in VEX ?! Seems quite useful to be able to lable rays like this.

Yes, it is quite useful and, unfortunately, no, there is no direct equivalent in VEX... at the moment. I remember placing an RFE for this during 6.1 beta. Not sure what the status is on that, and I haven't been able to touch 6.5 yet because of production. (Anyone out there testing 6.5 can confirm if we have ray labels yet?)

For *some* cases (namely when you don't need a ray label) you can get away with using getraylevel() and getglobalraylevel() for direct tracing and GI tracing respectively. A ray level of 0 represents a camera ray, and anything above that is a bounced ray.

Not the same, but could be forced into service depending on what you're doing...

Cheers!

[TheDunadan]

Thanks for the reply. Never dealt with raytracing materials before and when I saw the Prman 11 Documentation I was positively surprised how "easy to read" many of the sample codes are: Such as the notes on the Transluency and Subsurface Scattering.

Translucency and Subsurface Scattering

Since I have no access to Prman11 I thought I might be able to transfer these shaders easily to vmantra.

If I understood you right, the lacking "per ray" control won't allow me to do this "weighting" of each individual ray with a single trace() call, but with a loop I could do the same manually. (Later today I'll try it out anyhow )

// From Brute-Force Example of SSS Examaple
gather("illuminance", P, -Nn, PI/2, samples, "label", "subsurface",
            "surface:Ci", raycolor, "ray:length", dist) 
                {
                    sum += exp(-extcoeff*dist) * raycolor;
                }

Out of intrest, how does the performance of vmantra compare to Prman ?!

[Mario Marengo]

I was positively surprised how "easy to read" many of the sample codes are: Such as the notes on the Transluency and Subsurface Scattering.

I had a feeling that's where you were going with all of this

If I understood you right, the lacking "per ray" control won't allow me to do this "weighting" of each individual ray with a single trace() call, but with a loop I could do the same manually.

That's right. Even if you set the distribution to "uniform", you still get a single number back: the result of the summation divided by the num-of-hits -- i.e: the average contribution from the solid angle. So you have no way in which to impose the exponential falloff that you see in that code fragment, for example.

... that's not the same as saying that there's absolutely no way to do this kind of thing in mantra... but, at the moment, this would mean hand-coding an ss-cache as a vex "shadeop" (dso)... how "comfy" are you with C++? are you on Linux, or Windows? (I think you need the HDK to do vex dso's for Windows)... anyway; things get more involved if you go that route.

Alternatively, you can try to come up with a way to build your cache in SOPs (which in some ways makes more sense since that's where the geometry gets defined). In fact there is one such approach that was submitted by Simon Barrick here.

(Later today I'll try it out anyhow )

Cool!

Out of intrest, how does the performance of vmantra compare to Prman ?!

Overall, very favourably. There are a thousand details, of course, but in general, Mantra's speed is very good. One could even argue that perhaps raytracing is a tiny bit faster in Mantra. But for a realistic answer you'd need to put them both through a whole series of well-thought-out benchmark scenes. Alas, I personally haven't had the time to do that kind of thing properly, and AFAIK, there isn't any such thing "out there" either.

Cheers!

[digitallysane]

Hmmm, reading throgh the material at this link:

http://www.derzwerg.net/pixar/docs-5.5/

will maybe help me finally understand how Mantra works when it comes to GI and stuff (since it seems pretty similar with RenderMan).

I hope that the new docs in 6.5 will provide similar, in depth information, so it actually becomes useful when it comes to rendering with Mantra.

Dragos