HeightfieldCollisionShape limitations

Github wiki docs for HeightfieldCollisionShape says:

A mesh-accurate shape optimized for static terrains. This shape is much faster than other mesh-accurate shapes. +Limitations: Requires heightmap data. Collisions between two mesh-accurate shapes cannot be detected, only non-mesh shapes can collide with this shape.

Sounds good so far.

What’s concerning is that the source comments have some additional tricky and intimidating limitations that weren’t mentioned in the wiki:

Uses Bullet Physics Heightfield terrain collision system. This is MUCH faster than using a regular mesh.
There are a couple tricks though:
-No rotation or translation is supported.
-The collision bbox must be centered around 0,0,0 with the height above and below the y-axis being
equal on either side. If not, the whole collision box is shifted vertically and things don’t collide
as they should.

I haven’t been able to wrap my head around the amount of hackery and additional design workarounds needed to simulate something like a planet’s surface given these limitations, but that part is my problem. I’m thinking of creating a “Cube Sphere” (like this Cube Sphere, a Unity C# Tutorial ) using 6 curved surfaces. I need to stay close to 0,0,0 to maintain floating point precision anyway, so I guess that’s fine, but no rotation/translation seems painful.

Anyway, the main point of this topic:

  • Is the above documentation accurate and up to date? Both correct or just one?
  • Are these Bullet (jME 3.1 native Bullet) limitations or something specific to jME’s integration with Bullet? I don’t remember finding limitations like this in Bullet’s docs. (I could have forgotten, it was awhile ago.)

I think all those quirks and restrictions come from native bullet:
http://bulletphysics.com/Bullet/BulletFull/classbtHeightfieldTerrainShape.html

It’s not said using the same words, but yeah it seems that way. I was looking in Bullet’s pdf manual, not the javadocs.

I guess I need to experiment with ways to try and keep the world/view rotated in such a way that any nearby heightfield surfaces are always towards -Y, “below” where the camera and physics enabled stuff is. (I see our HeightfieldCollisionShape sets upAxis=1 so +Y is “up”.)