[ODE] some quick notes on 0.6...

[Geoff Carlton]

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

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.

Geoff