[ODE] cylinder collision. (and correction)
cr88192 at hotmail.com
Sat Oct 22 15:20:37 MST 2005
----- Original Message -----
From: "Jon Watte (ODE)" <hplus-ode at mindcontrol.org>
To: "Ron Barry" <Ron.Barry at sun.com>
Cc: "Andrew Aye" <AndrewA at terminalreality.com>; <ode at q12.org>
Sent: Friday, October 21, 2005 11:01 AM
Subject: Re: [ODE] cylinder collision. (and correction)
>> To describe what I need: lay out coins of all different
>> types on a desk surface. They collide and effect each
>> other along their edges, but they lie flat on a surface.
> This will give me coin-coin collisions using the bounding spheres, but the
> coins will slide flatly on the ground using the box geom contacts.
> If you have slanted walls (at 45 degrees angle with the ground, say), you
> may get contacts with the spheres that you really want to react to, else
> you'll get a bit of interpenetration until the box picks up the slack --
> you can formulate an appropriate heuristic for this case. Or just don't
> use slanted walls :-)
my physics engine has convex hulls, and I have recently gotten flat-topped
cylinders working (ok, not well enough for most cases, but 'in theory' at
otherwise, there is no real practical advantage to my engine at present
(but, it is lame, I have pretty much no one to talk to about it, or at least
that has any real interest in talking about it or comments related to it).
actually, knowing somewhere where physics simulation/writing physics
engines/... is on-topic would be helpful (but, alas, I am likely a perpetual
particular example: note the ode example using the wall. in my engine, this
wouldn't work, contact behavior is not good enough yet, so, this wall would
likely push itself apart pretty quickly. likewise, objects composed of
multiple parts are generally not really possible at present (eventually,
however, I have convex hulls, bsp tree support, ... which imo make up for it
in my case. I am aiming more for typical game-like situations (in
particular, situations similar to those experienced in
first-person-shooters), where features like the ability to handle things
like the maps, self-propelled AABBs, ... win a little over things like
non-working stacks, poor contact/constraint behavior, ...
I may soon also implement trimeshes, and am vaguely considering an "idle
objects" handling feature so I can up the object count.
multiple passes are taken presently in the simulation step, as I have found
this increases the well-behaved-ness of the simulation, at the cost of
greatly reducing performance.
I was considering making this a tunable property, but this could just end up
as an "implementation detail". alternate implementations are likely to not
need something like this (eg: everything is handled well in a single pass),
or have different "sane" values. a few properties have allready gone this
way due to implementation changes (eg: a few properties have become pretty
much useless, ...).
a minor complaint wrt ode, is, well, that naturally it doesn't have hull or
bsp support (as a basic solidtype). yes, probably, trimeshes make up for
this, but I have heard not-so-good things about the trimesh support.
otherwise, I don't really like ode's api, but this is arguably trivial.
yeah, some people seem to hate handle, constant, and function driven apis,
oh well, this is what I wanted (yeah, gl all the way, imo, opengl is a very
clean api, so I had modeled mine after it...).
ode is close, but, why a seperate function for nearly every property?
what is the deal with the float/double issue?
I also feel ode doesn't sufficiently seperate the internal from the external
interface. mine attempts to be strict, eg, nothing "internal" is present in
"external" headers, ...
as a result, the external interface intends to be very "plain". it does not
expose many things to the user, as imo this clutters up the definition of
the interface. what if there is a clone implementation, do we really want
them having to implement a bunch of extra mundane crap in the name of not
breaking existing apps?...
yeah, some extra crap is possibly exposed in my case, oh well.
note: my idea is, imo, not mutually exclusive wrt ode, for example, I have
on and off been considering writing an ode wrapper as well, but have not
really bothered (may as well keeping my own implementation to serve as a
reference...). the issue is, some things would be harder to map over than
others, and I am not sure if it is worth the bother.
I don't know what most ode users' oppinions are wrt ode's api.
maybe I should focus harder on the spec?
maybe I should put even emphasis on spec and reference implementation?
or I should put more emphasis on the implementation (more how it has been
that or it is all pointless anyways, and I should go do something else?...
> / h+
> ODE mailing list
> ODE at q12.org
More information about the ODE