Raytrace vs reflection map

[Dries]

Trying to speed up rendering times, I tried use the "autogenerate reflection map" option. But I get very different results compared to raytracing. I suspect this has something to do with shaderspaces, but I already spacechanged my vector for the refl map lookup to object space since the autogenerated map is generated in object space (I read somewhere on odforce). Please take a look at my simple setup file and do a render test. I've used a switch in the dd_reflect shader to turn map on/off. Any other comments on how I can achieve this or what to expect are welcome as well.

Thanks.

DRie.s

dd_reflect.hip

[Mario Marengo]

Trying to speed up rendering times, I tried use the "autogenerate reflection map" option. But I get very different results compared to raytracing. I suspect this has something to do with shaderspaces, but I already spacechanged my vector for the refl map lookup to object space since the autogenerated map is generated in object space (I read somewhere on odforce). Please take a look at my simple setup file and do a render test. I've used a switch in the dd_reflect shader to turn map on/off. Any other comments on how I can achieve this or what to expect are welcome as well.

Thanks.

DRie.s

Hi Dries,

A couple of things:

1. You space-changed your vector, that's good. But the key word there is vector. So replace your "Space Change" vop with a "Direction Space Change" vop, and set it to "Direction Other Than Normal" (and world->object as well, of course). The "Space Change" vop takes care of transforming positions (points), for directional elements you need this other one.

2. Even then you will see a difference. This has to do with the fact that an environment map is indexed (looked up) by a direction only (relative positions are not accounted for). Another way of thinking about this is: in an env map, all objects are infinitely far away. There are ways to "shrink" this infinite sphere by intersecting the reflection ray against a virtual sphere of finite size, but that's another thread

3. Notice that, in order to disassociate the reflection from the camera, we transformed the reflection vector to object space. This may seem correct.... until the object rotates, at which point you'll see the (mapped) reflection rotate along with it, which is obviously wrong (assuming the intent is to have a true "environment", which typically means world space). <BTW, when I say "world" space, I mean exactly that; not camera space>. But since world space is not directly available in VEX, you need to pass an object reference to your shader (a NULL parked at {0,0,0} will do), and then transform to *that* space. In that case you'll need the "Space Change To Object" vop.

And finally; if you use a reference object to transform to, you need to keep in mind that the Z-component of your reflection vector needs to be reversed -> dir *= {1,1,-1}. This is because the camera space during rendering looks down positive Z, whereas the reference object, which comes from houdini, lives in a space where the Z-axis points the other way.

All of those comments apply to mapped reflections only; not ray-traced ones.

Hope I'm not confusing you more by saying all this...

[Dries]

Hey, thank you very much Mario. I needed exactly this sort of explanation as I'm taking my first steps in shading. VOPS seem a great learning tool, but sometimes you're better off learning shading "old school" as you prove with the workaround to get to world space.

At the moment I can easily get away with the difference caused by the "infinite sized sphere" issue. The solution you mention is interesting to know of.

I used to think when not touching shading that /obj was world space and that it was the same as camera space (in houdini), so SOPS would represent object space and I understand the use of transform objects (it is all transformation matrices that get consolidated, right?), but in shading world it is a bit more confusing. Especially because I don't know exactly how houdini handles spaces or how they are organised when you sent of a render. Any chapters in the docs that I should read? I thought by default the global variables where in world space coordinates, right? So why should I use a transform object placed at 0,0,0 instead of spacechange object-->world?

To be honest, I find it quite hard to find people who can answer these questions for me in an understandable way. Even Top houdini people here in the UK get confused and have hot discussions about "spaces" in houdini. Or at least that's what I like to think for now :-). So you did a good job Mario. Cheers.

DRie.s

[Mario Marengo]

I used to think when not touching shading that /obj was world space and that it was the same as camera space (in houdini), so SOPS would represent object space and I understand the use of transform objects (it is all transformation matrices that get consolidated, right?), but in shading world it is a bit more confusing. Especially because I don't know exactly how houdini handles spaces or how they are organised when you sent of a render. Any chapters in the docs that I should read?

Hi Dries,

Glad it helped. Sometimes I start writing something about spaces and, reading it back, one would think I was trying to carefully construct the ultimate tongue twister, lol!

The only documentation I can think of is what's in the VEX docs, which does mention some of the important bits, but nothing like a tutorial or anything like that.

Spaces in VEX are a bit of a pet peeve of mine; just ask some of the guys at SESI

Yes; the "world" I'm talking about is what we normally associate with /obj. And the key quality of that space, is that it does not move/change/transform relative to any other object in the scene. So that, from the POV of any object in the scene, it is *fixed*. In the shading contexts, our "world" (/obj) has become "cam1" (or whatever camera object is being used to render), and everything else is defined relative to *it*. But cam1 is really just another object inside /obj, and therefore allowed to move; which it does... often! In other words, inside a shader, *everything* moves relative to *everything* else.

This is fine (and quite in tune with reality and all), but it means that every time we want an anchor (an immovable object), we need to construct one, and pass it to the shader. It would be nice if Mantra constructed one for us and called it "world", then half the headaches would simply disappear right there.

But don't get rid of the painkillers yet; because Mantra *does* have a place it calls "world", and that's the same place the rest of us call "camera"... and the throbbing begins...

So yes; all global variables (the dimensional ones like vectors and normals -- scalars are dimensionless) *are* expressed in "world" space. But now you know what that means: they are expressed in CAMERA space. And so in your case, when you transformed the reflection vector from "world" to "object", you were transforming from "/obj/CAM" to "/obj/model".

I thought by default the global variables where in world space coordinates, right? So why should I use a transform object placed at 0,0,0 instead of spacechange object-->world?

And now the answer to this one is hopefully self-evident: you would be transforming from "/obj/model" to "/obj/CAM", a vector that was already expressed in "/obj/CAM" space. Whereas the other way (with a reference object) you'd be transforming from "/obj/CAM" (its native space) to "/obj/MY_WORLD_NULL", which presumably doesn't move at all (unless you want it to, but you're in control then), and is external to both "/obj/CAM" (VEX's "world") and "/obj/model" (VEX's "obj" in a surface shader).

Now for the good news:

An RFE was submitted to have Mantra provide a "world" space and make it accessible from the shading contexts (possibly all). So *hopefully* all the stuff I just said will become obsolete in the near future

[mark]

the first time i read that, i thought the universal translator stopped working and you were talking an alien language

but it makes sense! good explanation... cheers

[Dries]

Allright, very interesting indeed. I hope SESI will release a nice release note when they do change this.

Nice one Mario.