[ODE] CVS repository available

[Adam Moravanszky]

> > Great.  I was looking at your TODO list there, and was wondering
> > when/how you/we want to implement some way of approximating collision
> > times (undoing a step that penetrated too far and/or asking collision
> > system how far it is OK to go).
>
> i have no plans to do this.

Perhaps you should elaborate on why you feel so strongly about this.  You
say this in the docs:

However ODE takes fixed size steps, as automatically choosing a
non-penetrating step size is problematic for an articulated rigid body
simulator (the entire ARB structure must be stepped to account for the first
penetration, which may result in very small steps).

It seems to me that in such a case, you are worried about a drop in
performance due to smaller time steps, but that is the user's problem (if he
chooses to make use of the suggested feature)  not yours.

Again, my OBB contact finding code cannot find appropriate contacts for deep
intersections.  If you explain that the changes suggested are indeed not
required, I will change the contact code, otherwise I will amend ODE to
carry out these steps, as you suggest in the docs under 10.3:   "Do your own
variable sized time stepping somehow. "

On to problem #2:

>you can use ODE's collision  system imdependently of the dynamics.

Yes, but I can't use ODE's dynamics independently of the collision system.

dContact is a true ODE-dynamics (non-collision-library) structure, but it
references dContactGeom, which in turn references dGeomID, which is the core
class of the collision detection engine.  That is the dependency. I know
that this reference is not currently made use of; so I am simply asking for
its removal.  Because a 3rd party collision library cannot provide these
DGeomID-s.

struct dContact {
 ...
  dContactGeom geom;
};

struct dContactGeom {
    ...
  dGeomID g1,g2;
};

I am also aware of your "User defined collision classes" mechanism, but this
is more appropriate for adding a few simple shapes rather than interfacing
with an existing library which already has its own space partitioning, pose
update, and pairwise contact determination for all the geometry types
already.


>do is use the collision part without *linking in* the dynamics part.
>and in fact with the appropriate set of headers you probably could do
>this. IMO this is not a big issue.

I would also change this, but it is indeed not a big deal.

--
-- Adam Moravanszky
http://n.ethz.ch/student/adammo/