Hello there… i've got a simple question that Im sure you guys will be able to answer.

Im converting some RenderMan shaders to VEX and I cant find a global variable to resemble RMan's "du and dv“. Do I use
” Du(s) and Dv(t)" to get those values?. I need this for anti-aliasing my shaders. They are REALLY aliasing right now.

Thanks a lot

RCortes

See $HH/vex/include/prman.h

edward
See $HH/vex/include/prman.h

HI Edward! hows everything?

I did take a look at prman.h and I cant find any declaration macro for du or dv.. the closest I find is dPdu and dPdv and according to the Ri Spec 3.2 those 2 are “Derivitive of surface position along u or v” and what I need is the “Change in surface parameters” which is du, dv.

so the macros

#define dPdu (dPds/Du(s))
#define dPdv (dPdt/Dv(t))

are not really providing me with what I need

cheers

Rcortes

I've run into the same problem, and Du(s), Du(t) do not work. I'm going to try to work it out later tonight, but if someone knows the answer it'll save me a lot of trouble.

MichaelC
I've run into the same problem, and Du(s), Du(t) do not work.

If you meant Du(s), Dv(t) (instead of Du(t) ), then I believe it *should* work.

Here's how I understand it:

PRMan: dPdu -> VEX: (dPds/Du(s))
PRMan: dPdv -> VEX: (dPdt/Dv(t))
PRMan: du -> VEX: Du(s)
PRMan: dv -> VEX: Dv(t)


And the reason is that in VEX, dPds has already been scaled by what in PRMan would be “du” (and simmilarly, dPdv is pre-scaled by dv), thereby saving you from having to type “dPdu*du” or “dPdv*dv”, which is arguably the more frequent usage of these things…

Mario Marengo

MichaelC
I've run into the same problem, and Du(s), Du(t) do not work.

If you meant Du(s), Dv(t) (instead of Du(t) ), then I believe it *should* work.

Here's how I understand it:

PRMan: dPdu -> VEX: (dPds/Du(s))
PRMan: dPdv -> VEX: (dPdt/Dv(t))
PRMan: du -> VEX: Du(s)
PRMan: dv -> VEX: Dv(t)


And the reason is that in VEX, dPds has already been scaled by what in PRMan would be “du” (and simmilarly, dPdv is pre-scaled by dv), thereby saving you from having to type “dPdu*du” or “dPdv*dv”, which is arguably the more frequent usage of these things…

Thanks… now I know its my shader and not a bad use of the Du(), Dv() functions..

oops that was a typo. Anyway, what I did was port a Cel shader to VEX. Du(s) Dv(t) are required for the edge detector; they weren't giving me the right results. I'll have to look at again. I must've screwed up somewhere else.

Of course, you guys got me all woried about this whole thing… again … thanks! :evil: :wink:
So I went and did some more tests… again…

Here's PRMan's dPdu versus Mantra's dPds/Du(s) along with an extreme closeup of the right-hand side edge…



Cool; things are looking pretty close
Now. Same thing with du…



OK. In the du/dv case the differences at the edges are a bit more pronounced than what I would have expected: the Mantra edges look “rattier”. However!… I'm still looking into this so I don't want to jump to any conclusions.

I *do* know (from having just tested it), that even though the “ratty” edges *look* like they may have something to do with sampling of the geometry, it *doesn't* – that end of things is pretty much identical between the two renderers when Mantra's pixel filter is set to “gaussian 2 2” or thereabouts. So, no; it appears to be related to the way the two calculate the derivatives. I'm currently testing the “extrapolate” and “smoth” options (for Du(), Dv(), etc) in Mantra, and also the “extrapolate” and “centered” derivative “Attributes” in PRMan…. although I haven't yet been able to get a better match from tweaking those…

It should be pretty obvious though, that they are pretty close to each other – we're talking about two completely different renderers here… still… should one expect derivatives on a primitive sphere to vary at all? are the differences I'm seeing at the edges too much? dunno… and I'm definitely not qualified to answer any of that. All I can say is that one looks smoother than the other, but the smoother one may be “incorrect” for all I know…

Oh; and just as a disclaimer: I'm not interested in forcing Mantra look exactly like PRMan – Mantra is Mantra and PRMan is PRMan and they're both excellent – but after years of using PRMan exclusively, making these little comparisons help me understand Mantra better, 'sall…

Cheers!

I should have mentioned what I'm using for these tests:

Mantra: VMantra 6.1.149 compiled on 09/29/03
PRMan: RenderMan 11.5 (RH72.intelP3)

Both at default settings, except Mantra's pixel filter was set to “gaussian 2 2”

Shaders:

Mantra: dPdu test:
surface testdPdu() { Cf = abs(normalize(dPds/Du(s))); }

PRMan: dPdu test:
surface testdPdu() {
vector v=normalize(dPdu);
Ci = color(abs(xcomp(v)),abs(ycomp(v)),abs(zcomp(v)));
}

Mantra: du test:
surface testDu() { Cf = Du(s)*100.0; }

PRMan: du test:
surface testDu() { Ci = du*100.0; }

