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.

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.

We had the power, we had the space, we had a sense of time and placeWe knew the words, we knew the score, we knew what we were fighting for

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 I tried and I tried 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!!

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.

Lol, thanks Baker. Anyway, I couldn't get it work. Spike advices were very clear but probably my opengl skills are too low to create a working orthographic projection in FTE for project parallel shadows.

I adapted this GLSL shader that mimic parallel light and I used this site as reference for bias matrix and for learning how shadows are applied in fragment shader

This is the modification in Sh_GenShadowMap() in gl_shadow.c. I simply delete all the code regarding omni/spot and replaced with this. Just temp code.

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).

Spike wrote: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.

Something like that?

I projected this textureon this scene. I used same matrix trasformations for both gl_Position and projected texture coords. It's important to mention that, in FTE, if you want to assign to gl_Position, something that is not ftetranform(), you have to use z margin to "extrude" it a little, otherwise zfighting will ruin the renderingHere's the code

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.

so probably it's not what I should do, but, weirdly, final image is exactly what I wanted to achieve!Now texture orientation is not tied anymore to camera inclination and it seems that texture "covers" entire scene with same texture coordinates. But I used texture2D, and not texture2DProj

adding to vertex shader a bias matrix and multiplying it to model matrix and l_cubematrix, makes image less "warped"

And the image is thisPersonally, this seems a weird projection and texture is stretched above spheres. It seems more like that every object preserves its own texture coords. But this approach uses texture2DProj

Today I tried a different approach. Instead of using engine builtin matricies, I asked myself: how would it be if I use arbitrary rotation matrix for texture plane projection?So I learned here how openGL uses matricies for transformation and I created a rotation on X axys matrix

This is the renderingyou can use cvar_glsl_project_angle to change angle of orientation of the projected plane. As you can see, both spheres have same inclination of projection, cubes seems that have their own. Plus, rotating objects like the cube in the screenshot, rotate the projection with them, so it's again in object coordinates, not world coords. But, really, I cannot understand how to convert it.