Shaky Crabs

[Bird]

Not anymore.
https://answers.microsoft.com/en-us/win ... 4a58259bd1

I already started a LW plugin to import GLTF a while ago. It shouldn't be too hard to get it working since all that's needed is the geometry

[Julio Jerez]

Ok, mean time I will work on that fix.
I am confident that is the biggest problem after seeing the density of the mesh.

[Bird]

Okay, I successfully made a LW plugin that imports the GLTF files so that LW can export to FBX. Seems to work .... at least Microsoft 3D object view loads them both as FBX

I put them on my google drive and send you a share. Hopefully you don't need permission now.

[Julio Jerez]

ok I have the files.
dude you are insane

this is how that mesh looks like

Untitled1.png (339.76 KiB) Viewed 9911 times

and I have to scale it in max 1000 time, the mesh is so dense that it looks as if is has a bump map texture on it.
is has several million triangles

I am going to use for making fix the bug that the engine use a small buffer to collect the intersecting faces, and any face that does not fit is rejected.

so after I get that in I will place the crab, and see how that work. them

we can see how to make the more efficient.

do LW has polygon reduction tools?

try to reduce the resolution, and use that a more simplified mesh for collision
I think that should fix the problem

[Julio Jerez]

I committed the test case, for the fix.

them we can talk about some tweak to get is going.

if you run the test, the mesh looks all white, because there is not texture, I can probably lay a check board laters.
but if you select debug simplay wireframe, then you can see it.

I also make a hard code tolerance that reject small polygon ten time smaller.
so if you try again, I will load more faces.

but that will no really fix it, for that I have to complete the quires, them I will try to load the original again.

one question, what unit are you using, when I load the mesh in max, is look so tiny that it is almost invisible, for me to see anything I have to scale 1000 time.

[Julio Jerez]

this is how it looks if I scale 100 time and I place a monster truck in the middle for reference

Untitled1.png (380.48 KiB) Viewed 9908 times

and even at that 100 time magnification there are ton is really tiny triangles wit edge smaller than 1 milimeter.

this is quite a challenge. But I take it.

[Bird]

the mesh is so dense that it looks as if is has a bump map texture on it. is has several million triangles

Yeah, the object was made using a photogrammetry tool called Meshroom and there was no poly reduction on it.
https://alicevision.org/
https://sketchfab.com/3d-models/rocks-m ... 0ac17ac6d9

one question, what unit are you using, when I load the mesh in max, is look so tiny that it is almost invisible, for me to see anything I have to scale 1000 time.

Haha. I found the problem. It's the crab that's huge. It's bounding box is nearly 1000 units in x and z and over 300 in y. I didn't notice because my app automatically normalizes all dynamic bodies when loaded ( makes the biggest dimension 1) The marine rocks static mesh bounding box is 4 x 5 x 1 in LightWave. In my app I scale it by 2.0

[Julio Jerez]

are you saying that after the scaling of the crab, the behavior is better?

I am still making the change for buffered polygon queried to and unbuffered one.

the buffer method is a legacy for the late 90's early 200's
meshes are high density now, and the buffered become unpractical.
I will work on that over this lang weekend.

of your scene,
my recommendation is that you apply some polygon reduction to the ground mesh.
you can probably decimate by a factor of 10, and it will still be fairly representative of the collision mesh, certainly a factor of 5.

them you can set the convex hulls max vertex to say 64 or higher and the scene should execute at much higher performance and stable

[Bird]

are you saying that after the scaling of the crab, the behavior is better?

No, in my app the GLTF crab is already scaled, so the behavior is the same. It's only the FBX mesh that I gave to you that is huge compared to the marine rock mesh.

my recommendation is that you apply some polygon reduction to the ground mesh.

I'm working on that now.

[Julio Jerez]

When you say 4x5x1

4x5 seem rather small by looking at the features of the terrain. Are those units meters.

If so I can apply that scale to make match exactly what you have.

[Bird]

I think units are arbitrary but they can be meters

If I query the bounding box of the marine rocks after applying the 2.0f scale I get

