Sign in to follow this  

Simple frustm culling problem...

This topic is 4592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm developing a simple 3D engine... I represent 3D object (at this stage) as programming object (classes), and I'm trying to implement frustum culling at 3D object level (not polygons/triangles at this stage) to test if "things works correctly)... unfortunally it seems I'm doing something wrong... using a perspective projection matrix, culling works, even if objects are culled away "too far" from the window border... using a orthographic matrix thisng goes worst, since culling doesn't work at all... to calculate frustum planes I use the "typical way" (i.e. extracting viewmodel and projection matrices, multiplying them and then creating planes equations... does this method works in ortho viewing mode?)... if needed I can provide full source code, even if it's in C# (I'm using Tao framework)... any suggestion?

Share this post


Link to post
Share on other sites
I've never done any frutum culling in Ortho mode. I would think it would work, but it depends on if you use it just to take out the perspective correction, or to draw in 2d. For example, if you use ortho but still keep the same near and far, it should work. But if you use gluOrtho, which excludes the near far, than the near far are -1 and 1, so anything outside of that would get culled. But I'm not sure. For 2d drawing, I recommend just knowing how far the screen goes and culling accordingly. If depth is 1, than up down left and right before culling is close to one I think, just check and find out if you are doing 2d drawing. If you use Ortho for a HUD radar or the like, you wouldn't need to cull anything, and I really don't think culling is useful on a 2d level at all anyway, unless it is 3d but with ortho projection, like CAD project.

Share this post


Link to post
Share on other sites
I use glOrtho, with the same near/far clipping planes used by perspective view... and gluPerspective to create the perspective projection matrix... Since I want to switch at runtime from ortho to perspective view, and since planes are calculated by matrices, I thought everything should work in the same way (in my case it hadn't to work in the same way... culling before the object is outside the window)... I'm wondering... is it possible that my frustum volume is too small for my camera viewport? Something like this
_____________________
|____________|_||_||_|
|...............................|
|....______________....|
|...|\____________/|...|----> Window
|...|.|__________|..|...|
|...|/____________\|--|----> Frustum volume
|..............................|
|___________________|

(ASCII graphic is a bit difficult! :D)

If so, how can I manipulate viewport/projection-matrix to fit always the frustum volume to the viewport? (Maybe silly question :P )

[Edited by - BladeWise on May 16, 2005 6:51:35 PM]

Share this post


Link to post
Share on other sites
I use bounding spheres for my objects, so everytime I'm going to render them, I check if the six plane equations are ok, in this way:
a*(Cx+Px)+b*(Cy+Py)+c*(Cz+Pz)+d<-r
where a,b,c,d are planes coefficients, Cx,Cy,Cz are bounding sphere center coordinates (all zero if the object is centered in the origin of it's model space), Px,Py,Pz are the coordinates of the object in the scene, and r is the radius of the bounding sphere.
My viewport depends on window size (it's resizable), near is 0.1, far is 500, angle is 45 degrees... in ortho, centerX and centerY are window width/2 and window height/2...
Before rendering an object, I check if it passes frustum check, if not I print on screen (console) "Object X failed frustum", so I can understand if the object is culled away or not, even if I can't see anymore objects in the window...

To give more informations... I use a camera object, with associated position and rotation (a vector and a quaternion), before rendering the scene I set the ModelViewMatrix with camera rotation/translation, then I render every object... the flow is like this...

- translate to camera position
- rotate by camera quaternion
- for each object in the scene
- push model-view matrix
- translate to object position
- rotate by object rotation
-pop model-view matrix

I fear this is not correct, since I should do camera translation/rotation for every object, in this way

- for each object in the scene
- push model-view matrix
- translate to object position
- translate to camera position
- rotate by camera quaternion
- rotate by object rotation
-pop model-view matrix

Is it the same?

Share this post


Link to post
Share on other sites
Quote:
Original post by BladeWise
I use glOrtho, with the same near/far clipping planes used by perspective view... and gluPerspective to create the perspective projection matrix... Since I want to switch at runtime from ortho to perspective view, and since planes are calculated by matrices, I thought everything should work in the same way (in my case it hadn't to work in the same way... culling before the object is outside the window)... I'm wondering... is it possible that my frustum volume is too small for my camera viewport? Something like this
_____________________
|____________|_||_||_|
|...............................|
|....______________....|
|...|\____________/|...|----> Window
|...|.|__________|..|...|
|...|/____________\|--|----> Frustum volume
|..............................|
|___________________|

(ASCII graphic is a bit difficult! :D)

If so, how can I manipulate viewport/projection-matrix to fit always the frustum volume to the viewport? (Maybe silly question :P )



Not really sure, but if you transform the clip-space plane equations (which are simply the planes parallel to the faces of a cube with side length of 2, and inward pointing normals) by the inverse of the projection matrix, you should get exactly the plane equations in view-space, no matter the projection you use. From that, you can transform them in whatever coordinate space you like.
Be careful, anyway, because transforming planes is not the same of transforming vectors!!! (but maybe you already know this!)

Share this post


Link to post
Share on other sites
Thanks for your advice, I'll have a look to this... anyway, I'm trying to find a bug (or a project fault) in my project... it's so frustrating... the fact is that I'm trying to calcuate *by hand* planes to see if (at least) those are correct... and it's not so funny :P

Share this post


Link to post
Share on other sites

This topic is 4592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this