The other flavor of occlusion() in vops land

[ihab]

Hi,

I've created a simple shader in vops that outputs bent normals as well as occlusion to some AOvs. To do that i had to use an inline vop to make use of the other flavor of the occlusion() function available in vex land but forbidden to sissy kids like me trying to use vops .

Anyway, The shader is working fine but i'm stuck with some details;

What is the correct space to output bent normals?

Should it be in object space, shader space, world space, camera space, NDC space?

I've noticed in the "show normals" shader shipped with houdini that the normal is multiplied by 0.5 then 0.5 is added to the result before it's piped into the Cf.

Is there a specific reason to so? I've noticed that this results in more contribution of the Z component of the normals resulting in more data in the blue channel of the normal pass.

Should i do the same with my bent normal pass? isn't this cheating? i mean why manipulate the normals but multiplying?

Thanks in advance.

[Mario Marengo]

What is the correct space to output bent normals?

Should it be in object space, shader space, world space, camera space, NDC space?

Whichever space will be useful to you at comp time. There's no "right" answer here -- space:camera or space:world are the typical ones, but it depends on whatever algorithm you'll be feeding them to at comp time.

I've noticed in the "show normals" shader shipped with houdini that the normal is multiplied by 0.5 then 0.5 is added to the result before it's piped into the Cf.

Is there a specific reason to so? I've noticed that this results in more contribution of the Z component of the normals resulting in more data in the blue channel of the normal pass.

Should i do the same with my bent normal pass? isn't this cheating? i mean why manipulate the normals but multiplying?

All unit-length vectors will have a range of [-1,1] for each axis. What that shader is doing is "pretty-fying" the output so you don't end up looking at negative values -- *0.5+0.5 puts them in the range [0,1] so there are no negative values.

Absolutely, categorically, do not do this when actually exporting the vectors -- this is only done to make the display more pleasant to look at, that's all. (and it's equivalent to pressing the "Adapt to Full Pixel Range" button on Mplay for a floating point image).

HTH.

[ihab]

Hey thanks for the swift reply!

One more thing: should i faceforward() err.. front face the output bent normal ? I mean wouldn't this be a more accurate method to bring the values to positive land?

Cheers,

Ihab

Edited September 10, 2008 by ihab

[Mario Marengo]

One more thing: should i faceforward() err.. front face the output bent normal ? I mean wouldn't this be a more accurate method to bring the values to positive land?

No. The front-facing normal would have been used (if at all) for determining the hemisphere for sampling. That's as far as that front-facing business should go -- it should not be used to further modify the resulting bent normal.

What I meant in my last post is that there's no need to put things into "positive land" -- actually, there's a need to *not* put them in "positive land". Their little world includes negative values and that's where they should stay.

In short: with the exception of normalizing and/or transforming them to a different space, you should leave them as they are (no front-facing, no *.5+.5, no nothing).

Cheers.

[ihab]

Thanks Mario.

[ihab]

ok .. back with more problems. I've noticed in the help that i can use the "missed direction" vector i.e the bent normal vector to sample an environment map to create a fast G.I shader. Now i have a few options to do that.

1. In vops i can pipe the bent normal into an environment vop and add it to my shader.

2.In the inline vop i can plug in the string pointing to the environment map and use it to add an "environment" argument to my inline occlusion function.

3. Use the "envlight" argument to pass an environment light name to the inline occlusion function.

which way is the correct way to go? and if they are all "correct" which way will create a more effecient shader in terms of render time?

Thanks,

ihab

Edited September 12, 2008 by ihab

[ihab]

anybody out there?

[Mario Marengo]

anybody out there?

Don't have Houdini in front of me now, but if I remember correctly, the environment-related optional arguments do not apply to the second form of the occlusion() function. So... I guess that would leave you with only option 1 (unless I'm misremembering things).

There was a thread not long ago that touched on usages of the visibility version of the occlusion() function. You might find some useful stuff there as well.

[ihab]

thanks again

I will take a look at this thread, i remember i bookmarked it a couple of weeks ago so that i would study it closely but totally forgot.

Cheers

[rob]

Hey ihab ,'

That thread will cover all you need ! I use that shader in production now .....

rob

Edited September 13, 2008 by rob

[ihab]

hey rob, long time mate!

i got thrown by accident into your direction. playing with shading in houdini is addictive. i created a shader myself and i'm cleaning it up right now. sadly i'm using it in production without cleaning up, hehe the usual story.

cheers,

ihab

[ihab]

Hi,

I've created a bent normal shader that outputs multiple stuff aside from the bent normal pass. It outputs:

1. Normal Pass

2. Occlusion Pass

3. Pz

4. Reflection Pass

5. Environment pass

And the RGB channel holds a slap comp of all these channels ready to use if you like without using any of the passes.

I created a mantra rop that outputs all the different passes into a single 32-bit EXR file.

I hope it's useful to anyone. It started as a bent normal pass and ended up this way during my work in a commercial.

Thanks Mario for the help.

Cheers

bent_normal.hip