The mesh walking elevation bug

[ChinRey]

Has anybody managed to figure out exactly how much we need to offset the elevation of a mesh floor with hull physics or is it still a question of trial and error to get it right?

[Drongle McMahon]

I measured the gap between bottom of feet and visible surface to be 0.075 - 0.0275*d, where d is the thickness of the prim I am standing on, when it is set to Convex Hull. The 0.075 is the avatar hover height, The 0.0275*d is the distance the hull surface is retracted from the visible surface.

ETA. If you use a cube mesh to make a physics shape that fits the bounding box, and Analyze it, it will make a "Prim" type shape with physics weight 0.36 which does not retract from the bounding box of the mesh. Whether that's useful depends on whether the floor is supposed to be there.

ETA corrected "+"to "-"

[ChinRey]

I should have mentioned, this is for floors with stairwells in them. Can't use triangle physics since the "doorway bug" will close the hole so I have to do it with analyzed physics.

There is a significant deviation in the walking elevation on a mesh surface made with analyzed physics even when physics shape type is set to prim and as far as I know, the only solution is to add an extra "offset" hull to the physics model to force the physics shape of the floor down a little bit. The question is, how much? Up until now I've just solved the problem by trial and error on the beta grid but that does get a bit tedious in the long run so I thought I' ask if anybody's examined the issue and found an answer.

Drongle's numbers seem to fit quite well with my experience so it is possible that the mesh retains the same error when set to prim physics shape as it as as a convex hull.

[Drongle McMahon]

If you upload a PERFECTLY flat plane with a hole in it, the uploader detects that the z dimension is zero and sets it to 1.0, to avoid a divide-by-zero error later on. In that case, when it is used as the triangle-based physics shape as well, it will not be affected by the "doorway" bug*, as that only happens if a dimension is less than 0.5m. The triangle based shape is in the plane at the centre of the z dimension. It does have some odd behaviour though. It seems to have no resistance if you walk into it horizontally although you can stand on it. You can close the hole in the physics by reducing the z dimension to <0.5m, when it becomes convex hull. When you do that, it doesn't move.

There is another way of avoiding the hole-closing, by adding a perpendicular triangle (as large as practical, to minimise weight increse) that will be buried inside a wall or in the ground. That keeps the bounding box > 0.5m thick.

*I'm not sure this behaviour should really be called a bug, as I believe it was put there deliberately to avoid the large loads on the physics engine from collision detection with the narrow triangles around the edges of thin walls etc.

[ChinRey]

---

Drongle McMahon wrote:

If you upload a PERFECTLY flat plane with a hole in it, the uploader detects that the z dimension is zero and sets it to 1.0, to avoid a divide-by-zero error later on. In that case, when it is used as the triangle-based physics shape as well, it will not be affected by the "doorway" bug*, as that only happens if a dimension is less than 0.5m. The triangle based shape is in the plane at the centre of the z dimension.

---

Yes, I sometimes use that trick for zero thickness sheets but on a walkable floor with a defined thickness it would mean you'd sink halfway into it which is even worse than hovering slightly above.

---

Drongle McMahon wrote:

There is another way of avoiding the hole-closing, by adding a perpendicular triangle (as large as practical, to minimise weight increse) that will be buried inside a wall or in the ground. That keeps the bounding box > 0.5m thick.

---

Or you could just tilt the floor/wall so it has a nominal size of more than 0.5 m along all thre axises. But both these techniques have several disadvantages. For a start, aligning meshes and prims in a complex build precisely inworld is hard enough even if you don't have to compensate for those tricks.

So I think analyzed physics with hovering height compensation is the best - I mean least bad - option and that means figuring out exactly how much compensation is needed.

[ChinRey]

I tried to do some tests and here are the results so far.

 

I uploaded a simple model made from two cubes with a slight gap between them. Overall size of the mesh is 4x8x2 m:

 

I used my regular body shape (Tokyo Girl Sori) which has a hover on ground about as exact as you can possibly get in SL:

AO was switched off of course but I couldn't figure out how to disable the default system animations

 

Standing on the model, with analyzed physics and physics shape type set to convex hull gave this result:

I can't imagine we can expect anything more precise than this in SL.

 

Contrary to Drongle's observations, increasing the z dimension of the mesh did not increase the gap, quite the contrary. Here it is with the height changed to 4 m:

 

 

 

Once I changed the physics shape type to prim, I rose up into the air:

This is of course a completely unacceptable result and some kind of compensation is needed.

 

Interestingly, the same model but with unanalyzed physics gave pretty much the opposite result.

With physics shape convex hull:

 

With physics shape set to prim:

 

Changing the dimensions of the mesh didn't affect the hover error at all. Even with double the height, the result was the same.

Here are my lovely freebie sneakers on a good old 4x4x2 m prim:

Here there was no noticeable difference between prim and convex hull physics shape.

 

Oh and this as a curiosity. Here I'm standng on the analyzed hull mesh with the physics shape first set to prim and then back to convex hull again:

I was not able to reproduce this so it may have been just a glitch and it was corrected when I took the mesh into my inventory and rerezzed it.