Code: Select all

 
ndMatrix startPose;
ndVector min;
ndVector max;
shape.CalculateAabb (startPose, min, max);

Rocks Min = -5.21654, -0.57037, -4.08912
Rocks Max = 5.21654, 1.59912, 4.08912

The crab has 1.0 scale and normalized so that the largest dimension is 1.0f
Crab Min = -0.403971, -0.155703, -0.500000
Crab Max = 0.403971, 0.155703, 0.500000)

This is what it looks like rendered in my app

crab_scene.jpg (180.12 KiB) Viewed 9879 times

[Julio Jerez]

ok, just now just wait until I get the fix and we try again.

[Julio Jerez]

Ok, I spend some time trying to figure out how to maje this better.

I try to change the algorithm but that was a huge mistake, after getting running I realized it had some many problem than it was not worth getting running.
The problem is that the corrent method is buffered. Meaninion it collect the faces intersecting an obb, and the process those faces. I try to make it unbuffered.
But the changes are just too many, that that's a probably a feature for a next release, so a saved and reverse the github.

What I did was to make the buffer variable size,
So it will now collide with all the faces at the spence of running slower.

For that mesh, with the test convex I am using it gets really slow, the mesh capture fro 8 to 10 thousands faces per query, and that's too many.

Anyway, if you sync, you can try the sandbox, and you test again, let us see how this tweaks behave, before going to new algorithm
try to scale the floor mesh to the size you mention, 10x8×4

[JoeJ]

terrain.JPG (235.5 KiB) Viewed 9858 times

Here an image from my terrain, as i have quite the same problem.
This is a very low lod, but if we would zoom in to the detail the collision mesh should have for a game on the surface, we would see similar structures and details, just at higher frequencies.
(I'm currently working on making the meshing pipeline out of core, so i can generate such large data sets at all.)

Once i have this working, i can start work on generating a reduced mesh.
However, the problem with mesh reduction is:
At smooth regions (valleys) we can achieve aggressive reduction, so performance will be much better.
But at regions with structure and detail (mountains), we can't reduce so much. So at these regions perf. will be still worse, and we require a large buffer for many triangles.

Thus, mesh reduction won't give us a uniform, guaranteed speed up. So it's nice to see you plan to improve this. If the OOB is large, there is no guarantee that a fixed size buffer will be large enough for all cases, effectively forcing us to use 'small' game objects. (I don't think that's a big problem, but ofc. a more general solution would be better.)

For an alternative i could use tiles of heightmaps to represent most of the terrain.
But won't work for cliffs and caves. And i don't want to use heightmaps at all, because with a mesh i can represent the whole static world, including buildings.
So by using tiles of meshes, i can use a regular grid to find the tile, and then only one BVH per tile is needed to find all static collisions. I don't need multiple, overlapping acceleration structures for terrain, rocks, and buildings.
So i assume the 'one mesh for all' approach should be also the fastest solution in the end.
That's why i'm personally convinced that heightmaps are a thing of the past.

Though, there is more to this than just collision detection.
I was playing the Uncharted game, which really is a good example of actions i want to achieve with robotic ragdolls.
Climbing is an important mechanic for this game. Similar to Tomb Raider, the character can climb and handle along paths made from edges. It can also jump from a current path to another nearby path.

Likely they make those paths all manually during level design.
But it would be much more interesting if we could detect them at runtime, as part of the AI system.

Thus, for such things it would be necessary to have adjacency information for the mesh, so we can traverse it for AI purposes.
That's maybe a reason i would decide to make my own static mesh primitive, as you have suggested i probably should.
But not sure yet. Just mentioning it in case you consider to add full adjacency for future changes.

[Bird]

Not seeing much change in the latest version. I switched out the crab for a tetrahedron

https://youtu.be/GH1A4gC0u-E

In Lightwave, I merged vertices, fixed a non-manifold problem and reduced the mesh from over 1 million tris down to 300,000 and the penetration problems are mostly gone but the pile doesn't seem to settle now.

https://youtu.be/iXeGi8eDzhA