What space is "shader" space exactly?

[Ivan Mavrov]

Hello guys,

I was looking into a strange space-to-space transformation behavior on our side and fell back to the OSL Specification looking for wisdom.

Unfortunately, I cannot interpret properly the following statement:

"shader" - The local coordinate system active at the time that the shader was instanced.

I thought that "shader" space is the local tangent space at the shading point.

For example:

vector("shader", 1.0, 0.0, 0.0) is a tangent pointing along the positive u texture coordinate axis (in "common" space) a.k.a normalize(dPdu).

vector("shader", 0.0, 1.0, 0.0) is a bi-tangent pointing along the positive v texture coordinate axis (in "common" space) a.k.a. normalize(dPdv).

vector("shader", 0.0, 0.0, 1.0) is the shading normal at the hit point (in "common" space) a.k.a N.

This is really handy for bump mapping and other stuff.

Can someone give me a hint for the proper and renderer-independent implementation of "shader" to "common" transformation ?

Thank you!

Ivan Mavrov

[Larry Gritz]

Each geometric primitive object (sphere, mesh, patch, etc.) may have a local coordinate system. For example, you might think of a sphere primitive as having a canonical position and orientation in a local space, and you *place* that local coordinate system (and the sphere that lives in it) relative to the world with a local-to-world coordinate matrix. This is what OSL calls "object" space. The meaning of "object" space is the same for all shaded points on a geometric object, but may be different for each object in the scene.

Similarly, each shader group (aka shader network, or material, or whatever your renderer calls it) can have its own coordinate system, and so when an OSL shader refers to "shader" space, it means the coordinate system for the shader group that's currently executing. The meaning of "shader" space is the same for all shaded points on all objects that share the same shader group, but may be different for each shader group in the scene. Note that one shader group can be shared among several objects, each of which may in fact have different local object coordinate systems. 

Does this make sense?

You could also make a tangent coordinate system that differs for each individual shading point, defined by the dPdu, dPdv, and N vectors (using P as the origin), and sometimes it's useful, but OSL doesn't have a special name for that.

It would be a perfectly reasonable request to ask that OSL recognize "tangent" space as meaning this, but in 20 years of writing shader compilers, I don't recall anybody wanting that feature as a language built-in, versus just assembling the matrix themselves. Generally speaking, it should not be necessary. Because of the magic of displacement (and bump) and derivatives, you shouldn't need to compute tangent space explicitly in order to bump map.

-- lg

--
Larry Gritz
l...@larrygritz.com

[Ivan Mavrov]

Thank you very much for the thorough explanation.

Though I might understand better what "shader" space is, off the top of my head, I cannot come up with an example of how to use it (instead of just "world" or "camera").

I'm afraid I might be missing out on an important language feature here hahaha.

Thanks again.

Best regards,

Ivan Mavrov

[Larry Gritz]

Imagine that you are doing some form of texturing that's based on 3D position. For simplicity, let's assume we want something like

color C = noise(P);

but of course, it could be a more complex procedural pattern, or a projected texture map, or whatever. So in this case, you'd see a noise pattern on the model and it would look fine for one still image.

Now, what happens in an animation when the camera moves or if the model itself moves with respect to world space? The numeric coordinates of P for a particular spot on the model, expressed in camera or world space, will be different from frame to frame. Therefore, you will see an animation of the texture sort of flowing over the model instead of sticking to it.

So the solution is to define another coordinate system (not world or camera) that moves rigidly with the model. For some models, "object" space will be fine, but for others it is inadequate. So you may wish to associate another coordinate system with the shader itself (which you may move rigidly with the model, or move independently of the model to help you place the pattern as you want it), and shade based on that coordinate system. THAT is shader space, and you'd use it like this:

point Pshad = transform ("common", "shader", P);

color C = noise(Pshad);

Now as long as you move the local coordinate system of the shader declaration rigidly with respect to the model, the pattern will "stick" to the model as it moves (or as the camera moves).

(If the model is not only moving rigidly, but also deforming, then you will in addition want to use a "reference mesh" or "Pref", rather than raw P, but that's a whole other set of issues to explain.)

--
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 post to this group, send email to osl...@googlegroups.com.
Visit this group at http://groups.google.com/group/osl-dev.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@larrygritz.com

[Ivan Mavrov]

I see now.

Thank you very much for your time and effort explaining this.

Best regards,

Ivan Mavrov