[ODE] visibility detemination?

[gl]

I very much doubt that you want to use collision at all for visiblity
testing - it's bound to be much slower than a frustrum vs (ideally
hierarchical) primitive test.

If you think about it, ODE is already using axis aligned boxes to minimize
collision checks.  You can just test these precomputed boxes against your
view frustum.  If you use spaces, you can cull entire spaces with a single
check.  Doing collision on top of that is overkill ...
--
gl

----- Original Message -----
From: <skjold@cistron.nl>
To: <ode@q12.org>
Sent: Monday, February 17, 2003 11:24 AM
Subject: Re: [ODE] visibility detemination?


> 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
> >
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>