[ODE] Re: Call to set a space's AABB.

[gl]

Seconds after sending this, it ocurred to me that what I really want is
placeable (position-only) spaces.  I would then have spaces centered in
their correct place in the graph/world (ie. their bound extents would still
default to zero, but the values would be offset by their position) - they
could now grow and shrink (which is helpful in this case), and would still
never overlap, eliminating the need for all-zero checks.

Would this be of use to anyone else?
--
gl

----- Original Message -----
From: "gl" <gl@ntlworld.com>
To: <ode@q12.org>
Sent: Friday, February 21, 2003 5:41 PM
Subject: Call to set a space's AABB.


>
> OK, my scene graph is quadtree based.  I may do my own collision culling
in
> the future, but for now I create a simple space for each quadtree node,
> giving me a deep space hierarchy that matches the graph.
>
> The problem is that any spaces/nodes that contain no objects have their
> bounds set to all-zeros.  Worse, any spaces that contain only other empty
> spaces (ie. most of them) also have their bounds all zero.
>
> Worst of all, if I now add a a _static_ geom to the graph, I put it into
the
> world's static space to avoid collision between other statics.  Problem is
> that now the space belonging to the node the geom was sorted into still
> keeps its bounds at 0,0,0 (as it's never added to it).
>
> To speed up the collison callback I currently skip spaces who's bounds are
> all zero, but in this scenario that no longer works.  Worse, if I remove
> this check I now have to test zillions of these 'contains only other
spaces'
> spaces that all overlap each other (because they're all zero), or cull
them
> some other way.
>
> All of these problems could be avoided if I could preset each space's AABB
> to the correct dimensions.  In fact, I would like to lock this AABB so
that
> it never grows or shrinks - it should never grow because I currently don't
> allow node overlapping, and it certainly should never shrink, so it
removes
> the need for the internal AABB housekeeping altogether.
>
> I can of course hack this in myself, but would anybody else find this
> useful?  Or does anyone have another approach to this?
> --
> gl
>