[ODE] Large terrains

[John Miles]

> Hi John,
>
> Thanks for the great input.  What I'll most likely do, since it'll most
> likely integrate the smoothest with my current system, is create separate
> trimesh bodies for each patch in my terrain, which is typically 32x32
> cells... sometimes 16x.
>
> Did you find that the noticable hitch during body creation was easier to
> deal with than the large loading times, just out of curiosity.

They are both pretty annoying, but then I'm anal about that kind of thing.
I think the best compromise will be to create the bodies once using the
flatness optimization, when they're first needed.  That way the hitches
become less and less obtrusive during gameplay.

Being able to save/load TriMeshes directly *might* help, but I have a
feeling the hitch is due to tree insertion rather than object allocation.

> Also, what did you find to be the most efficient way for adding & removing
> geoms from the collision set?  Did you use your own structures to cull out
> the creation of the contact joints in the callback?  Or did you actually
> remove the bodies from collision space?  If the the latter, how did you
> handle it?  I'm fairly new to ODE... I've gotten quite familiar with the
> API, but I have only been experimenting with it for a week or so.
>

At this point, I can't seem to reproduce the circumstances that led me to
conclude that dSpaceRemove() was better than plain old dGeomDisable() (which
is annoying, because the difference I recorded earlier was substantial).

The results seem similar in both cases, so I would stick with dGeomDisable()
for now.

>One last question =]  Which space type did you find worked best once you
>had all of your techniques in place?

Quadtrees and hash spaces perform about the same in my experience.  I'd go
with whichever one uses less memory in your application.

-- jm