Once I switched on my AO, it became clear that the hovering height doesn't track the surface quite as well on a mesh as on a prim or on the ground. (Obviously SL uses a completely different and separate algorithm for calculating hovering height on a mesh surface than it does on the ground or on a prim but that's hardly a surprise.) This means that it makes sense to add alittle bit of hover to a walkable mesh surface to prevent the animations to dirve the feet through the floor.

I'm still not anywhere near an answer to my original question: how much hover height compensation do we need on mesh surfaces. But I feel I've made some progress. Unfortunately it seems the issue is far more complex than I thought and I'm beginning to get a feelign the only solutions are either to accept the annoying hovering effect or spend lots of time on the beta grid with trial and error tests before each and every upload.

Right now I'm glad I advertise my builds as having phsyics "as perfect as SL allows" rather than just "perfect". I wouldn't like to be accused of false advertising. :matte-motes-wink:

 

The mesh model I used for this test was made in Blender - just a simple cube resized and duplicated. Physics models are identical to the visual model.

Tests were done in Mesh Sandbox 3 on the beta grid and the viewer I used to upload was Sl Viewer 3.8.0299338 for Windows 8.1

 

[Drongle McMahon]

"Contrary to Drongle's observations, increasing the z dimension of the mesh did not increase the gap..."

Not contrary at all - you must have missed the minus sign in my equation (or did I miss it?*). Whoops. I put "+" where I meant to put "-". The hull used by the default convex hull of a box is smaller than the bonding box, by a constant proportion. So as the dimension increases, you sink further into the mesh, exactly as your pictures show. The gap gets smaller and then goes negative as you sink in. When physics shape type is Prim, whether the shape is analyzed or not,  the gap should stay constant.

I think the effect you see when you see with the un-alalyzed shape, where you are left standing as it it were not there, is something to do with the major difference between un-analyzed (triangle-based) and analyzed (hull-based). collision is detected anywhere inside a hull-based shape (including default convex hull). So if you find yourself inside or spanning such a shape, you will be gradually pushed out. Collisions don't seem to be detected if you span across a triangle based shape. I guess you are sort of colliding in both directions and that cancels out. So you are left standing there. If you find yourself inside a triangle-based box. you can't get out except by sitting on something outside, because you collide with the triangles from the inside just as you would from the outside. A similar hull-based box will push you out.

There's another rather interesting property of triangle based shapes with certain contructions, that makes them easily penetrable from one side but not from the other. You can make one-way doors and other interesting objects using this principle. I don't recommend using it though, as it is surely a bug that might get fixed.

ETA: *Yes I did - sorry!! Corrected now :smileyembarrassed: I did say "retracted though, which is correct.

ETA: I reported the default hull contraction as a bug in the jira years ago, but nothing ever happened.

[ChinRey]

---

Drongle McMahon wrote:

Whoops. I put "+" where I meant to put "-"

---

Ah, that explains it!

 

---

Drongle McMahon wrote:

The hull used by the default convex hull of a box is smaller than the bonding box, by a constant proportion. So as the dimension increases, you sink further into the mesh, exactly as your pictures show.

---

Hmmm, that means It's not safe to resize convex hull meshes made with analyzed physics. Yet another thing they completely forgot to tell us!

---

Drongle McMahon wrote:

There's another rather interesting property of triangle based shapes with certain contructions, that makes them easily penetrable from one side but not from the other.

---

Yes. Which side is solid depends on the direction of the normal of course, so what happens if we use smooth normals for the physics shape? I never had the courage to check that.

---

Drongle McMahon wrote:

You can make one-way doors and other interesting objects using this principle. I don't recommend using it though, as it is surely a bug that might get fixed.

---

It might be a bug. But even so, omn a scale from 0 to 0, what are the chances it'll ever be fixed?

I don't actually know of a single mesh related b... oh, never mind. I'll start a separate thread about that.

[anselm Hexicola]

You may wish to look at what Drongle told us in a thread I raised a while back.

[ChinRey]

Thank you, Anselm. Yes, that thread was realy interesting reading! :matte-motes-smile:

[Drongle McMahon]

Yes, thanks. I had fprgotten that one already! Could have saved myself some time!

[Drongle McMahon]

Drongle McMahon wrote:

The hull used by the default convex hull of a box is smaller than the bonding box, by a constant proportion. So as the dimension increases, you sink further into the mesh, exactly as your pictures show.

---

Hmmm, that means It's not safe to resize convex hull meshes made with analyzed physics. Yet another thing they completely forgot to tell us!

Oh deare. I should be clearer ... by "default convex hull", I mean the one that gets used when you set the physics shape type to Convex Hull. That always gets made, whether you specify a physics shape or not, and whether you analyze it or not. If you don't specify one, it gets made from the convex hull of vthe low LOD mesh (which can often be inappropriate). If you do specify a mesh, a LOD mesh or one from a file, then it is the convex hull of that mesh, not broken up into components like the analyzed shape itself. So it's only when using the Convex Hull physics shape type that you need to worry about this. Analysed shapes set to physics shape type Prim should be ok, with constant offset.