Renderman space transforms fo VEX

[Mcronin]

I'm trying to work through a Renderman shader in VEX but I'm stumped with something.

In RSL

transform ("screen", P)

This function transforms P in screen space, screen is a perspective corrected version of camera space. Is there an equivalent for VEX?

Similarly

vtransform("screen", dPdv)

I don't know what vtransform does exactly but there's screen space again. I'm guessing it's vector transform, but what's the difference between vtransform and transform if both ouptut vectors and take vectors as arguments? I understand dPdv to be dPdt/Dv(t). Is that correct?

[Mario Marengo]

This function transforms P in screen space, screen is a perspective corrected version of camera space. Is there an equivalent for VEX?

Hi Mike,

If I recall correctly, this is the same as NDC space. So that RSL's "screen space" is a.k.a normalized device coordinates (NDC), and "raster space" is a.k.a physical device coordinates (PDC) where its dimensions are in pixels. I'm not totally 100% on this though, and I don't have the books infront of me at the mo. But I read "perspective corrected" as "perspective removed", i.e. orthogonal. And if normalized, then -> NDC.

Anyway; if I'm right, then in VEX you'd just use toNDC() and fromNDC()

I don't know what vtransform does exactly but there's screen space again. I'm guessing it's vector transform, but what's the difference between vtransform and transform if both ouptut vectors and take vectors as arguments?

The vtransform() function in RSL is, as you guessed, used for transforming vectors; unlike transform(), which is used to transform points. As I understand it, vectors are treated differently in that they are considered "free" vectors, and so don't get any translations applied during transformation. Normals have another set of issues and so get their own version of transform as well -> ntransform().

Same thing in VEX, where the general form is: [from_code|to_code]_[type_code]space(...)

So, for example, wo_space() transforms points (no type_code for points) from world- to object-space, ow_vspace() transforms vectors from object- to world-space, etc.

I understand dPdv to be dPdt/Dv(t). Is that correct?

Yes; that's correct. Although, if you want to take advantage of some of the derivative options, I'd recommend using Du(P [, options...]) and Dv(P [, options...])

Cheers!

(P.S: Nice work on the wiki Matrix stuff! )

[Mcronin]

Thanks for the informative answer. Translating some of this stuff from Renderman is quite confusing to me and I really appreciate the help. Now I should be able to get this shader worked out.

The Matrix Odwiki stuff... That's turning into a real project. I started it though, so now I have to finish it. I figured out how to do some formatting so it looks nicer but it's a loooooonnnnnngggg way from being complete. I figure if I do a little bit everyday it should be done in maybe a week or so. I keep finding errors in it so feel free to correct it if you notice any.

[Mcronin]

I just tried your suggestions and toNDC is exactly what I needed thanks again

[Mario Marengo]

I just tried your suggestions and toNDC is exactly what I needed thanks again

You're welcome; I'm glad it worked -- I wasn't too sure about it since one hardly ever uses "screen space" because prman also has an "NDC space"... can you say "redundant"?

About the wiki stuff... yep; I know what you mean. I think I opened my own can of worms with the shader library thingie -- it's going to take a long while to finish at the rate I'm going, lol!

But please keep it coming, it's a wonderful summary you're putting together there! I looked through it again today and didn't notice any errors (a couple of tiny typos in the text, not the math -- I'll try to fix them next time I'm there).

And, by the same token, please feel free to go in and correct my stuff if you see any blunders!

Cheers!

[Mcronin]

Well there's a lot of redundancy in PRMan it seems; point, vector, normal, and color types... They're all vectors and it bugs me a bit. I'm sure there's good reasoning behind making the distinction for different types but I don't comprehend it.

This information you gave me is excellent. I'm writing an NPR shader and hopefully an edge detection COP (something better than Wren and more robust than the current Edge Detect COP) for a multipass cartoon toolbox of sorts. Right now it does sort of standard toon shading, but I needed to figure this out because I want to add a stippling effect to the shader, like a Lichtenstein painting

or maybe Seurat

About the shader library. I've been reading what you've written and it's very good and I saw the libraries that you and Mark have been adding. Maybe exapnding the prman library that ships with Houdini would also be a good idea.

[Mario Marengo]

Hi Mike,

That sounds really interesting!

I haven't kept up with the NPR side of rendering much since the type of work we normaly do doesn't require it. But I was recently working on something completely unrelated and looking for uniform point distribution methods, and came across a good paper that deals with pretty much what you're doing. You've probably already seen it, but just in case, its called "Fast Primitive Distribution For Illustration" by Secord, Heidrich, and Streit. You can download the full text at

http://www.cs.ubc.ca/~heidrich/Papers/RW.02.pdf

It's from the 2002 Eurographics workshop on rendering. They end up using a Halton sequence with (I think) 3 and 5 for the primes (this is the bit that I was interested in at the time). Worth a read if you haven't already.

Maybe exapnding the prman library that ships with Houdini would also be a good idea.

Yep; that's a good idea; although I don't think that will ever become as simple as "include this file and RSL away". But I agree that it can be improved... hmmm

Cheers!

[Shiny]

Sorry, I'll go on this post - while I've some question around problems discussed here.

I have no clearness about space transforms at VEX at whole. The problem is next: any globals defined at "camera" space, but all functions are orinted to convert between object/world/texture spaces. Ok, but we have no any dat at that spaces, excluding passed by users params. I even dont know, what I have to think. May be "texture" space is identical to "camera" (like current Pixar's RSL implementation assumes "shader"/"object" or "camera"/"current" spaces as identical)/ As I seem, I just don't know about some nig, but what about ? Thank you!

[Mario Marengo]

Check out this other thread here

As far as "texture" space goes... I believe it's the space defined just before the object instance (in the IFD) -- i.e: the space you set in the "Shading" tab of your object under "Shader Space". If this is correct (and I'm not 100% since I haven't used it yet), then it would be the equivalent to "shader" space in PRman. So, if you leave everything at default, and don't specify something other than "This Object" in that field, it would end up being equivalent to "object" space (in VEX).

Cheers!