Yo @arcman7 and @Cedric
Here is an example of creating a btHeightfieldTerrainShape from babylon mesh data. But as you can see it doesnt quite work right… the sphere go right thru the mountains.
If you change line 58 to call ammoMesh instead of ammoHeightmap it works perfect.
So i am wondering if its the actual ammo btHeightfieldTerrainShape that is the problem or some how directly setting the vertices position kind as the heightdata is the problem… as we as passing the whole positions array instead of ONLY the Y components
You’re missing some of the code required to pass the the vertices data to Ammo so I added that in for you. You also need to set the scaling, added that as well.
This should clear it up for you - height map is rendered in red, and you can visually see how its off from the visual mesh (or rather the visual is off from the physical):
Setting the origin to (0, averageY, 0) was the correct way to go. See if you can get the hmap visual to align with the model:
The reason I’m interested in seeing both the world model and the hmap point clould system aligned is because babylonjs and ammo js have their respective z-axis flipped. You have to account for that somewhere in the code.
I like this approach a bit better that serializing the unity generated raw heights. If i make one solid piece of geometry for the terrain and just get the heights from the positions… that seems like the best and most efficient way to generate the heightmap (just need to fix the alignment) and alot faster that the function that took 3 or 4 mins for a 100 x 100 heightmap
this looks like the magic code here that simply creates an Ammo heap with the actual heights of the mesh for which it is providing collision for
/* they're the same for all rectangles m x n, where n == m */
const numberOfRows = subdivisions
const numberOfCols = subdivisions
const ammoHeightData = ammoInstance._malloc(
4 * numberOfRows * numberOfCols
)
console.log('here')
let height
let p2 = 0
for (let i = 0; i < heightData.length / 3; i++) {
height = heightData[i*3 + 1]
ammoInstance.HEAPF32[ammoHeightData + p2 >> 2] = height
p2 += 4
}
and use ammoHeightData in the btHeightfieldTerrainShape constructor
I like this way better
1 Like
Something doesn’t quite line up
Using a righthanded system (like Ammo)
I think I’m missing something obvious here, but this has been bothering me in my own projects. The z-axis is flipped but those vertices don’t seem to line up correctly with the model.
All the stuff i ever been doing in Ammo has always been with left handed geometry… all the triangle mesh stuff, convex hell… all come from using left handed geometry and scene.useLeftHandedSystem = false… I will try in my toolkit… but gonna take a sec to set all this up in my Babylon Toolkit with left handed geometry
Yo @arcman7 I cant tell what the latest fixed playground we are working on to use the getVerticesData to get the raw mesh heights. And where we are with trying to align the heightmap to the original terrain mesh ?
I’m aiming for these three things to be alinged:
- Physics ammo vertices, showHMAP vertices (red dots from the point cloud system), and the visual model with the globe stretched flat.
I’m relying on showHMAP vertices for getting a sense of where the physics vertices are, so the first task is to make sure they’re aligned correctly. I’ve just been visually inspecting how the spheres collide to get an idea of how aligned they are, this isn’t a great way.
The next goal is then trying to align the visual flat globe with the showHMAP vertices.
This achieves a few things:
- That the height map data being produced is right, there should be hills where we expect them and generally all of the physical geometry should match up; your ammo mesh method could already validating this for us.
- That the offsets and transforms we use to align the ammo vertices are also correct.
Ofc if you’re able to use the ammo debug drawer interface you don’t even need the hmap visuals, and this whole process becomes easier.
And where we are with trying to align the heightmap to the original terrain mesh ?
We are setting the rotation quaternion of the ammo heightmap rigid body and the globe model
What mods to ammo do you need to get the debug drawer going. IMe or Cedric are they who have been building the ammo.js release in the Babylon Dist folder.
Let me all all the changes and I’ll add them to all my btSmoothTriangle changes I made for ammo
I been trying to get the powers that be BabylonJS to fork a branch of ammo so we can maintain our fixes we have for ammo
But still no joy… so I been keeping these changes on my machine to date
Oh Shit… I forgot… i did this already. I made the fork here GitHub - BabylonJS/ammo.js: Direct port of the Bullet physics engine to JavaScript using Emscripten
Yo @arcman7 … I can update the repo with the changes you need. Send em to me
The very most recent builds of Ammo.js just using the normal master branch should have the debug drawer interface. I also opted to increase the allowed memory usage by a factor of 4, this is present in the ammo js build I linked to in the gist.
Do you know how to add these features?
- Please expose btTriangleIndexVertexArray · Issue #398 · kripken/ammo.js · GitHub
- the setLinearVelocity for btKinematicCharacterController is not exposed · Issue #341 · kripken/ammo.js · GitHub
These would be amazing to have.
I did a sync from main branch
Please check my BJS branch. that it has the debug drawer stuff in it
I will look into exposing the others
1 Like
Can we change the contents of this file to:
version: '3'
services:
builder:
build: .
volumes:
- .:/code
command: bash -c "rm -f builds/ammo.* && cmake -B builds -DTOTAL_MEMORY=1073741824 -DCLOSURE=1 && cmake --build builds"
I can’t make issues on your repo.
the default size for babylon is 128MB
Note: You and i should talk. We need to meet up. I know what you are talking about and i maintain several HEAP SIZE Builds in the Babylon Toolkit.
There is an option to select the ammo build size when you export your project from Unity
But i dont think the powers that be for babylon are gonna want the DEFAULT heap size for ammo to always be 1GB of memory. So i think when i make the builds for babylon dist folder. i set it to 128MB (which is at least better than the 64MB that kripken build is using)
1 Like
I might make a builds folder in our BJS branch and keep the different size builds there as well
1 Like
Can you add me as a collaborator? I’ll create a separate branch that can be used for enhanced gaming builds
@Cedric @sebavan @Deltakosh hey would yall mind if the memory heap were resizable as opposed to some fixed size? Currently I set the heap memory limit to 4x the default. It would be nice if we could continue adding cool features into the babylon js ammo js build.
I think the fixed sizes are a bit faster than the resizable builds. I could be wrong. But I thought I read that somewhere. @Cedric is da ammo man, ask him for sure.
1 Like
Yo @arcman7 there are now different build sizes
2 Likes
Oh I love that, great idea to let people chose!
1 Like
