GL matrix story (stupid but true)

[Baker]

I am writing code to force portrait display mode by rotating the frustum/ortho/viewport.

Results in a 90 turn just by inserting ...

glRotatef (90, 0, 0, 1); // Add me!
glFrustum (-xmax, +xmax, -ymax, -ymax, glnear, glfar);

Stupidly, OpenGL fails to do this! Possibly due to a division by zero I am guessing where perhaps -xmax and xmax are used somewhere in the matrix calculation in a way they add together to be zero.

Hilarously ... instead I use mh's glmatrix frustum calculation which performs the calculation in a way that avoids division by 0 in common situations --- then do glLoadMatrixf (m) to load that matrix.

Then I live in "Not my problem!" city!

[Spike]

well, (-ymax)-(-ymax) == 0, so yeah, what do you expect?
I really hope that was a typo in your post and not your code.

glFrustum internally does a glMultMatrix, so make sure your prior matrix is sane. Also that you've got GL_MATRIX_MODE set properly. too much state sucks. but yeah, glLoadMatrix is the most sane way to do most of this anyway. The matrix generated by the function is well defined and well documented so implementing your own should be fairly easy, and more efficient on account of using glLoadMatrix instead of the implicit glMultMatrix of glFrustum.

[Baker]

[mh]

Yeah, the great thing about OpenGL is that you can look at the spec, read how things are implemented, then construct your own variant if you need to.

It should be possible (and easy!) to write a GL_RotatedFrustum that does the same in a single operation, not that it would be a performance improvement (unless for some reason you're calling glFrustum thousands or more times per frame).

None of these calls do anything special or magic or voodoo. They just construct an ordinary 4x4 matrix, do a multiplication and load the result to the GPU. There's nothing mysterious going on in their internals.

[toneddu2000]

Since we're talking about GL matricies, could please tell me, you, engine gurus, if it's possible to create an ortographic matrix to pass to FTE shadowmap code to make it project dynamic parallel shadows? Because but so far I only created weird static plane shadows!

Note that I created same matrix also in GLSL and pass it to the shadow map fragment shader part

PS:sorry to have sneaked into your post with a question, Baker, but the opportunity was too greedy!!

[Spike]

toneddu2000, you're actually looking for two projection matricies.
the one used to render the shadowmap needs to transform from camera space to clip space.
the one used to read the shadowmap needs to transform again from camera space, but this time to the texture coords (with depth).

clip space in opengl ranges from -1 on the left, bottom, and nearest part of the screen, to 1 on the right, top, and furthest part of the screen.
on the other hand, texture coords range from 0 to 1, as does the 'red' component of the shadowmap texture (aka the depth).
sampling from a 2d shadow sampler can be done with a 3d texcoord - the 3rd coord being a reference value to compare the texture against. This gives slightly smoother results. the alternative is to treat it as a regular texture and do the compare yourself, which may be needed with gles2, but mneh.

so the first matrix is a standard ortho matrix, while the second one can be generated from the first by multiplying it against a bias matrix, but if you care about precision you'd get more precise results by calculating it directly.
and don't forget the divide-by-w thing, though I don't recall it actually being needed with ortho matricies.

[toneddu2000]

thanks a lot Spike, I'll reply in the original thread, to avoid spoling Baker's thread

[Baker]

Doesn't bother me in the slightest, just fyi. Was just sharing a short experience.

Your post about shadowmapping was interesting. Carry on ... should you wish ...

[toneddu2000]

[Spike]

for a start, you're not even using the ortho matrix in your glsl, at least not in any way that would prevent it from being optimised out.

your light is in one place and its projecting onto some meshes. the vertex coords get multiplied by the model matrix which gives you the vertexes world coord. at this point things diverge - you have both a camera (with its view + perspective-projection matrix), and a light (which has its own orientation/view matrix, and its own ortho-projection matrix).
gl_Position needs the screen/camera position in clip space.
however, your shadowCoord needs the shadow coord in texture space upon your projected texture. this has absolutely nothing to do with the camera's view or projection matrix - the only normal matrix that matters for this varying is the model matrix.

what I'd recommend you try is to first just get your texture projection working.
ditch the shadow map for now, and just project a regular coloured 2d image onto a black wall for now.
that way you'll know when your s+t texture coords are correct, that there's no weird affine issues, etc, in a way that is completely separate from the shadowmap generation.
divide and conquer. you won't know when the p coord is correct until you reinstate the actual shadowmap, but at least you'll know that you're actually reading the right part of the shadowmap. the actual depth values themselves are probably the last thing you should tackle (ignoring stuff like pcf/smoothing/etc).

[toneddu2000]

[Spike]

no, you want to project the texture, not sample it from screen space. If you'd wanted that then there are easier ways to do it. Ones that do not require you creating a z-fighting minefield. Try re-reading the second block of text in my previous post.

[toneddu2000]

[toneddu2000]