hello ! Question about Culling !

[popom]

I wonder me if when I have an object who are hidden by an another, OpenGl draw it then delete it ?
Must I create a Culling Function to know if an object must be drawed with glvertex ...
The FPS can be better ?

Thanks !
I hope that you'll understand my bad english !!
Cyril

[jwatte]

The only functions that determine "visibility" in OpenGL are Z buffer, stencil test, alpha test and back-face culling. (did I miss some?)

Because you just submit simple geometry serially to OpenGL, it cannot determine whether some polygon you're submitting now might be obscured by some polygon you'll be submitting later -- the work-around is to use the Z buffer, although you will eat up some of your available fill rate.

As you say, you can do some kind of occlusion/culling (portal engines seem well matched to modern hardware for indoors scenes) to avoid doing unnecessary work on the card.

Now, you're saying you're using glVertex(). If you want your stuff to run fast, the first thing you should do is move over to glVertexPointer() and glDraw{Range}Elements(), possibly using either the NV_vertex_array_range or EXT_compiled_vertex_array extensions.

[popom]

Thanks for your informations !

I tried to use GlDrawElements, but that had not run faster !!! why ? i don't know !
So i use Lists with some called at glVertex3f(...);

So, OpenGL make calculs for all call to glVertex ? if an object is behind you, (in a 3d engine) openGL 'll make caculs for this object as if it won't be showed on the screen ?

Thanks
Cyril

Originally posted by jwatte:
The only functions that determine "visibility" in OpenGL are Z buffer, stencil test, alpha test and back-face culling. (did I miss some?)

Because you just submit simple geometry serially to OpenGL, it cannot determine whether some polygon you're submitting now might be obscured by some polygon you'll be submitting later -- the work-around is to use the Z buffer, although you will eat up some of your available fill rate.

As you say, you can do some kind of occlusion/culling (portal engines seem well matched to modern hardware for indoors scenes) to avoid doing unnecessary work on the card.

Now, you're saying you're using glVertex(). If you want your stuff to run fast, the first thing you should do is move over to glVertexPointer() and glDraw{Range}Elements(), possibly using either the NV_vertex_array_range or EXT_compiled_vertex_array extensions.

[zen]

If you don't want do draw any objects that you cannot see because they're behind you or generally not where you're looking what you need is to implement view-frustum culling.Do a search on the web.You'll find info on how to do that.Also don't forget the opengl FAQ .There's som usefull info there too.
If you don't want to draw onjects that *are* in your view-frustum(the area the camera can 'see')but are hidden by other objects(which are in front of them) then what you need is occlusion-culling.I have never tried this but I think you'll be able to find enough info on the web.
Hope that helps.

[This message has been edited by zen (edited 06-03-2001).]

[popom]

Thanks you !!!
I'll search !
bye
Cyril

[stim]

I have the best results creating my own culling algorithm and applying it to the data first so only visible vertices are passed to be drawn.

I find that it is always useful to transform from object coords to world coords and store the world coords (useful for collision detection). It may help to use simple model for clipping and collision detection and use the information for the more complex model. Perform culling algorithm when all objects are in place and viewing volume clipping can be performed.

combine the view and projection matrices and invert. This gives a volume in world coords. Compare stored world coords of objects with world coords of clipping volume to test if visible.

I prefer to not use zbuffer if possible and use a fast depth sort of objects instead. When rasterizing zbuffer comparisions are SLOW even in hardware. It may not look as nice but is faster.

[davepermen]

how do you do the sort of the triangles? you need the nearestpoint on triangle.. how do you get this fast?

[Tom Nuydens]

Originally posted by stim:
I prefer to not use zbuffer if possible and use a fast depth sort of objects instead. When rasterizing zbuffer comparisions are SLOW even in hardware. It may not look as nice but is faster.

I seriously doubt that. Are you saying that disabling the depth test and doing a depth sort of all your triangles for every frame is faster than letting the hardware take care of things?

If you're going to sort by depth, do it in a way that will actually do you some good: enable the depth test and sort your (opaque) geometry front-to-back. Also, do the sorting per object rather than per triangle. Your CPU has better things to do with its time

- Tom

[popom]

do you have some links about culling, mathematics for culling and others ... ?
Thanks !
bye
Cyril

[tfpsly]

flipcode.com