So I ran into a fun problem.Some renderers sets P to 0.0 for rays that hit the environment... but to me this is wrong. Because if I want to make a shader that applies a screen image, I need to be able to do transform("screen", P) .... which is obviously impossibru for 0,0,0 coordiate.
I think a good way to "fix" this is so simply invent some point that is along the ray from the camera to the environment... most easily, the camera position + I ?
But the specification of OSL is silent on this, so I can't put much force behind my argument.
I think that doing transform("screen", P) should be possible also in an environment shader, and for that to happen, P can't be zero.....
Sorry but does the spec guarantee that transform("screen", I) works?!? And what would that even mean? Transforming a view direction to a screen pixel? That makes zero sense to me....
I don't think this makes sense. If I do this, the same shader mapped on an object would return the wrong thing in a reflection, rather than back-converting the hit point P to where it is in screen space....
if instead the spec is augmented to specify that P, in an environment context, must have a value that is valid to convert to screen space, everything would work fine and consistently.....I don't really see the harm in doing this - it simplifies things a lot...?
Ok I found a real world case where this is breaking things, and the trick to transform 0 to camera isn't working:
I wrote a ground projection shader for max 2021... and in my viewport backend (which do set P to a (in my mind) sensible value in environment hits) I can compute the environment rays intersection with the virtual ground plane. So the ground these boxes are standing on doesn't exist, it's the environment, but in my shader I project it to the flat plane. My viewport code does the right thing, because it has the current P that defines the real ray:
But in Arnold, where I do not have this value, and have to back-transform "0" from camera space, it turns out that it is just giving me the camera origin, not the origin of that particular DOF ray.
So I get the wrong things (as if the ground was at infinity):
I think this is broken. I think P, in an environment shader, should be decreed in the spec to be "on the ray", so I can make computations like this properly.
On Tuesday, January 21, 2020 at 9:31:15 PM UTC+1, Master Zap wrote:*Boink.*
Larry? Help :)/Z
On Tuesday, December 3, 2019 at 2:52:18 PM UTC+1, Master Zap wrote:Imagine I have a reflective teapot on top of a screen-mapped plane.When the reflection ray of the teapot hits the plane, I expect it to pick up the screen-mapped pixel projected back into screen space.
I.e. I expect transform("screen", P) at that intersection to return what I want. (Which it does, today).Now, assume I want to use the same screen-mapped shader in my environment. Currently I can't (in the P=0 renderers) because suddenly, what was valid in the reflection, is suddenly not valid for the camera ... if it hits the object... but it works if it hits the plane ... uhm... that's quite inconsistent and weird to me./Z
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/2178f0ee-ed49-4f83-ad66-5d99baf41910%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/8792DE6D-0B44-4CB0-97AC-65FE83755486%40larrygritz.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/CAM-xo90VOAbhC_zBTy7s24QWzpB7yxc_qEO4gPpgQ2_HvR%3DXWA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/11AF8F6A-A05E-4594-9CE7-AC89720D47D8%40larrygritz.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/CALu_sPzpWkj%3Dv25xkMsc25kau4Tmp56sF7noyuXt1gaP65GA4Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/37A72AC9-06E8-4487-9259-F891F3380E53%40larrygritz.com.
I will test it as soon as I have some time (I'm confined at home with children so finding time is err... complicated)
Alternatively, I think that if we define an "environment" space, which has the same transform-to-common matrix than "world" except the last column is set to zero, then I believe:transform("environment", "screen", I)Will provide the desired results, if 'I' is properly defined as the view vector for environment shaders. This needs to be validated, but I believe it is geometrically correct.
, and anyway OSL does not provide matrix * vector multiplications.
The real bottom line is stop trying to write a renderer in a shader. It was a bad idea 20 years ago and it's a worse idea today.Olivier
The real bottom line is stop trying to write a renderer in a shader. It was a bad idea 20 years ago and it's a worse idea today.