[ODE] Proposal: Change Heightfield Origin

[Martijn Buijs]

Jason Perkins wrote:
 > Can you elaborate on why you think centering the origin complicates things?

When rendering a terrain, you usually start at [0,0] and loop through the vertices. Of course you 
can offset those as well, but at its simplest, the origin lies at [0,0]. If we'd offset the origin 
to the center, you need to take that in account in all your non ODE terrain calculations (quick 
height tests for AI etc).

I think in general it is easier to let the user to decide whether to offset it or not, rather than 
let some users correct it to get it back at [0,0]. However I agree that it just depends on what the 
user may find intuitive...

 > Yes, it is easy to apply an offset to change the origin, but I think
 > that's just another reason to make heightmaps behave like the other
 > primitives. You can always apply an offset to get the old behavior.

True, but it will be slightly less efficient if you don't want the offset.

David Walters wrote:
 > I've had a chance at changing this functionality now and it didn't go
 > very well. It's less efficient to do it naively and too significant a
 > change to totally redo for a different origin. I'm also getting
 > paranoid about offseting by half_width and half_depth which sounds
 > like a good way of introducing precision errors. I'm thinking that it
 > should be left as it is now...

That was sort of what I meant, but not sure if the precision loss is that significant.

 > If the geom was going to be used as a dynamic object then i'd push
 > hard to change this

In that case, I would have to agree with the both of you.

 > but as it's a collision oriented type I think
 > that it's not such an important issue.

Agreed.

 > For those of us running with real world data (eg derived from USGS
 > terrain datasets), double precision is actually very useful. What is
 > annoying is that there has to be two different compiled versions of the
 > codebase with either float or double precision. I work in a mixed world
 > where we have some of both contributing to models, so we really need to
 > have that mode where both paths are available simultaneously. Someone
 > said they were starting work on that, but not sure where that's got to
 > now. If nobody has started it after late august, I'll probably chip in
 > and do it. However, like several others on here, we have Siggraph to
 > deal with first so no immediate cycles.

Actually I've worked with USGS datasets before, and have never come across double precision data, I 
assume they exist but are probably rare. But I agree we should a 'double' path, if only for the sake 
of completeness.

I'd say:
1) we change the current 'float' data path from dReal to true 32-bit floats.
2) add additional 'double' 64-bit float path


Martijn