Triangle list physics is driving me up the wall... literally

[Rick Nightingale]

I've been unable to find any mention of this phenomenon anywhere, which surprises me, so I'm mentioning it and asking for comments 😀

I much prefer to make my physics models from triangles, instead of using the non-touching cube method. If I make a vertical wall though, say for a house, it will work perfectly in every regard except that I can walk up the wall.

It seems that I'm walking up the edges of the vertical triangles defining the wall's (flat, vertical) physics. I have to lean slightly into the wall as I walk along it to do this, but it happens everywhere there's a triangle edge near me and I end up walking diagonally up the wall as if there's a hidden ramp. I've even been able to climb all the way to the top of a 10m vertical wall like this and stand on the roof.

If I analyze the mesh into hulls this doesn't happen of course, but then the attached roof or floor has the floaty-walk issue.

Is there anything I'm doing wrong here, or is that expected behavour from vertical triangle physics?

 

[ChinRey]

38 minutes ago, Rick Daylight said:

If I make a vertical wall though, say for a house, it will work perfectly in every regard except that I can walk up the wall.

Yes, that can be a bit annoying. One solution is to shift the lower edges of the physics a li'l bit inwards, something like in this quick mockup (gray surfaces are the visual wall, red the physics:

Edit:

On second thought, usually it's better to tilt the top of the physics outwards from the visual, as long as it doesn't extend outside the mesh' bounding box of course:

Both illustrations are rather exaggerated btw. You only need to tilt the physics planes very slightly towards the direction the avatar comes from.

Edited November 27, 2021 by ChinRey

[Rick Nightingale]

Ahh... that would work perfectly on the part I was doing just before I posted. It has an overhanging edge anyway; I nearly did incline the physics there to save a few triangles. I'll give it a go after I've finished the current part. Thank you

[animats]

The physics engine works best if it has convex hulls to work on. (A convex hull is a polyhedron with no "dents". Like shrink-wrap.) The physics engine will try to deal with what's called a "polygon soup" of random triangles if that's what you give it, but convex hulls collide better because they have a clear inside and outside. This prevents some situations which can get you stuck in a wall.

Confusing the issue is that SL has several convex hull options. The one in prim properties puts a convex hull around the entire object. That's the big hammer of SL physics - don't get inside this thing at all. It's good for rocks and such, things you never get inside of, even partially. Simple and efficient.

But you can also create convex hulls in the mesh uploader. Beq Janus made the upload window resizable in Firestorm, so you can make it big enough to see what's going on.

There's a thing in the uploader called the convex hull decomposer. It's from Havok. It will try to break an arbitrary object into a set of convex hulls which roughly add up to the original object. Unfortunately, it's not too smart. If you put in "wall with door opening", you ought to get two pieces of wall and a door lintel. But you'll probably get a bunch of wedge-shaped pieces that add up to your original shape. This is the reason for putting small spaces in the physics model; it's to prevent the clueless convex hull decomposer from generating a badly chosen set of hulls. It won't join pieces across a gap.

The various parameters for analyzing and optimizing the physics model are useful if used with a big upload window. Then you can see the choices being made. The window updates as you move the sliders. Try to get rectangular solids, rather than wedges, and the physics model will work better. Two back to back wedges tend to result in flaky behavior like being stuck between them.

Triangle meshes used as collision objects have some gotchas.The physics engine has no idea what "inside" means for a random piece of mesh. So it's possible to get stuck inside an object. Non-watertight triangle meshes used as physics objects may behave strangely, since they are ambiguous about what's inside. Clean your meshes before uploading.

