[ODE] Colliider space/geom issues
bram at sara.nl
Sun Feb 26 03:59:21 MST 2006
John Miles wrote:
> That's fine, too; the instructions Benoit gave for integrating them with ODE
> 0.039 are still valid for the current version.
> I believe the objection to full ODE citizenship in the past has been their
> lack of support for collisions with trimeshes. I don't think that's a very
> pressing concern, because the usual applications for trimeshes seem to be
> terrain and static geometry that doesn't need to collide with height maps
> I have not tested the dCone primitive, but the heightmap terrain geoms have
> worked great for a long time.
Ok, I glanced at the code, but what immediately strikes me are the
distrinct classes for TerrainY and TerrainZ.
This looks like unnecessary codebloat to me.
Surely, the proper way to implement this would be to have a single
Terrain class, with a parameter 'height axis' that can be set to x,y or z?
Selecing the axis runtime instead of compile time may hurt performance
a little bit, but I wouldnt sacrifice maintainability of the code for this.
And if it's really important to have the last bit of performance, compile
time parameterization could be done with templates also, so we dont bloat
So what do you want me to do now?
(1) Merge the code as is.
(2) Rewrite the Terrain classes to a single class, or two instances of
a single template?
(3) Just dump this stuff in contrib/ as is.
Also, the contrib is presented as a unified terrain+cone.
Do these parts hold their merit on their own? Thus: if you
merge only one of these with the code base, would that make sense?
Or put differently: when --with-cone and --with-terrain are available,
would some users configure ODE with only one flag?
> (I just updated the files in the zipfile with a few cosmetic cleanup tweaks;
> you might want to re-download it before you do the update.)
> -- jm
>>From: Bram Stolk [mailto:bram at sara.nl]
>>Sent: Saturday, February 25, 2006 4:41 AM
>>To: John Miles
>>Cc: Ode at Q12.Org
>>Subject: Re: [ODE] Colliider space/geom issues
>>John Miles wrote:
>>>Cool -- I noticed it when diffing against an older version, and
>>>what was up.
>>>Here are versions of the dTerrainY, dTerrainZ, and dCone source
>>>work with the new geom-offset functionality. They appear to
>>work fine with
>>>the test_boxstackb program:
>>>Can someone with CVS access please move these into the
>>>contrib/TerrainAndCone directory of the unstable branch, so
>>>to be usable with the rest of the library? Thanks!
>>Well, as you have tested these, maybe they should go in the
>>source tree, instead of in contrib.
>>I'll try to do this this weekend.
>>Probably with a --with-cone configure flag or something.
More information about the ODE