Errors in mapping btHeightfieldTerrainShape to Terrain

[Spangle]

Hi All,

Over the last few weeks I have just been playing around with Bullet and OGRES. I have been trying to use the btHeightfieldTerrainShape to map over the heightmap rendered through OGRES.

After much fighting to force the Collision Vertices to render using the processAllTriangles() method, I discovered that the collision map was slightly off compared with the rendered equivalent.

I believe I have tracked the difference down to an integer divide in the getVertex() method of btHeightfieldShapeTerrain. By changing the setValue methods from:

Code: Select all

setValue(-m_width/2+x, height, -m_length/2+y)

to:

Code: Select all

setValue(-m_width/2,0f+x, height, -m_length/2.0f+y)

, the terrains map much closer. Ordinarily this wouldn't be a problem if you have an even number of points in the width & height ! It is just unfortunate I am using 257 x 257 !

This does have a knock on effect, because there can now be cases where the range of triangles assessed for collision does not include the correct one. To overcome this I have enhanced the quantisation mechanism to round further up or down by adding 0.5 in magnitude to the point values. i.e.

Code: Select all

int x' = int(x + 0.5*abs(x)/x)

.

So this seems to work for me, and matches the OGRES terrain well. Can this be raised as a bug ? Or am I using this in completely the wrong way ?

Thanks,
Spangle.

[Erwin Coumans]

the fix for

Code: Select all

setValue(-m_width/2,0f+x, height, -m_length/2.0f+y)

sounds reasonable, so it will be changed. I'm curious about the other one

Code: Select all

setValue(-m_width/2,0f+x, height, -m_length/2.0f+y)

It might be related to the way OGRES handles heightfields. Do you have a link to OGRES, your demo, or more information how the heightfield of OGRES is exactly specified?

Thanks,
Erwin

[Spangle]

Attached is a VC8 project that I was using to play with the heightmap terrain. It is a very simple ball that drops onto the terrain and rolls down over it. I am also using OgreBullet to help tie in with Ogre and I have also done a bit of jiggery pokery so that I could use the same processAllTriangles() routine that is used in the collision determination to also render the triangles on screen.

I have also included the bullet files I have changed to try and give you an idea of what I am trying to show (All changes marked with SMJ). Basically, when I made the first change (move from int to float), the ball started rolling, but would eventually fall through the floor ! I eventually decided that in some occassions the wrong triangles where being used in the collision eval, and so that is why I made the second change.

Please let me know if I you need more detail.

Many Thanks,

Spangle.

[Erwin Coumans]

I just applied your suggestion, so it will go into Bullet 2.64.

Thanks a lot for the feedback! If you have any demo/showcase to share using OgreBullet, please let us know,
Erwin