Note to SESI: We'll be in touch about the fee for Mario torture-testing your renderer…

:twisted:

You had him in a knot all afternoon - he was luvvin' it.

Cheers,

J.C.

You had him in a knot all afternoon - he was luvvin' it.

Yeah – the textbook quality comparison figures kinda gave that away

What happens if you turn off the pixel filtering and turn smooth off for mantra?

edward
What happens if you turn off the pixel filtering and turn smooth off for mantra?

You get this:



Which makes sense given the entry in the docs for “smoothing”:
Derivative “smoothing” will cause the magnitude of the differentials to be adjusted non-uniformly over patches
Since dPds is the differential and Du(s) is its magnitude, then with “smoothing” off, Mantra gives you a single value for Du(s) across each patch. AFAIK, there's no equivalent to this switch in PRMan.

Note: the sphere was placed quite far from camera (i.e: it doesn't fill frame) to accentuate any edge artifacts. But it also means you don't see as many patches as you'd expect in this test. Not to mention that at 8-bit output, it would take some careful false-coloring to get those 1e-4 changes in Du(s) between some patches…

Given the above though, the really interesting question becomes: what does an expression like dPds/Du(s,“smoothing”,0) give you ?!?
Since dPds/Du(s) is the only way to get the actual derivative (this value does not exist as a global in Mantra), you end up with… what?… dPdu*du/Du(s,“smooth”,0)? … a differential with bogus scaling?



The one thing that I can't seem to get anywhere with is the “extrapolate” option… no matter what I throw at it, I can't see any effect – Can anyone describe a situation where this option would make a visible difference?

Mario Marengo
Derivative “smoothing” will cause the magnitude of the differentials to be adjusted non-uniformly over patches
Since dPds is the differential and Du(s) is its magnitude, then with “smoothing” off, Mantra gives you a single value for Du(s) across each patch. AFAIK, there's no equivalent to this switch in PRMan.

Actually, I believe that there's a compile time switch to turn off smoothing in shader . This means you have to recompile your shader to change the smoothing behaviour.

Mario Marengo
The one thing that I can't seem to get anywhere with is the “extrapolate” option… no matter what I throw at it, I can't see any effect – Can anyone describe a situation where this option would make a visible difference?

The most obvious way to see what the extrapolate option does is to write a quick little shader to compute normals with an option to turn extrapolate on/off. Use the SHOP viewer to run your shader on a sphere or torus and watch the patch boundaries appear and disappear.

surface
foo(int extrapolate=1)
{
vector nn;

nn = computenormal(P, “extrapolate”, extrapolate);
Cf = normalize(nn) * .5 + .5;
}


It's most noticable if you view the geometry with a low level of detail.

Extrapolation will estimate derivatives at the patch boundaries slightly differently. It estimates (by extrapolation) what the values on the other side of the patch are. This should give smooth values across smooth surfaces. However, it should be noted that with high frequency displacement shading, that extrapolation may attenuate discontinuities. Since the surface isn't smooth, the “guess” at what the adjacent patch value is might actually be more inaccurate than a non-extrapolated value. When this happens, the patch boundary will become more noticable. Still, it might just as “right” as a non-extrapolated value, so it's probably safe to have it turned on all the time.

Hope this helps.

Mark.

mark
Actually, I believe that there's a compile time switch to turn off smoothing in shader . This means you have to recompile your shader to change the smoothing behaviour.

Hmmm… gotta look at the docs again… which might take me 5 days or so…sheesh!, I complain about the VEX docs, but the PRMan docs (w.r.t RSL) are all over the place – the info's usually there, but good luck finding it! :roll:

mark
The most obvious way to see what the extrapolate option does is to write a quick little shader to compute normals with an option to turn extrapolate on/off. Use the SHOP viewer to run your shader on a sphere or torus and watch the patch boundaries appear and disappear.

Aha!
Yup. Got it now, thanks.

So…..

If we wanted to take advantage of these controls in a generic way (and expose them in our shaders), we can't use dPds and dPdt anymore since these options are already cooked into their values, so we build our own… but then what are the settings when the globals (dPds|dPdt) get computed?

After some testing (on a bunch of different geometry), I'm getting the best matches with “extrapolate” ON, and “smoothing” OFF (which is the reverse of what the docs give as default).

Can you confirm this? Or is there something wrong with my test?
Here's what I'm using to check:
#pragma choice test “N” “Normals”
#pragma choice test “dP” “Derivatives”
#pragma label amp “Amplitude”
#pragma label extrap “Extrapolate”
#pragma hint extrap toggle
#pragma label smooth “Smoothing”
#pragma hint smooth toggle
surface
testExtrapolate(string test=“N”; float amp = 1; int extrap=1,smooth=1)
{
vector global,local;
if(test==“dP”) {
global = normalize(dPds);
local = normalize(Du(P,“extrapolate”,extrap,“smooth”,smooth) *
Du(s,“extrapolate”,extrap,“smooth”,smooth));
} else {
global = normalize(N);
local = normalize(computenormal(P, “extrapolate”, extrap,“smooth”,smooth));
}
Cf = abs(global-local)*amp;
}

Thanks Mark!