[ODE] some quick notes on 0.6...

[Martijn Buijs]

** Didn't show up on list, removed attachment. **

Geoff Carlton wrote:
> 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

Hi,

I have some heightfield code (see attachment or http://home.planet.nl/~buijs512/ode/ ) that may be
useful. It supports both a callback AND copy/reference data mechanism, but only does Y-up terrains.
It is not final but I think its a good foundation to go from.

If someone could review and commit it I'd be very grateful. And hopefully it gets things going. :)

Martijn