Jump to content

convex mesh object vs thin prim collision


animats
 Share

You are about to reply to a thread that has been inactive for 1199 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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.

capsule.thumb.png.f0b237318735a83211fd98cafd0292f1.png

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.

tubeinworld.jpg.1b4feb11e7216657e05370086b03a05c.jpg

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?

Link to comment
Share on other sites

collidefail1.png.3c4e4b3aa7eecb7f2a2b696d5ac06302.png

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.

collidefail2.png.acd03fe077f8d5901ec1cf4c272ba947.png

Then, stuck - avatar on top, bike underneath.

It doesn't recover. It gets worse.

This has to be a known problem. Any comments?

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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. rampslowapproach_001.thumb.jpg.6f0166e9ee35291a2f0452153e308685.jpg

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.

 

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

heterocerabridge_001.thumb.jpg.1e7b7cb31fc74d3cc9fdd64fda6da444.jpg

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.

Chappaquiddick-kennedy-car-bridge.jpg.541ecc5fb586c87a946b7c4888c019eb.jpg

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.

 

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 by Fionalein
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1199 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...