[ODE] Subtractive Geometry

[Brian Bell]

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

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.

Brian

----- 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,
that
> > aggregates the existing geom classes.  The additive geoms could be
> > represented internally as a standard composite geom.  The collision
logic
> > 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
geom
> > 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
> -- 
> Adam D. Moss   . ,,^^   adam at gimp.org   http://www.foxbox.org/   co:3
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode