[ODE] Proposal: Change Heightfield Origin
buijs512 at planet.nl
Thu Jul 13 09:01:20 MST 2006
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.
> 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
1) we change the current 'float' data path from dReal to true 32-bit floats.
2) add additional 'double' 64-bit float path
More information about the ODE