[ODE] Subtractive Geometry
bbell at legitimatefront.com
Wed Mar 31 14:01:04 MST 2004
Right. You're correct; I was grossly oversimplifying the problem. Still,
given that we're only really interested in supporting the standard geom
primitives (clearly mathematically defined shapes), it seems that if we
could develop/provide edge/corner generation logic (even if it was very slow
and pre-process oriented, ie., no dynamic motion of subtractive elements)
then this would be very doable, and seems like a worthwhile feature for the
Certain types of game simulations could really benefit from a model like
this, for example, the old non-digital games where you had to roll a ball
around a maze and into a hole. It seems to me that this is MUCH better
modeled as a cylindrical subtraction from a box, rather than making the
field out of multiple boxes and leaving a gap, especially since you have to
deal with all the potential issues where the boxes meet up.
----- Original Message -----
From: "Adam D. Moss" <adam at gimp.org>
To: "ode" <ODE at q12.org>
Sent: Tuesday, March 30, 2004 3:15 PM
Subject: Re: [ODE] Subtractive Geometry
> Brian Bell wrote:
> > It seems to me that this is definitely doable with a custom geom class,
> > aggregates the existing geom classes. The additive geoms could be
> > represented internally as a standard composite geom. The collision
> > for the geom would be something like ( colliding with additive-composite
> > !colliding with subtractive ).
> Certainly, but that's not the hard bit...
> > The only problem I see is supporting surface collisions along the
> > subtractions. It seems that this could be handled properly if all the
> > classes handle interior surface collisions properly, which I'm almost
> > positive they don't.
> It's not a BIG deal to collide with the interior instead of the
> exterior (off the top of my head, for most of the geoms it might
> well be enough just to negate the contact depth). The difficulty
> which most people who propose a solution like this seem to miss (or
> maybe I'm just not seeing the full simplicity) is that to collide a
> geom with a CSG you're not just point-testing for inside/outside,
> which is relatively easy to do on a composite in a boolean manner.
> Rather, we unfortunately really have to care about the shape of the
> resulting composite object for various reasons I can think of,
> the primary one being that a colliding geom would have to be able
> to respond to the edges and corners of the composite shape which
> aren't trivially derived from or deferred to one or other of the
> individual geom's collision functions.
> Adam D. Moss . ,,^^ adam at gimp.org http://www.foxbox.org/ co:3
> ODE mailing list
> ODE at q12.org
More information about the ODE