[ODE] cylinder collision. (and correction)

[cr88192]

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

>
> 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 :-)
>

major plug:

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 
least...).

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 
troll).


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, 
maybe).

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

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 
thus far)?
..

that or it is all pointless anyways, and I should go do something else?...


> Cheers,
>
> / h+
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>