   Creating a projection matrix without GLUT!
  My travails with openGL ES continues with me running into yet another wall! The problem is that I'm trying to do view frustum culling. For this I need to extract the planes from the projection matrix. Ok, so I know how to get the planes but how do I get the current projection matrix? opengl ES doesn't seem to offer any getFloatv equivalent to extract the matrix info. I was told to build my own projection matrix and plug this matrix into my plane extraction code.So, the big Q then is: how the hell do I build a projection matrix? I searched a bit on the Net and apart from various tedious mathematical text on the subject, I couldn't find a practical guide that told me how to build a projection matrix without me tearing my remaining hair out! Help!   
  Look here :http://pyopengl.sourceforge.net/documentation/manual/gluPerspective.3G.htmlIt explains the gluPerspective() function and the resulting matrix. The same can be found for other matrices on the site.Now, for frustum planes extraction, refer to http://www2.ravensoft.com/users/ggribb/plane%20extraction.pdfIt is a great reference (for both OpenGL and Direct3D.Note that I assume things are the same for OpenGL ES as for OpenGL.Hope it helps.   ;  Here are some things which might help. First of all, you can find the construction for RH perspective matrices in the DirectX documentation; however, the z-clipping range is different than OpenGL, so you'd have to alter it to reflect this. You can also find the OpenGL frustum matrix construction in the back of the Red Book, but you'll have to convert from fov-aspect form yourself if that's the info you have available.I'll also go ahead and post some of my code, which if you're lucky will work 'out of the box' and solve your problem. (I say 'if you're lucky' because I stripped some irrelevant stuff out for posting, and may have screwed something up in the process.) Just ask if you have any questions about the code; you'll probably have to make a few changes, such as swapping out the math functions, getting rid of the template stuff, and replacing the 2d indexing with 1d indexing if necessary. Here it is:template <class T> void Matrix4<T>::perspective_yfov_RH(T yfov, T aspect, T n, T f) {    yfov = Math<T>::DegToRad(yfov);    T hh = Math<T>::Tan(yfov * (T)0.5) * n;    T hw = hh * aspect;    perspective_frustum_RH(-hw, hw, -hh, hh, n, f);}template <class T> void Matrix4<T>::perspective_frustum_RH(T l, T r, T b, T t, T n, T f) {    LoadIdentity();    m_(3, 3) = (T)0.0;   T inv_width  = (T)1.0 / (r - l);    T inv_height = (T)1.0 / (t - b);    T inv_depth  = (T)1.0 / (f - n);    T n2 = (T)2.0 * n;   m_(0, 0) = n2 * inv_width;    m_(1, 1) = n2 * inv_height;    m_(2, 2) = -(f + n) * inv_depth;    m_(0, 2) = (l+r) * inv_width;    m_(1, 2) = (b+t) * inv_height;    m_(2, 3) = (-(T)2.0 * f * n) * inv_depth;    m_(3, 2) = (T)-1.0;};  seb, thanks for the links - the glu reference is proving to be very handy!jyk, thanks for the code - just what the doctor ordered! While I don't see a problem converting it to my needs, I'm just a bit puzzled by the deg2rad you are doing for the fov. I thought openGL used degrees anyway, so do we really need to convert?   ;Quote:Original post by SpecchumI'm just a bit puzzled by the deg2rad you are doing for the fov. I thought openGL used degrees anyway, so do we really need to convert?A couple of things about that. First of all, since this code operates outside of OpenGL, it can use anything it wants - degrees or radians. You only have to take into consideration the fact that OpenGL uses degrees when using a gl function - such as glRotate() or gluPerspective() - that has an angle as an argument.However, the function I posted does happen to take the field of view in degrees. The Math::Tan() function, on the other hand, takes radians, hence the degrees->radians conversion.'Hope that clears it up, and feel free to ask if you have any other questions about the code.   ;Quote:Original post by jykThe Math::Tan() function, on the other hand, takes radians, hence the degrees->radians conversion.Now I feel a bit silly. Should have figured that you were doing it for the Tan function! I've probably been staring at the code for too damn long! :)Okay, I implemented the function and it works "out of the box" very nicely! :) However, I'm facing a couple of issues. Hope you can help here too: my perspective is a bit skewed. I've chosen a fov of 45 degrees but I think my other values may be a bit off. Please note that I'm working in fixed point maths and I've had to change a bit of things in the way you are calculating things, so it might be a problem with that rather than a logical one, but to clear things logically first: 1) My near clip parameter seems to change the depth of view. If I set it to a lower value things appear more distant and higher value makes things nearer. Is something seriously wrong at my end? 2) My screen height is more than the width so my aspect ratio is < 1. Do I need to tweak my fov to suit this then or should 45 degree work regardless? I ask because my perspective skewing lessens with lesser values of fov (30 or 25 looks much better).;  Hm, let's see. Well, first of all, although I'm 98% sure the functions I posted are correct, I'm not 100% sure (I could have messed something up when I posted them). If you have the means to do this, I think it would be a good idea to set up your program (temporarily) to switch back and forth between the custom code and the gl code either randomly or in response to some command; if the code I posted is correct, the view should change minimally, if at all, when you switch. This would be a good way to test the correctness of the code.I'm afraid I'm out of my element with the ES/fixed point stuff, so I'm not sure what the ramifications of that are.Now when I hear 'skewing' I think of being off-center or 'crooked'; is that what you mean by the projection being skewed, or do you just mean it's 'messed up' in some way? If it's the former, that would be odd. If you're just referring to things being closer or farther away than it seems they should be, I would point out that (like gluPerspective) the function I posted takes the vertical rather than horizontal field of view, and 45 seems a little small, especially given that your screen is taller than it is wide. But if that's the case, it wouldn't make much sense that smaller fields of view would look better...So I'm afraid this post wasn't much help. I would test those functions myself, but at the moment I don't have a project set up to do that easily. I certainly would like for my code to be useful to you though, so let me know if you need any more help sorting it out.   ;Quote:Original post by jykIf you have the means to do this, I think it would be a good idea to set up your program (temporarily) to switch back and forth between the custom code and the gl code either randomly or in response to some command; if the code I posted is correct, the view should change minimally, if at all, when you switch. This would be a good way to test the correctness of the code.I've indeed checked this and the gluPerspective seems to do things rather differently. Actually, that's not entirely right. You see, ES doesn't have the gluPerspective function and so I'm doing certain calculations (similar to yours for fov) and using glFrustum to achieve the effect. Here are the things I'm doing (Dave Astle's code adapted rather):void SetPerspective(igFixed width, igFixed height, igFixed fov, igFixed near, igFixed far){igFixed aspect = FixDiv(width, height);  // = width/heightigFixed top = FixMul((Tan(fov/2)), near);// tan(fov/2) * nearigFixed bottom = -top;igFixed left = FixMul(aspect, top); // = aspect * topigFixed right = -left;    glMatrixMode(GL_PROJECTION);glLoadIdentity();glFrustumx(right, left, bottom, top, near, far);glMatrixMode(GL_MODELVIEW);}Note that igFixed = int and FixDiv and FixMul are functions to perform division and multiplications of fixed point numbers. I've indicated the equivalents in the comments.Quote:Now when I hear 'skewing' I think of being off-center or 'crooked'; is that what you mean by the projection being skewed, or do you just mean it's 'messed up' in some way? Er.. I mean it's umm.. messed up in some way. :) Skewed is the wrong word I suppose. What I had in mind was something like "stretched at edges". You know, something like the fish-eye effect but less severe.;  The 'stretched at the edges' part sounds like a field-of-view issue. In any case, changing the near clip value (within reason) shouldn't change how things appear onscreen. So if changing znear creates a zoom-like effect, something may be wrong.Other than that, I have to admit I'm a bit stumped :-| There are too many things I'm not sure of, like for example, does glFrustumx() do the same thing as glFrustum(). (I note that in your sample code, 'right' and 'left' are switched around, which suggests maybe you're working with a different coordinate system or something).If you're still stuck on this tomorrow, let me know and maybe I can test my functions to make sure they're correct. Also, any additional info you could provide about how the ES library might differ from 'regular' OpenGL would be useful (coordinate system, what the 'x' in glFrustumx means, etc.).   ;Quote:Original post by jykOther than that, I have to admit I'm a bit stumped :-| There are too many things I'm not sure of, like for example, does glFrustumx() do the same thing as glFrustum(). glFrustumx is same as glFrustum except that the former is for fixed point numbers. The x indicates that it expects parameters in fixed point.Quote:(I note that in your sample code, 'right' and 'left' are switched around, which suggests maybe you're working with a different coordinate system or something).That's an artefact of how Astle was calculating left and right in his code. I simply switched the parameters when passing into the glFrustum function. :)[quoteIf you're still stuck on this tomorrow, let me know and maybe I can test my functions to make sure they're correct. That would be very nice! I appreciate the help you've provided so far. Cheers!