[ODE] some quick notes on 0.6...

[John Miles]

> As for the heightfield collider, I agree it should be in the
> trunk instead of a
> patch. I personally don't have the expertise to integrate it.
> Someone will have
> to contribute some time to do it. It's an open source project;
> that's how things
> work.

I'd be glad to integrate it as-is, but there have been some objections, and
I don't think they're entirely invalid (just that they reflect priorities
that I disagree with).  It *would* be nice if you could specify an arbitrary
orthogonal basis at initialization time.  And while I don't think callbacks
are the right answer for user-owned terrain -- it's not unreasonable for a
complex primitive to maintain its own copy of the data, the way OPCODE does
for instance -- I do agree that allowing local modifications to the
collider's copy of the terrain is necessary for a lot of applications.  A
subarea-replacement scheme might be the best way to do that.

I'll spend some time looking at it, and see if there's some room to address
the shortcomings that have been pointed out.  No guarantees, but if I can
get the terrain colliders into a state where everyone agrees they're worthy
of inclusion in the trunk, I think the library would benefit from the
effort.

-- john