btHeightfieldTerrainShape just won't aligned with me terrain

[mickey]

Code: Select all

btCollisionShape *heightShape = new btHeightfieldTerrainShape(width, length, mTerrain->GetHeightTable(),
			1.f, mTerrain->GetMinHeight(), mTerrain->GetMaxHeight(), 1, PHY_FLOAT, flipQuadEdges);

This was my final try before I give up, the scale height is set to 1.f, the min height and max height is exactly the min and maximum height generated by my terrain. They both use the same height table and i just set whatever floating height value on the height table to my terrain vertices.

Then I know i need to rotate -90 degrees whenever i render my terrain so it gets oriented properly with Bullet's terrain shape.

But I did find out about something. You would see on my right screen shot, when my generated terrain height goes down, Bullet terrain shape seems to go up. This happens along the edges.

The black color is bullet's terrain shape.

Thanks in advance for any ideas on how to make sure they align properly.

[Dragonlord]

This shape is rather rudimentary riddled with a number of problems. I simply rewrote the class ( making a new one using the bullet version as blue print ) and refactored the relevant methods into using my system. Prevents you from having all kinds of troubles and is faster ( no data conversion... and in my case I also needed holes in the terrain ).

Things I noticed in the process of this:
1) Cell spacing is hard-locked to 1 blender unit ( at last I found no way to alter this without messing with the scaling factors which is unsatisfactory )
2) Duplicate code ( code in getVertex and company gets called every time although being invariant )

But somehow I don't really see the problem with your terrain. Can you post a larger view or explain more in detail what is wrong? Is it shifted off center? Or is the stretching wrong?

[Erwin Coumans]

Thanks in advance for any ideas on how to make sure they align properly.

This shape is rather rudimentary riddled with a number of problems.

The btHeightfieldTerrainShape has been fixed and updated for Bullet 2.73. We should get rid of any remaining issue. Can you report every remaining bug in version Bullet 2.73 SP1 version?

Both mickey and dragonlord, can you provide a reproduction case, fully building source code testbed that shows the problem with btHeightfieldTerrainShape?
I'll make sure any issue we can reproduce gets resolved.

Thanks a lot,
Erwin

[Dragonlord]

What goes for the scaling I assume this can be done using the localScaling parameter. I though opted to re-implement the class since this way I could drop all the conditional branches ( since my terrain is always Y-up and stored in a float data type ). Also the scaling is not an issue since I tap directly in my data array using my own parametrization ( I'm using a different quad-split than the class uses by default ) and supporting holes ( a simple bit-array storing the visiblity of faces ). I don't think this should go into the main bullet since it's rather easy to extend the shapes on your own.

Now for the redundancy and the invariants ( all in the cpp of the height field shape ):

line 285-286:
During every call of this method 1/scaling is calculated for each vector component. 1/scaling is though an invariant changing only during setLocalScaling ( as far as I got this ). I precalculated the inverse scaling and stored it aside replacing a mul+div+intermediate with a simple mul ( i expanded the intermediate since it doesn't really help much ).

line 202ff:
m_width/btScalar(2.0) and m_length/btScalar(2.0) ara again invariants, in this case even class invariants ( m_width and m_length defined in the constructor ). Also precalculated those and tuck them away to turn a div+intermediate into a read-variable.

Could be called pre-mature optimizations but I tend to precalc stuff if I can afford the extra space.

[mickey]

and in my case I also needed holes in the terrain ).

Sorry just a little bit off topic, Id like to know how you do those holes in your terrain? I just use a simple deformation by lowering the height values in my 2d height table array:


( square craters, I have yet to make a circular crater and apply smoothing)

then couple it with texture splatting.

Anyway going back:

But somehow I don't really see the problem with your terrain. Can you post a larger view or explain more in detail what is wrong? Is it shifted off center? Or is the stretching wrong?

You can see on my first post image that on one part, my real terrain(white) overlaps Bullet's rendered terrain(gray), and on another part, Bullet's rendered terrain is higher/overlaps my actual terrain. They both use the same floating point height table.

No its not shifted off, they are of the same size, though Bullet's terrain seems to be rotated 90 degrees to the left.

The height just does not match.

[Dragonlord]

What goes for the holes they are real holes. I'm using a bit-array to declare if a face is visible or not. The final rendered mesh then omits those triangles ( it's done using indexing and a personal variation of CLOD ). In bullet I used my own class where in the process triangles method I also checked triangles for visibility using the same bit-array. Works splendid so far.

Now about the hight I could only think off the scaling value but you passed 1.0f there. When you said your terrain has to be rotated 90 degrees though a red flag just jolted up with me. In the blender height terrain class the lower left ( if you look down from bird view ) corner is (0,0) with increasing X to the right and Y to the top. For people using bitmaps in top-down ordering this causes the rows in the terrain to be flipped. Try once re-ordering the height image in bottom-up row order and make sure the coordinate system is matching.

[Erwin Coumans]

Hi mickey,

can you share a testbed that reproduces the problem?

Thanks,
Erwin

[mickey]

Hi mickey,

can you share a testbed that reproduces the problem?

Thanks,
Erwin

Hi Guys

I'm terribly sorry, my bad. I just needed to offset my terrain vertices and now they align properly. Truly sorry for the confusion.

btHeightfieldTerrainShape works great!

Thanks!

[tomva]

Hello mickey-

I recently made a bunch of changes in btHeightfieldTerrainShape (for 2.73), and there may be a bug with height offsets. It is possible to work around (I'm guessing that's what you did by adjusting the height values) but some clients may find it awkward or impossible to work around. I'll submit a patch for an upcoming release.

-Thomas