[ODE] visibility detemination?

[skjold@cistron.nl]

Hi Adam,

> Do be aware, though, that if you're going to cull drawing primitives
> based on the geometries that represent them then those primitives
> should lay wholly within their geometries, otherwise it would
> not be correct to assume that if the geometry does not collide
> with the viewing frustum then the primitives may be culled away.

Maybe I'm missing something, but why would drawing primitives ever lay outside collision primitives? Geometries define the physical size/shape/location/orientation of everything in the virtual world, right? Then don't they always represent exactly what you intend to draw (and if not, wouldn't it make more sense to have the geometry always encase the drawing primitive entirely)?


> 
> Further, ODE's current geom primitives don't offer any half-
> reasonable way to construct a vaguely accurate frustum volume to
> cull against.  You can use a number of plane geoms, but ODE's
> hashSpace doesn't do anything clever with planes yet (they
> never fit into a single cell of any resolution) so you wouldn't
> gain anything over walking the AABBs in your scene and testing
> them manually.

Ok, I assumed that checking for (potential) collision with planes would be very efficient, but I don't know much about the current status of these things in ODE. In any case, you don't need even a remotely accurate geometry to represent the frustum volume, if all you do is take advantage of the existing collision-detection "infrastructure" to quickly and cheaply eliminate any reasonable subset of non-visible objects from the rendering pipeline. Even one plane would be enough (if plane collisions were implemented efficiently in ODE) to instantly cull half of your objects on average (the ones behind the camera) with only a minor overhead. Or instead, like I said, ANY arbitrary geometry can be used in place of an actual frustum geometry, as long as the AABB that ODE generates for it always completely encases the intended frustum volume. The geometry itself wouldn't even be necessary at all, if it weren't for the fact that you need it as a placeholder for that AABB that is used in the hash-space, but actually the AABB is all that matters here: It is generated and cached for you along with all the other geoms, and you get the benefits of octree-usage completely free. Surely this must be exploitable in a way that makes sense?

Greets,
Mark