heightfield successes lately???
joshua....@gmail.com
a callback, for particular use with ogre, and its terrain scene
manager, on which i perform ray traces or use the manager's member
functions to return height data about the generated heightmap mesh (or
whatever it is in ogre). I'm using the latest svn build of
ode_double.
I use this to place a four sphere'd car on top. when using the
heightmap as generated by a callback I suffer a rather significant
performance hit for starters...
where the geom is actually made changes depending on whether or not i
have wrapmode set on....
Id love to be able to flip a switch and turn on some visualisation for
the geom in some way... I know thats an ogre side thing... that way i
can see what geom ode is generating
when the car is resting on the height mesh it keeps bouncing on its
suspension, but this behavior is not seen when I rest the car on a
plane.
when the car drives on the heightfield it looks like its driving on
ice
What do you guys do to develop terrain to work with, to those of you
whom this applies?
Teravus Ovares
heightfield float array and expand it to 512x512 and then average the
blocks by the various surrounding blocks to 'smooth' the terrain
before sending it to ODE. It seems to produce less bouncy results.
Truly though, the heightfield in ODE has been the source of many a
problem. For a while there I had my own patches to deal with some of
it's 'wierdness'. I think I still have some of them applied to my
local build. Though it's gotten much better then it was in previous
versions, it still isn't perfect.
As far as submitting my patches to ODE's maintainers.. it's my
view that they have a more 'academic/idealist' view of the way it
should be done then practical. So, I highly doubt that they would
accept them.
Best Regards
Teravus
Daniel K. O.
> I've been trying to work with heightfields
ODE's heightfields have some known bugs; depending how you use it you
might experience missing contacts, wrong contact normals and even
normalization errors.
Probably because the easiest workaround is to just use a trimesh for a
terrain, nobody completely fixed the heightfield issues.
--
Daniel K. O.
"The only way to succeed is to build success yourself"
joshua....@gmail.com
digging through the docs, but how do you guys go about generating your
ode trimeshes? Do you get the data from an external editor and plug
that into ode and your rendering system of choice at once? or do you
make a new ode geom from data already obtained by your rendering
system? I understand you could probably do both, but I ask as an
inexperienced user, which makes more sense to do? To me it would be
the latter, and if thats the case, I wouldn't mind a little hint to
point me in the right direction! Thanks for your quick followups! I
appreciate the heads up about the heightfield class.
On Dec 2, 9:20 pm, "Daniel K. O." <danielko.lis...@gmail.com> wrote:
> jkord...@intlogsys.com escreveu:
Daniel K. O.
> As far as submitting my patches to ODE's maintainers.. it's my
> view that they have a more 'academic/idealist' view of the way it
> should be done then practical. So, I highly doubt that they would
> accept them.
Out of curiosity, could you elaborate what you mean by "academic/idealist"?
Jon Watte
>
> Out of curiosity, could you elaborate what you mean by "academic/idealist"?
>
>
I believe he means people for whom the trade-off between time spent and
degree of result obtained does not directly impact their paycheck. If
you're working for a studio where you need to achieve results X within
time Y to get another milestone payment, then results X matter, and
anything else does not matter. Meanwhile, if you are, say, a college
student (or, for that matter, faculty) who decide to work on ODE just
because the world would be a better place if available open source
physics engines were higher quality, your view of appropriate trade-offs
will be different.
Thus, suppose someone finds a real bug, and fixes it in a way that fixes
the bug, and does not introduce side effects, but offends some
maintainer's sense of purity, then you have a conflict:
- some people prefer to reject a patch for purity reasons, rather than
get the bug fixed
- meanwhile, the people who worry about their own paycheck will not go
back and re-work a fix that already fulfills their own requirements
In my opinion, if a patch fixes a bug without introducing side effects,
then the patch should be accepted. If the patch offends someone's sense
of purity, then that someone is free to submit another patch that
corrects whatever the stylistic problem is. However, in the general open
source world, I believe I am in the minority (although among highly
successful open source projects, my opinion might be a little more
common, perhaps).
Sincerely,
jw
Teravus Ovares
I don't mean it in a derogatory sense. :)
We definitely disagree on a few things as is evidenced by the past
e-mail on the list. For example, it's my belief that a good physics
library will run the best it can under the circumstances that the
library consumer gives it. It shouldn't ever error unless it's
completely unavoidable :). This view isn't shared by everyone :).
Obviously, I still use ODE :) and to great effect as is evidenced by
the ODE physics plugin in OpenSimulator(You can search youtube to see
some videos of it in action). Though, as I said, I have specific
patches that I use to handle error conditions that are specific to my
use of the library (without asserting) that are unavoidable (such as a
few of the terrain issues). Additionally I have code to resolve and
reset the scene if something really bad happens (such as a NaN 'black
hole').
As far as negative effects of my terrain patch. Sometimes it
produces odd results in a raycast against it. It still suffers from
the dNormalize issues, but the assert is squelched and the values are
checked by the ode library consumer.
of particular annoyance to my application is
(nMinX < nMaxX) || (nMinZ < nMaxZ)
and in some cases
numTerrainContacts <= numMaxTerrainContacts
These jump to dCollideHeightFieldExit with 0 contacts as opposed to
the svn functionality of asserting, because in some cases, they're
just unavoidable with the existing bugs. In practice, this doesn't
have any effects what so ever in my use of the library except that
it's more bullet proof. There's nothing that a library consumer can
do to moderate those effects without pre-calculating the situations (
to pre-calculate the situations, you'd have to run it through that
section of code anyway.. so it makes no sense) so, it's an
un-avoidable crash. The end user designs the layout of the terrain,
so, in my application, it is not possible to limit the terrain
situations to avoid a bug.
at one point I had a patch on the code that reads
if (depth > dEpsilon)
vertexCollided = true;
that changed it to
if (depth <= dEpsilon)
vertexCollided = true;
because that produced better contacts on everything *but raycasts*.
For a while before I patched this, at the peaks of terrain hills would
be a ring area where the contacts were about 1.5 meters below where
they should be and resulted in objects falling into the 'pits' and
getting shot back out again when the hit the border of the pit area.
But, this particular one has since been fixed and is no longer necessary.
Best Regards
Teravus
Oleh Derevenko
----- Original Message -----
From: "Jon Watte"
Sent: 3 грудня 2008 р. 05:00
Subject: [ode-users] Re: heightfield successes lately???
> Thus, suppose someone finds a real bug, and fixes it in a way that fixes
> the bug, and does not introduce side effects, but offends some
> maintainer's sense of purity, then you have a conflict:
> - some people prefer to reject a patch for purity reasons, rather than
> get the bug fixed
> - meanwhile, the people who worry about their own paycheck will not go
> back and re-work a fix that already fulfills their own requirements
>
That's a pity you can't answer my letters ;-), but just listen to the word
of wisdom:
The correct code is always beautiful.
So if the code is getting ugly/obfuscated/overweighted/etc..., this should
be a warning for you that you are doing something wrong. If you start
implementing everything in correct way and watch all the time for it to stay
in that correct way you would hardly ever need to apply a dirty patch to fix
something.
Oleh Derevenko
-- ICQ: 36361783
Danny Price
No two components have ever given me more trouble in ODE than trimeshes and heightfields!
Martijn Buijs
> Has anyone actually used ODE heightfields successfully in a non trivial
> application
Actually I have. :)
Then again, I'm the one who wrote the original dHeightfield API (though not the underlying math), so
I'm probably more aware of the problems to steer clear. I haven't touched the code in a while
though, and I don't pretend to understand what currently goes on behind the API functions (lots has
changed), but I've tried to follow the reports of the problems.
I believe most problems are due to 2 bugs:
1)
Rotated heightfields may produce some strangeness. Actually I've seen this reported only once, but I
have never had the chance to test rotated heightfields. The demo seems to work fine though. David
Walters may know more about this, he added this feature. Y-up heightfields work correctly for me.
2)
Penetration on heightfield grid edges. Contacts will be generated at the lowest heightfield sample
under the objects' AABB (called 'heightfield zone' in the code) instead of on the grid edge at
proper height.
This bug was introduced with the optimization patch, which merges coplanar grid triangles to fewer
planes to speed up intersection tests.
I and Oleh have both taken an in-depth look at this bug, we thought it may be related to floating
point accuracy but that appears not the case. I don't think either of us has any ideas left as to
what causes this problem.
Unfortunately Olehs attempts at this have removed a workaround for this bug. Which was a 'margin'
constant that extended the heightfield grid triangles on the horizontal plane. It added some grid
edge overlap and thereby 'filling' the gaps caused by the bug. This isn't correct and 100%
fool-proof, but currently works well for me. Perhaps we should revert to the old code so at least
there is a workaround for the time being, right now it is broken to the point where heightfields are
practically useless.
3)
There _was_ a third problem, similar to the second, and related to the optimization patch, but that
has been fixed (I think since 0.9).
> No two components have ever given me more trouble in ODE than trimeshes
> and heightfields!
Trimesh collision detection are generally know to be a 'hard problem'. Heightfields on the other
hand should not be 'hard'. We should really fix it.
At some time in the near future I will have to add support of 'diamond' style heightfield grids
(e.g. for ROAM terrains) so I will probably have to revise large parts of code to add this.
Hopefully I will negate this bug in the process, but if it turns out to be still effective it may be
better to remove the optimization altogether or re-write it from scratch.
Any help with this will be greatly appreciated. I'm not an expert in this field, most of my
contributions so far have been superficial. But as the co-author and person who pushed for
heightfields to be included in ODE, I feel responsible for these problems.
If the author of the optimizations (Paul Cheyrou-Lagreze) reads this, please tune in if you have the
chance.
And to hell with 'academics' Teravus, send in those patches. ;) I will have a look at it.
/Martijn
Oleh Derevenko
----- Original Message -----
From: "Martijn Buijs"
To: <ode-...@googlegroups.com>
Sent: 3 грудня 2008 р. 15:22
Subject: [ode-users] Re: heightfield successes lately???
I just implemented a correct handling for floating point numbers that
guarraneed that no collision test falls into two triangles at once and no
one is lost in between of triangles. With this change, if everything else is
correct, adding overlap should be unnecessary. So if it does not help, that
means the overlapping is not a direct solution but just a workaround that
fixes the main bug by instroducing some side-effects.
Also, I clearly remember that you have found the reason of the problem and
it was not related to the triangle overlapping at all. You just had no idea
how to fix it then and in time everybody has forgotten about that bug. I can
look through older posts and find that letter, if necessary.
Martijn Buijs
> guarraneed that no collision test falls into two triangles at once and no
> one is lost in between of triangles. With this change, if everything else is
> correct, adding overlap should be unnecessary. So if it does not help, that
> means the overlapping is not a direct solution but just a workaround that
> fixes the main bug by instroducing some side-effects.
Indeed, the overlap that initially came with the optimization patch was a hack, incorrect and did
introduce noticable side effects. I mentioned it because it is only 'less broken', and works better
*in practice*.
But I know you don't like that, and honestly, I don't either. :)
> Also, I clearly remember that you have found the reason of the problem and
> it was not related to the triangle overlapping at all. You just had no idea
> how to fix it then and in time everybody has forgotten about that bug. I can
> look through older posts and find that letter, if necessary.
>
> Oleh Derevenko
> -- ICQ: 36361783
Yes, I recall the discussion. Perhaps my wording was unclear but I meant 'I know exactly what the
bug *is*' rather than 'I know exactly what *causes* the bug'. I really have no idea what *causes*
the bug.
/Martijn
Oleh Derevenko
----- Original Message -----
From: "Martijn Buijs"
To: <ode-...@googlegroups.com>
Sent: 3 грудня 2008 р. 16:03
Subject: [ode-users] Re: heightfield successes lately???
>> Also, I clearly remember that you have found the reason of the problem
>> and
>> it was not related to the triangle overlapping at all. You just had no
>> idea
>> how to fix it then and in time everybody has forgotten about that bug. I
>> can
>> look through older posts and find that letter, if necessary.
> Yes, I recall the discussion. Perhaps my wording was unclear but I meant
> 'I know exactly what the
> bug *is*' rather than 'I know exactly what *causes* the bug'. I really
> have no idea what *causes*
> the bug.
Ah, sorry. I looked at the old letters and, indeed, the bug that was clear
was fixed by commenting a part of the function. And another one with loss of
contacts near the triangle edges had remained unsolved. :-(
Danny Price
What advantages in particular do heightfields present over trimeshes other than the fact that you don't need to define the mesh?
Martijn Buijs
> Why we are on the topic, can someone recommend a guide to using ode
> heightfields? I've not been able to find any documentation anywhere. I
> was able to make a basic one by using some code I found online but the
> collisions were completely messed up.
>
> What advantages in particular do heightfields present over trimeshes
> other than the fact that you don't need to define the mesh?
Reduced memory usage. Only need a 2d array of values in a format of choice (byte, short, float,
double) and allows compression/paging (via GetHeight callback).
It also allows for fast deformable/animated heightfields, for example to simulate water surface or
destroyable terrain. Trimesh requires updating the acceleration structures, which is often slow.
Trimesh triangles are infinitely thin, objects may pass through depending on timestep. Heightfields
are infinitely thick below the surface and 100% guarantees that contacts will be generated at any
point under the surface.
---
I was going to add some illustrations to the dHeightfield section (
http://opende.sourceforge.net/mediawiki-1.6.10/index.php/DHeightfield ) on the ODE Wiki, but the
wiki seems to be still in limbo. Any updates on that? Maybe we should just move away from SF.net, it
has been slow and generally unavailable for the last year or so. Perhaps Google Code has a nice
solution for documentation?
/Martijn
Danny Price
Martijn Buijs
> It needs a code example of useage more than anything. Given how many
> people use ODE, I'm surprised so few examples exist.
Are you aware that there's a demo in included with ODE ("demo_heightfield")?
/Martijn
Teravus Ovares
float[514 * 514]). The region is actually 256m^2
I paraphrased some things because on our implementation the y is
flipped and the array is y ordered instead of x ordered however, the
code looks something like this:
IntPtr LandGeom;
int m_regionWidth = 256;
int m_regionHeight = 256;
float[] m_heightmap = new float[514 * 514];
// double the region size, add two samples
int heightmapWidthSamples = 2 * m_regionWidth + 2;
int heightmapHeightSamples = 2 * m_regionHeight + 2;
//looped for x and y - flatten out array
m_heightmap[x*heightmapHeightSamples + y] = height[x,y];
// create unmanaged reference
IntPtr HeightmapData = d.GeomHeightfieldDataCreate();
d.GeomHeightfieldDataBuildSingle(HeightmapData, m_heightmap, 0,
heightmapWidth, heightmapHeight, (int) heightmapWidthSamples, (int)
heightmapHeightSamples, scale, offset, thickness, wrap);
d.GeomHeightfieldDataSetBounds(HeightmapData, m_regionWidth, m_regionHeight);
LandGeom = d.CreateHeightfield(space, HeightmapData, 1);
this produces a 'double resolution' heightmap.
Then the terrain must be rotated in our case;
Vector3 v3;
float angle;
d.Matrix3 R = new d.Matrix3();
Quaternion q1 = Quaternion.CreateFromAxisAngle(new Vector3(1, 0, 0), 1.5707f);
Quaternion q2 = Quaternion.CreateFromAxisAngle(new Vector3(0, 1, 0), 1.5707f);
q1 = q1*q2;
q1.GetAxisAngle(out v3, out angle);
d.RFromAxisAndAngle(out R, v3.X, v3.Y, v3.Z, angle);
d.GeomSetRotation(LandGeom, ref R);
// finally we put it in the middle of the region
d.GeomSetPosition(LandGeom, 128, 128, 0);
* Note: the use of the Quaternion class used to be the ODE Matrix
class, but OpenSimulator is a community project and someone felt it
was more clear using quaternions from a different library.
Best Regards
Teravus