[ODE] Collision CSG?

[david@csworkbench.com]

Here's an idea that might be interesting to add to the collision toolbox:
primitive-mapped heightfields.  For example, you have a mesh of an arm
that kinda halfway looks like a capped cylinder but not really.  So you
take a capped cylinder, make a function to map it's surface to 2D (i.e.
the long axis is x and degrees around it is y).  Then you could specify
heights in terms of 0 = directly on the surface of the primitive, negative
means that many units towards the center, and positive means that many
units away from the center (all in body coordinates if I'm clear as mud). 
Nothing would happen until an object collided with the surface of the
primitive, then the collision system would query the heightfield at that
x,y coordinate (or you could just do it yourself).  This should be a lot
faster than generic mesh collisions while still being able to define the
exact same shape in many instances.

Just a thought,
David

P.S. in other news, I would have released the iterative algorithm today if
I had not have discovered a strange small amount of torque creeping in to
the system, seemingly in the friction approximation.  I'll try to track
this down tomorrow and see if I can get it released.  I may release it
tomorrow anyway so I can get some help finding the problem if it doesn't
become apparent rather quickly.

>> I've been wondering about this too but never tried yet: could
>> you just invert the contact point's normal and(/or) depth before
>> contact joint generation to effectively have objects bounce against
>> the inside of a geom instead of its outside...?
>
> I guess in this one case you could.  Actually it would probably be
> better to classify primitives as being fully contained by another.
> Then, when an intersection ocurrs, the previous 'contained' state would
> determine if it was inside, and thus should have the contact normal
> reversed.
>
> However, I was thinking about more complicated cases.  Say you wanted an
> open goldfish bowl - you could use the two spheres as before, but then
> also use a box to slice the top open... in effect you'd have positive
> and negative collision primitives.  You would need some way to determine
> if an intersection with a positive prim can be disregarded if it's also
> contained in a 'negative' collision prim... but that's where my thinking
> got stuck : ).
> --
> gl
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode