convex mesh object vs thin prim collision

[animats]

I'm working on a motorcycle design in SL, and want to create a better base "sled" for it. So I made a "capsule" shape in Blender.

Simple capsule shape, faces minimized in Blender.

I imported this with full detail and no "simplification", since simplification tends to mess up the geometry and make it asymmetrical. This wraps around the bike, and has to slide well over hills and small obstacles. It has to be symmetrical or the bike will not go straight.

In world

Here it is in world. As a test, I made it "physical" - it falls over properly and can be pushed around, and will support a physical cube placed on top of it. It's set for convex hull collisions, and since it's a convex object, it should be one perfect convex hull.

So I made it part of a bike. That mostly works, except for thin road surfaces at steep angles. It falls through those. It consistently falls through the long wooden bridge at the south end of Hetrocera's bay. It falls through a place on Robin Loop where the road takes a sharp upward pitch. Bike and rider get stuck in the road prim. All this is nowhere near a region crossing; separate problem from that.

This is unexpected. Ordinary prims don't fall through. Mesh wheels don't fall through. An ellipsoid prim of roughly the same dimensions doesn't fall through. Am I doing something wrong here? Known bug?

[animats]

Here's the bike, supported by that mesh object, shown translucent in blue, trying to cross a bridge like the one in Heterocera.

Collision detection seems to fail here. The simple convex shape goes right through that thin prim.

Except for this special case, that bike works quite well, and rides nicely on that blue convex mesh object. Rough roads and curbs work fine.

Then, stuck - avatar on top, bike underneath.

It doesn't recover. It gets worse.

This has to be a known problem. Any comments?

 

[animats]

So we've spent two hours trying various bikes against that 30 degree ramp. Some fall through, some can climb the ramp.

• One old super bike does well, even at high speed. Don't know why. The front wheel does go into the ramp momentarily, but then comes out.
• Huge lag in the sandbox today, but the lag meter and statistics all look good.
• Big sled prims don't help much. Even a simple rectangular prim can fall through that ramp.
• Making the ramp thicker, 1 meter, doesn't help.
• Making the ramp from short sections doesn't help.

I've seen a "sled" form which is a row of cylinders. I think the idea there may be that if the collision detection system misses one collision, one of the other collisions will be detected and will get things back on track.

Something else in SL to have to work around.

 

[Callum Meriman]

Can you turn on Show Physics - not the new Beq single-object version, but the old full scene version? (in a sandbox)

When you imported the mesh, you set the physics to file and used the same dae, or just used high?

Have you tried it as Prim and not Convex?

[animats]

I've tried old show physics in the LL viewer in a sandbox. It's not too helpful.

Tried Prim mode for the big mesh object. Didn't help.

The big mesh object works fine at very slow speed.

At slower than walking speed, the collisions work right.

The translucent blue object is the sled mesh. Only it and the frame (which is the root) are collidable in this test. So here, it's supporting the bike, like it should. Both are set to convex hull. At walking speed, the blue object goes through the ramp.

The slope determines what happens. Above 18 degrees, fails, even at slow speeds. Below 18 degrees, succeeds, even at high speeds.

The vehicle system prevents the vehicle from rotating rapidly in pitch. The collision system is trying to rotate it. That ought to result in going up the hill in a horizontal attitude, and for some vehicles, it does. But here, the vehicle goes into the hill. But turning down angular friction or linear deflection in the vehicle params has no effect. That doesn't seem to be it.

I have a bike from Marketplace which can take this hill at very high speeds. It's non mesh. No sled prim. Torus tires, cylinder wheels, sculpted body.

Replying to Callum: tried changing big prim physics type to Prim from Convex Hull. Didn't help.

