getting projection matrix
hi,
i''m using "glGetFloatv( GL_PROJECTION_MATRIX, proj )" to extract the projection matrix and do some frustum culling on a quake 3 map. however, i''m getting strange results. when i move around the level, polygons dissapear and reappear almost at random. i''m doing the matrix extracting just after calling "gluLookAt". i''ve followed the gametutorials.com tutorial exactly, but this is still happening. any ideas??
I have a couple of reasons why this might be. One I am pretty firm on. The most obvious is that if you are modifying the projection matrix and you have backface elemination turned on, those polygons may now have surface normals pointing away from where they are visible. I would say that is the most likely reason. You might try it on different video cards though, as I''ve had an ATI Radeon do this to a scene, while an Nvidia Geforce 2 did not. (I''ve had other features where ATI seemed to work better). So if you can try it somewhere else. If not, and you have the projection matrix. Try transforming the surface normals through the pipeline and after the projection matrix test if they are visible. If you need some idea of how to do this let me know.
well, the thing that''s strange is that the gametutorials.com tutorial runs fine. here''s some of my code:
the strange thing is, when i put the calculate frustum call before the ->Look() call, the level renders correctly, but is missing about 1/4 of the geometry. (all quake 3 maps are behaving this way).
glEnable(GL_DEPTH_TEST);glEnable(GL_TEXTURE_2D);glCullFace(GL_FRONT);glEnable(GL_CULL_FACE);then to render:camera->Update();glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glLoadIdentity();camera->Look();frustum->CalculateFrustum();//then render level
the strange thing is, when i put the calculate frustum call before the ->Look() call, the level renders correctly, but is missing about 1/4 of the geometry. (all quake 3 maps are behaving this way).
Very odd. I''m not sure how to tell you to solve this. I guess keep comparing code. Maybe replace your sections with theirs slowly and methodically and see if that fixes the problem. The fact that it is after the calculate frustrum seems to definitely be a problem where the normal used to determine the backface is not where it is supposed to be. That is the dot product of the view vector and the normal <= 0. I hope someone else can help. I''m redoing my system right now so I don''t have visual studio in place to work play around with it yet.
Normals aren''t used for back face culling by OpenGL, so unless you are doing it yourself manually (which you really shouldn''t) that probably is''t the problem.
You do realise that when you extract the planes from the projection matix they are in view space? You usually wan''t them in world space for easier culling against the world (otherwise you''ll have to transform every scene node into view space to do culling). This can be achieved by extracting the frustum planes from the matrix PM where P is the projection matrix and M is the inverted camera transform. If M is the Modelview matrix you''ll get the frustum planes in object space.
You do realise that when you extract the planes from the projection matix they are in view space? You usually wan''t them in world space for easier culling against the world (otherwise you''ll have to transform every scene node into view space to do culling). This can be achieved by extracting the frustum planes from the matrix PM where P is the projection matrix and M is the inverted camera transform. If M is the Modelview matrix you''ll get the frustum planes in object space.
Thanks GameCat for calling my mistake. I haven''t done OpenGL in a while (been busy with robotics research and a ray tracing engine). Are you sure it doesn''t for planer normals. I know it doesn''t for lighting normals, but I''m pretty sure that the reason you have to specify which winding you want is because of the surface planer normals which is the easy way to remove a backface.
You are completely right about the fact that what he is getting is in view coordinates. I didn''t think about that at the time. Darn coordinate systems :-).
You are completely right about the fact that what he is getting is in view coordinates. I didn''t think about that at the time. Darn coordinate systems :-).
OpenGL uses the signed area of a triangle post projection to determine if it is front or back facing. Normals have nothing to do with back face culling in OpenGL, but triangle winding order does.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement