[ODE] visibility detemination?

[skjold@cistron.nl]

Well, eliminating definitively non-visible objects can be done with a frustrum geometry quite well, basically piggybacking on the rough selection procedure of dSpaceCollide that is performed each frame anyway. But the risk is, that more checks will be done than is necessary for objects that are (potentially) in your FOV, if those objects consist of multiple geometries (such as articulated bodies - if you have those at all). So in that case special handling will still be required for collisions with the frustrum geometry.

It would probably be best to take advantage of collision detection only for making a very rough selection of potentially visible objects - minimizing unnecessary overhead - and then work with that selection (likely passing them through regular FOV calculations to get a finer selection). You could even consider using a large sphere geometry that fits exactly around your intended frustrum, since it's meant only for fast culling of definitively non-visible objects, and sphere geometries are very effecient to check collisions against.

Just some thinking out loud here, I hope it's useful :) I'm not sure how this collision approach compares to regular FOV culling in terms of efficiency, really, so I don't know if it's worth doing that in the end. But I figure, taking those smartly cached AABB's and multi-resolution hashed spaces into account that ODE uses, there must be some way to take advantage of the processing that's already being done for that each cycle.

Greets,
Mark

> hmmm... interesting concept. Personally I wouldn't do it, favoring my own
> FOV calculations, but the principle is sound.
> 
> Essentially I think that the FOV should just give an approximation of what
> is definately visible; so the exact collision calculations of ODE may be a
> bit overkill.
> 
> ----- Original Message -----
> From: "Clint Brewer" <clint@haptek.com>
> To: <ode@q12.org>
> Sent: Monday, February 17, 2003 10:51 AM
> Subject: Re: [ODE] visibility detemination?
> 
> 
> > Henri Hakl wrote:
> >
> > >"Culling code" - as in determining what is visible and what not?
> > >
> > >Sorry - not sure what you mean...
> > >
> > >
> > yes, exactly.  For doing a quick sweep over all objects, and determining
> > which of them is visible.
> >
> > Currently I have my own code that checks objects to see if they fall
> > within a view frustum before sending them through the rendering pipeline.
> >
> > I was figuring that since ODE is already dealing with collision code in
> > a pretty fast way, I could make a view frustum geometry and collide that
> > with the objects to see which are inside it.
> >
> > -c
> >
> >
> >
> > _______________________________________________
> > ODE mailing list
> > ODE@q12.org
> > http://q12.org/mailman/listinfo/ode
> 
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>