Show Physics (in LL viewer, of course; it's meaningless for mesh in Firestorm) shows the big sled mesh object looking like the big sled mesh object. That object, all by itself, seems to have proper physics properties.

 

 

[ChinRey]

I'm not sure if it has anything to do with this but there is an old JIRA about vehicles failing to track the surface if their physics weight is too low(!)

I can't remember the details and I can't find it now. Maybe @Whirly Fizzle can? She knows all JIRAs by heart.

[Whirly Fizzle]

Sounds like this bug?

BUG-7119 - Certain vehicle shapes, hitting a concave ramp at high speed, penetrate the ramp more than expected

[animats]

Thanks very much. That explains a lot. The bike that isn't working is a modern 17 LI all mesh design. The bike that is working is an old prim and sculpt design with a LI over 30.

Guess we have to add some dead weight.

[ChinRey]

10 hours ago, ChinRey said:

Maybe @Whirly Fizzle can? She knows all JIRAs by heart.

 

10 hours ago, Whirly Fizzle said:

Sounds like this bug?

Q.E.D.

 

9 hours ago, animats said:

Guess we have to add some dead weight.

Dead weight is the right word unfortunately but yes.

[animats]

Too little physics weight really does break the collision system. I made every object in the bike a convex hull. Land impact went from 17 to 18. The bike no longer falls through the ramp. It sometimes gets "caught" by a nonexistent obstacle on steep ramps, though, just like the prim/sculptie bike.

There seems to be a critical angle for this bug. Rachel Stardust tried making ramps with different slopes. Over 18 degrees at the break, fail. Under 18 degrees, success.

Here's the troublesome Heterocera bridge.

20 degrees at the break. Way too much.

That bridge seems to be modeled after the famous bridge at Chappaquiddick, which has been in the news lately.

A bad bridge design that changed history. Not as steep as the bridge in SL.

Very few main roads in RL or SL have a break this sharp. There's a steep spot at one end of the Heterocera bridge, and a steep spot on Robin Loop. Those are the only really bad spots I have found, and that's with over 500km of SL driving. What we need here is some mole work on a few trouble spots.

The steepest street in San Francisco is 17.5 degrees, and the approach isn't a hard break like SL. Given this unfixed physics bug, SL should keep worst case road slopes down to 15 degrees. That's huge by real world standards. 10 degrees is the normal limit for mountain roads. 20 degrees is unrealistic and things break.

 

 

 

[animats]

Filed a support request to fix the two places in Heterocera where main roads trigger this problem. Only a few spots trigger this, and you don't expect it, since it's an obscure bug.

Part of our ongoing effort to make SL great for long distance driving.

[Fionalein]

Couldn't you just hide two dark grey physical torus prims in the tires? Would also solve any "bike looses tires at zooming out" problems...

[animats]

10 hours ago, Fionalein said:

Couldn't you just hide two dark grey physical torus prims in the tires? Would also solve any "bike looses tires at zooming out" problems...

It doesn't seem to matter where the physics weight comes from. It just needs more of it. Bug known for years, apparently.

Visible level of detail for mesh objects is a separate problem, much discussed in the mesh forum.

[Beq Janus]

On 17/04/2018 at 6:04 AM, animats said:

Show Physics (in LL viewer, of course; it's meaningless for mesh in Firestorm) shows the big sled mesh object looking like the big sled mesh object. That object, all by itself, seems to have proper physics properties.

2

Why would it be meaningless in Firestorm? Unless you are using an outdated version of the viewer there should be no limitations to what you can see.

[animats]

6 hours ago, Beq Janus said:

Why would it be meaningless in Firestorm? Unless you are using an outdated version of the viewer there should be no limitations to what you can see.

Because physics convex hulls are recomputed in the viewer for display, not sent from the server. The convex hull generation is done in the LL viewer with a copy of the Havok code used server side.  Firestorm does not have that code, because they don't have a Havok license. You get a message about this every time you upload a mesh object from Firestorm.

[Whirly Fizzle]

16 minutes ago, animats said:

Because physics convex hulls are recomputed in the viewer for display, not sent from the server. The convex hull generation is done in the LL viewer with a copy of the Havok code used server side.  Firestorm does not have that code, because they don't have a Havok license. You get a message about this every time you upload a mesh object from Firestorm.

Firestorm has a Havok sublicense from Linden Lab - http://wiki.secondlife.com/wiki/Linden_Lab_Official:Havok_Viewer_Sublicense

You need to be running a Havok enabled build of Firestorm, not the OpenSim version.

[animats]

Oh, I'll have to try an upload with a non self compiled Firestorm.

[Fionalein]

1 minute ago, animats said:

Oh, I'll have to try an upload with a non self compiled Firestorm.

only if you have a Windows version... Linux one doesn't have havoc... maybe time for Wine

 

Edited April 19, 2018 by Fionalein