Hi all
VOPs question..
The only way i seem to be able to orient my environment map to stay in world space (rather than camera space)with the Chrome Env VOP is by changing space to reference another objectt in the world - in my case a geo with a null at sop level (i couldnt get it working with just a null at object level)
This is fine as it allows me to move the camera, and the environment map stays nicely in line with the world….however….
..how can i make it so that it doesnt need to do this? I mean, everytime i want to use an environment map with my shader in this way, I will have to have an object to reference - as will anyone else wanting to use it.
- which leads me to add that another problem seems to occur when i create a parameter to choose the object at shop level, it doesnt work at all! When i just choose an object in VOPs and make it default (ie dont create a parameter to choose it at SHOPs level) it works fine.
confused, would appreciate help
thanks guys
J
Object Space Change..Chrome Env
8332 14 3- JohnnyBGoode
- Member
- 55 posts
- Joined: July 2005
- Offline
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
You need to apply a space change from world to object for both N and either I or what ever vector you are using to reference in to the environment map.
World being camera space in the shading context. That is why when you move the camera, your environment map moves with it.
World being camera space in the shading context. That is why when you move the camera, your environment map moves with it.
There's at least one school like the old school!
- JohnnyBGoode
- Member
- 55 posts
- Joined: July 2005
- Offline
Hey Jeff,
Thanks for that - i had figured that out - i just wondered why in a shading context i had to reference another object to keep the Env map as the correct orientation.
Its just quite annoying to have to have that each time i use the shader - to create a null and reference it
Surely - as spherical environment map there should be some kind of option?
I guess the logical default would be to stay in orientation to the camera. so that as an object moves it looks like it is reflecting back the environment - but as i want to move the camera too, its really annoying that i cant set it up to keep orientation to the 3d space, without each time making a null.
Thanks for that - i had figured that out - i just wondered why in a shading context i had to reference another object to keep the Env map as the correct orientation.
Its just quite annoying to have to have that each time i use the shader - to create a null and reference it
Surely - as spherical environment map there should be some kind of option?
I guess the logical default would be to stay in orientation to the camera. so that as an object moves it looks like it is reflecting back the environment - but as i want to move the camera too, its really annoying that i cant set it up to keep orientation to the 3d space, without each time making a null.
- Simon
- Member
- 2199 posts
- Joined: July 2005
- Online
As a monumentual hack you could run three axis oriented vectors through the the camera transform and then use these to calculate the inverse camera transform matrix and apply that to your shader. Never tried this though and it would probably be way slow.
The trick is finding just the right hammer for every screw
- Mario Marengo
- Member
- 941 posts
- Joined: July 2005
- Offline
Keep it coming guys! Maybe all this talk will help move this old, old RFE from “bottom-of-the-pile” to “bottom+1”
@jeff: Object space would only work if there were no transformations going on in SOPs, which is unreliable at best.
@Johnny: Using camera space (which is “current” space in both Mantra and PRMan, and also “world” space in Mantra) is probably the least reliable as the camera is probably, of all things, the most likely to move.
@Simon: Hehe… yeah, and as with all the “monumental hack” brethren, there's always the problem of finding a way to guarantee that this information is always available to all shaders… without the user having to do anything special (which is what a global world space would be)… otherwise you might as well just use a reference object
Maybe it can be argued that dropping such a shader-specific thing as “world space” in favor of the more generic “named spaces” is a GoodThing – what with VEX being so much more generic than, say, RSL and all. But in practice, I think it just ends up making things less intuitive for the user… which IMHO is a BadThing. We need/want/love named spaces, but we also need/want/love a global world space (at least in the shading contexts).
But if whining won't get us a global world space, then may I suggest a compromise RFE?
@SESI: Could we add a matrix-valued space:currenttoworld query to the renderstate() function?
The renderstate() function is, after all, pretty shading-context specific…
(Oh, and it would also be grand if we could change the docs so they stop referring to “current” space as “world” space, but I guess it's too late for that now since it would mean changing all those wo_ ow_ functions too… nevermind).
How about it?
@jeff: Object space would only work if there were no transformations going on in SOPs, which is unreliable at best.
@Johnny: Using camera space (which is “current” space in both Mantra and PRMan, and also “world” space in Mantra) is probably the least reliable as the camera is probably, of all things, the most likely to move.
@Simon: Hehe… yeah, and as with all the “monumental hack” brethren, there's always the problem of finding a way to guarantee that this information is always available to all shaders… without the user having to do anything special (which is what a global world space would be)… otherwise you might as well just use a reference object
Maybe it can be argued that dropping such a shader-specific thing as “world space” in favor of the more generic “named spaces” is a GoodThing – what with VEX being so much more generic than, say, RSL and all. But in practice, I think it just ends up making things less intuitive for the user… which IMHO is a BadThing. We need/want/love named spaces, but we also need/want/love a global world space (at least in the shading contexts).
But if whining won't get us a global world space, then may I suggest a compromise RFE?
@SESI: Could we add a matrix-valued space:currenttoworld query to the renderstate() function?
The renderstate() function is, after all, pretty shading-context specific…
(Oh, and it would also be grand if we could change the docs so they stop referring to “current” space as “world” space, but I guess it's too late for that now since it would mean changing all those wo_ ow_ functions too… nevermind).
How about it?
- Simon
- Member
- 2199 posts
- Joined: July 2005
- Online
Hey Mario, I'm definetely in the add world space to VEX camp, this gets my vote every time, ever since it first bit me in the arse :twisted: (excuse my french)
Is this Mark just being stubborn or is there something that just makes this inheritently difficult to add? :shock:
Is this Mark just being stubborn or is there something that just makes this inheritently difficult to add? :shock:
The trick is finding just the right hammer for every screw
- wolfwood
- Member
- 4262 posts
- Joined: July 2005
- Offline
As far as named coord spaces go, using vector otransform() and friends is pretty close.
In IFD you can define a named coord system by using the ray_space command.
ray_space /obj/null1
ray_transform 1 0 -0 0 0 1 -0 0 0 0 -1 0 0 0 5 1
You can dump those ray_space commands to the IFD stream by turning on the “Output Xform to IFD/RIB” on the Null SOPs, its on the second tab.
@JohnnyBGoode (this is why nulls weren't working)
Then you can reference those coord spaces with otransform.
I think its fairly common to drop a null at the world origin and then call that null WORLD or something and then reference that null from the shader to get a reference to world space.
Its different from RSL…but i'm pretty sure all the functionality is there. (Then again its raining outside).
I still agree with Mario and Simon though. Just reminding everyone you can still do it, just painfully.
In IFD you can define a named coord system by using the ray_space command.
ray_space /obj/null1
ray_transform 1 0 -0 0 0 1 -0 0 0 0 -1 0 0 0 5 1
You can dump those ray_space commands to the IFD stream by turning on the “Output Xform to IFD/RIB” on the Null SOPs, its on the second tab.
@JohnnyBGoode (this is why nulls weren't working)
Then you can reference those coord spaces with otransform.
I think its fairly common to drop a null at the world origin and then call that null WORLD or something and then reference that null from the shader to get a reference to world space.
Its different from RSL…but i'm pretty sure all the functionality is there. (Then again its raining outside).
I still agree with Mario and Simon though. Just reminding everyone you can still do it, just painfully.
if(coffees<2,round(float),float)
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
I will querry the bug/rfe database and see if there is an existing entry. If there is, I will give it a touch. If not, I will submit it as it has been asked for before.
Now I wonder why this issue hasn't been raised as vocally before. I am now a very big believer in using environment reflection maps and per-object reflection maps and have had the issues that have been covered here. I use the trivial solution of an object space change when showing vops to artists but resort to proper defined spaces (now much easier with the additions to the null object) to lock down the environment maps.
Perhaps it is too easy to just raytrace everything in Mantra and live with the longer render times… PRMan didn't have embedded raytracing until PR11.5 ( working that is ) so it is a well defined process in that world.
Now I wonder why this issue hasn't been raised as vocally before. I am now a very big believer in using environment reflection maps and per-object reflection maps and have had the issues that have been covered here. I use the trivial solution of an object space change when showing vops to artists but resort to proper defined spaces (now much easier with the additions to the null object) to lock down the environment maps.
Perhaps it is too easy to just raytrace everything in Mantra and live with the longer render times… PRMan didn't have embedded raytracing until PR11.5 ( working that is ) so it is a well defined process in that world.
There's at least one school like the old school!
- Mario Marengo
- Member
- 941 posts
- Joined: July 2005
- Offline
jeff
I will querry the bug/rfe database and see if there is an existing entry. If there is, I will give it a touch. If not, I will submit it as it has been asked for before.
Much appreciated, sir.
jeffWell, I guess it depends on what you mean by “vocally”, because, if I recall correctly, I opened a topic on this very subject back in the “Houdini 6.0 Early Access Feedback” days (or thereabouts) which I believe started with the line:
Now I wonder why this issue hasn't been raised as vocally before.
“AAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRGGGHHH!!!!!”
…in a large font, bold, and underlined
Look it up if it's still archived somewhere… anyway; that's about as “vocal” as I can manage in a public forum
jeff
Perhaps it is too easy to just raytrace everything in Mantra and live with the longer render times…
Noooooooooooo!!
Ray tracing in Mantra is very nice and fast and we all love it, but you don't want to go raytracing everything all the time … besides, many times you just want to do an environment() call for reasons other than your plain-vanilla reflections… (and of course I know you know all this, but I thought I'd be more vocal on this issue ).
jeff
PRMan didn't have embedded raytracing until PR11.5 ( working that is ) so it is a well defined process in that world.
…and that world has a built-in global world space… (now I'm being whiney, redundant and vocal all at the same time… I should swap avatars with Jim ).
Cheers!
- JColdrick
- Member
- 4140 posts
- Joined: July 2005
- Offline
- wolfwood
- Member
- 4262 posts
- Joined: July 2005
- Offline
- JohnnyBGoode
- Member
- 55 posts
- Joined: July 2005
- Offline
wow - i set about putting together my fist ever shader - in VOPs no less…
…and before you know it, ive dug up an old zombie that comes back to haunt Mario - ooops.
Thanks for all your help - ive got it working (with a null pffff!), but a revision would be cool.
As a complete newbie, I thought it was my fault that it wasnt working, but it seems my instincts were right.
Cheers all
J
…and before you know it, ive dug up an old zombie that comes back to haunt Mario - ooops.
Thanks for all your help - ive got it working (with a null pffff!), but a revision would be cool.
As a complete newbie, I thought it was my fault that it wasnt working, but it seems my instincts were right.
Cheers all
J
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
- JohnnyBGoode
- Member
- 55 posts
- Joined: July 2005
- Offline
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
http://www.sidefx.com/journal/ [sidefx.com]
That shows you the daily revision log for the currently released Houdini.
It should be your home page in your favourite browser! 8)
That shows you the daily revision log for the currently released Houdini.
It should be your home page in your favourite browser! 8)
There's at least one school like the old school!
-
- Quick Links