W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: Adding normal matrix to CSS Shaders

From: Chris Marrin <cmarrin@apple.com>
Date: Mon, 19 Dec 2011 16:03:02 -0800
Cc: public-fx@w3.org
Message-id: <8CDB63A7-A2C8-4418-AFB9-F3DECCC391F5@apple.com>
To: "Gregg Tavares (wrk)" <gman@google.com>

On Dec 19, 2011, at 3:15 PM, Gregg Tavares (wrk) wrote:

> On Mon, Dec 19, 2011 at 2:12 PM, Chris Marrin <cmarrin@apple.com> wrote:
> 
> On Dec 16, 2011, at 10:51 PM, Fabrice Robinet wrote:
> 
> > Hi group,
> >
> > One great outcome of CSS Shader could be the ability to add custom/simple lighting to DOM elements.
> > The simple addition of the normal matrix to be passed to the shader (as optional),
> > would allow simple cases without impacting the SPEC too much.
> 
> What is a "normal matrix"?

A normal matrix is basically a model-view matrix without scaling, to avoid the distortion to normals that occurs if a matrix has non-uniform scaling. You can derive it simply by inverting and then transposing a model-view matrix, but you often see it passed in to avoid the need to do that operation per-vertex.

In fact I see many shaders that just pass in a normal matrix and a model-view-projection matrix, since you really usually don't need a separate model-view and projection matrix after you've factored out the normal matrix. 

But in this case it seems like you're typically going to want to use the normal matrix to compute lighting and then just transform the points of the mesh by the projection matrix, since the model-view matrix will be applied to the resultant element after the CSS shader is applied to the element surface. Of course, doing that will flatten the CSS shaded image onto the element surface, so viewing it edge on won't look right, much like bump mapping doesn't look right when you view it edge on.

> 
> If you feel like going crazy, there's something nvidia defined, "Standard Annotations and Semantics" that many shader editors use. They define the following 24 matrices
> 
> WORLD 
> VIEW 
> PROJECTION 
> WORLDVIEW 
> VIEWPROJECTION 
> WORLDVIEWPROJECTION 
> WORLDINVERSE 
> VIEWINVERSE 
> PROJECTIONINVERSE 
> WORLDVIEWINVERSE 
> VIEWPROJECTIONINVERSE 
> WORLDVIEWPROJECTIONINVERSE 
> WORLDTRANSPOSE 
> VIEWTRANSPOSE 
> PROJECTIONTRANSPOSE 
> WORLDVIEWTRANSPOSE 
> VIEWPROJECTIONTRANSPOSE 
> WORLDVIEWPROJECTIONTRANSPOSE 
> WORLDINVERSETRANSPOSE 
> VIEWINVERSETRANSPOSE 
> PROJECTIONINVERSETRANSPOSE 
> WORLDVIEWINVERSETRANSPOSE 
> VIEWPROJECTIONINVERSETRANSPOSE 
> WORLDVIEWPROJECTIONINVERSETRANSPOSE 

I sure hope we don't have to produce all those :-)

really these are just a lot of combinations of model, view and projection. What I'm calling a normal matrix is just WORLDVIEWINVERSETRANSPOSE in this notation. 

I really think we just need to decide which combinations will give authors enough flexibility for common tasks. I think (but I haven't given it nearly enough thought) that projection and normal matrices would cover most of the useful cases.
Received on Tuesday, 20 December 2011 00:03:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 December 2011 00:03:21 GMT