[ODE] visibility detemination?

[gl]

(oh goody, reply-all would send _me_ a copy ;)

Note that I tend to type 'frustrum' rather than 'frustum' - it's burned into
my brain like that ...
--
gl

----- Original Message -----
From: "gl" <gl@ntlworld.com>
To: <ode@q12.org>
Sent: Monday, February 17, 2003 10:37 AM
Subject: Re: [ODE] visibility detemination?


>
> 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
> >
>