Dear frnds,
please clarify the doubt,
I have a doubt in light source point of view,
[x
]= [view matrix of light ] * [ projection matrix of light ] * [ object of world matrix ] *[vertex (hitting point)]
Printable View
Dear frnds,
please clarify the doubt,
I have a doubt in light source point of view,
[x
]= [view matrix of light ] * [ projection matrix of light ] * [ object of world matrix ] *[vertex (hitting point)]
I'm guessing you meant you have a "question" rather than a "doubt".
What's your question?
BTW, your space transformations need the light VIEWING and the light PROJECTION matrices swapped. And even then that's going to leave you in light CLIP-SPACE. You still need a bias matrix to shift your projected coords from -0.5..0.5 to 0..1 needed for shadow map texture lookup.
sorry for posting like that...
In light source point of view,i have doubt in depth buffer
(COLUMN MATRIX)[x,y,z,w]=[bias matrix]*[view matrix of light]*[projection matrix of light]*[object of world matrix]*[vertex]
In this calculation,how to find the depth value ?
As Dark Photon mentioned, you've got the wrong matrix order. It should be
(COLUMN MATRIX)[x,y,z,w]=[bias matrix]*[projection matrix of light]*[view matrix of light]*[object of world matrix]*[vertex]
The depth value will be in 'z'. Note, if you are using a perspective projection, then you also need to divide by 'w'.
The bias matrix should be:
0.50000 0.00000 0.00000 0.50000
0.00000 0.50000 0.00000 0.50000
0.00000 0.00000 0.50000 0.50000
0.00000 0.00000 0.00000 1.00000
But you can also do this transformation in the shader with the more optimized (and easier to read?):
[x,y,z,w]=[projection matrix of light]*[view matrix of light]*[object of world matrix]*[vertex]/2+0.5
Maybe the shader compiler will optimize it this way.
It should be equivalent? Good enough for me to use it, and it is working.
Doing multiplication or division with a scalar on a vector is done piecewise.
Whether the compiler can do the optimization anyway, I can't say.
That's an interesting puzzle. :confused: Hmm, let's see:
Code :
[x, y, z, w] / 2 + 0.5 = [x*0.5+0.5, y*0.5+0.5, z*0.5+0.5, w*0.5+0.5]
versus
Code :
[bias matrix]*[x,y,z,w] = [ 0.5 0.00 0.00 0.50 0.0 0.50 0.00 0.50 * [x,y,z,w] 0.0 0.00 0.50 0.50 0.0 0.00 0.00 1.00 ] = [ x*0.5+0.5*w, y*0.5+0.5*w, z*0.5+0.5*w, w ]
where in both cases [x,y,z,w] is a CLIP-SPACE position.
If we do the perspective divide on the latter (the standard "bias matrix" approach), we get the nice [ x/w*0.5+0.5, y/w*0.5+0.5, z/w*0.5+0.5, 1 ], which is just the scale-and-shift we need to shift the NDC cube (-1..1,-1..1,-1..1) into (0..1,0..1,0..1).
But with the former, we end up with: [x*0.5+0.5, y*0.5+0.5, z*0.5+0.5, w*0.5+0.5]. And if we do the perspective divide, ...we end up with something very different.
I could be missing something (very possible!), but I don't see how to map this as equivalent to the former. Any ideas?
Thanks.
Thanks, I see what you mean! And you are right of course. The reason is works for me is that I don't do the perspective divide (using orthographic projections).
The simplification should still be valid if it is done on the xyz component only, shouldn't it?
edit: I did some performance testing (using queries), and could find no measurable differences between using a const mat4 bias.