[ODE] some quick notes on 0.6...
gcarlton at iinet.net.au
Thu Jun 22 18:56:30 MST 2006
John Miles wrote:
>> 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
> 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
> -- john
If you have time to look at it that would be great. A nice solution
would be to get a single dTerrain with a setting enum (Y_UP, Z_UP), or
as you said above with an "up vector". That lends itself well to future
In case you are curious, I keep harping on about callbacks because I've
needed it last time I used ODE terrain, in prototyping a large world
where the heightfield was compressed to use a byte per vertex (with an
additional float height per "section"). In terms of cost it boiled down
to a function call, lookup and a few multiplications per "hit", which is
more costly but not outrageously so. There has also been talk of a
different interpolation scheme, which could either be put in as another
mode again or just left up to any user mechanism. A callback even
allows fun things like implicit terrains and sphere worlds (I think), it
depends on whether any collision code relies on a global "up"
direction. Anyway, as long as there is a single terrain type, this
extension is fairly trivial to put in next time somebody needs it.
More information about the ODE