(llCastRay uses the physics engine, and my NPCs use llCastRay. Sometimes my NPCs will walk right through something, because its physics model has big gaps. When they do, an avatar can walk through the same place. I've seen too many vehicles like that. Too often you can walk through the hood area.)

[ChinRey]

55 minutes ago, animats said:

The physics engine works best if it has convex hulls to work on. (A convex hull is a polyhedron with no "dents". Like shrink-wrap.) The physics engine will try to deal with what's called a "polygon soup" of random triangles if that's what you give it, but convex hulls collide better because they have a clear inside and outside. This prevents some situations which can get you stuck in a wall.

Unfortunately there is one problem: two hulls are not allowed to touch each other, there will always be a small gap between them. This means that if you use a hull for the floor, the avatar will always hover a little bit above it.

Both hulls and trignale lists (which is what Havok calls triangle soups) have their pros and cons and I know you're a physics engine expert, animats, so I should be a bit careful disagreeing with you. But Havok is a bit weird and I've found that it's actually very rare that multiple (that is more than two or three) hulls is a better solution than a triangle list for a mesh. The physics weight calculation confirms this and unlike the other weight algorithms it does seem to be a fairly good estimate of the actual load. If I remember right, @Beq Janus did some tests a while ago that also showed that triangle lists are far more appropriate for Havok than what we usually expect from other physics engines.

[animats]

6 minutes ago, ChinRey said:

Unfortunately there is one problem: two hulls are not allowed to touch each other, there will always be a small gap between them. This means that if you use a hull for the floor, the avatar will always hover a little bit above it.

Both hulls and trignale lists (which is what Havok calls triangle soups) have their pros and cons and I know you're a physics engine expert, animats, so I should be a bit careful disagreeing with you. But Havok is a bit weird and I've found that it's actually very rare that multiple (that is more than two or three) hulls is a better solution than a triangle list for a mesh. The physics weight calculation confirms this and unlike the other weight algorithms it does seem to be a fairly good estimate of the actual load. If I remember right, @Beq Janus did some tests a while ago that also showed that triangle lists are far more appropriate for Havok than what we usually expect from other physics engines.

That's worth knowing. Convex hull collisions are cheap to compute, but that's a server-side cost, and in SL, we tend not to have big piles of colliding objects anyway.

And, right, the Havok system doesn't allow hulls to touch. However, you can't get two basic mesh cubes in prim mode to stack without a gap. Works with prims only. I suspect that the collision model for prims was manually tweaked to get that right.

The big advantage of hulls is that, since they're actual volumes, the collision detection works better. You don't get those "stuck under the landscape object" problems. You'll be kicked out of a convex hull. And you don't get those weird situations that result from hitting a collision surface edge-on.

Because I do SL vehicles, I'm very aware of those kinds of problems.

[Beq Janus]

6 hours ago, ChinRey said:

If I remember right, @Beq Janus did some tests a while ago that also showed that triangle lists are far more appropriate for Havok than what we usually expect from other physics engines.

I don't actually recall this, though I might well have done and totally forgotten 🙂

In general triangles are less preferable than hulls, esp. for things like walls as the avoid both 0.5m limit on thin walls and the "inside" problem. 

19 hours ago, Rick Daylight said:

It seems that I'm walking up the edges of the vertical triangles defining the wall's (flat, vertical) physics. I have to lean slightly into the wall as I walk along it to do this, but it happens everywhere there's a triangle edge near me and I end up walking diagonally up the wall as if there's a hidden ramp. I've even been able to climb all the way to the top of a 10m vertical wall like this and stand on the roof.

I think you've described exactly what is happening, as the physics engine has only a pair 2 dimensional planar triangle there is every chance that in the vagaries of server-side physics accuracy you end up balancing along the edge of one triangle. I quite like the "leaning out" solution for those cases where we insist on/have no choice but using planes.

5 hours ago, animats said:

And, right, the Havok system doesn't allow hulls to touch. However, you can't get two basic mesh cubes in prim mode to stack without a gap. Works with prims only. I suspect that the collision model for prims was manually tweaked to get that right.

tweaked I am sure. the physics is slightly smaller than the visual prim I think.

 

[ChinRey]

1 hour ago, Beq Janus said:

In general triangles are less preferable than hulls, esp. for things like walls as the avoid both 0.5m limit on thin walls and the "inside" problem.

A wall is one of the objects I would use hull physics for but unfortunately we can't combine hulls and trianges in the same mesh and hulls don't work well for floor.

And I don't think the hulls is better than surfaces rule is quite as true for Havok as it is for other physics engines. There are a couple of anomalies in the way physics weight is calculated and the way physics is treated in SL that seem to indicate Havok has done some "clever" tricks that shift the balance to be a little bit more favourable to triangle lists under many circumstances. (I'm talking about free form hulls here btw. The four standard predefined volumes would certainly have been the best options when applicable but those aren't available for meshes in SL of course.)

 

1 hour ago, Beq Janus said:

tweaked I am sure. the physics is slightly smaller than the visual prim I think.

It is indeed. I'm fairly sure hull physics are shrunk for meshes too but unlike for prims, LL didn't get it quite right.  I don't know whether this is because mesh was introduced at a later stage when development quality was lower or because it's harder to do with fee form polylist meshes than with procedural objects. It might be a combination of both.

[animats]

5 hours ago, ChinRey said:

It's harder to do with fee form polylist meshes than with procedural objects.

Shrinking a mesh to fit inside another mesh at a specified distance is a reasonably hard problem. I had to code that once. You can't just downscale the mesh. For complex objects a downscaled mesh will have some surfaces in the wrong places. Moving each face inward results in the geometry changing. Some triangles, edges, and vertices can disappear. You have to figure out what to do about parts of the mesh thinner than twice the shrink distance, since having them disappear and have no physics model is no good.  There's no perfect solution to that.

So, that's probably why they didn't do it.

[Rick Nightingale]

Interesting discussion, thanks folks. I tested like crazy in Aditi and I think it's turned out OK. Almost everything is traingle physics, with just a few bits that worked out better (from my point of view) to use hulls for. I tried really hard to break through walls etc. without success, lol. There are a few places left that, if I try hard, I can caatch a triangle edge and walk up a little, even with a lean-in, but I've hidden those in corners no normal person should be mucking about in.

I designed my house as external and internal 'shells', rather than by making walls as such, so using hulls would have been much more troublesome to design after the fact. Anyway, it all works well, even my spiral staircases.

Now I'm playing with assorted texture ideas... something I'm even less good at. Plus there's still some small mesh details to add (like roofing fascias) which I'm doing as I feel like.

Everything you see except the unicorn and the bench seat is mine: