Moving through solid walls at high speed

[Imagin Illyar]

I've recently discovered the joy of motorcycles in SL :)  I have a great track that has solid transparent walls to keep you from going off the sides.  It works great at low speeds but I've noticed that when you go fast eneough you can go right through them and then actually get your bike trapped by them.  To test I set up some ordinary solid walls on an empty building platform and tried thick, thin, doubled and even trippled solid walls - at high eneough speeds I can go right through them.

Is this some kind of limitation of SL?  Anyone know of a work-around for this problem?  

[LepreKhaun]

Though it is a limitation of SL, Leonardo da Vinci had the workaround: Remember: acquire accuracy before speed.

[Drongle McMahon]

Yes. It is a limitation of the collision detection in the physics engine. I guess collision tests are made at discrete time steps and with limited looking ahead (if any). So if you sre going fast enough, you can pass through a surface before the collision is detected. Once that has happened, there is a big difference between triangle-based and convex hull based shapes - you can get stuck inside a closed triangle-based shape, as colliding with the inside is not that much different from colliding with the outside. However, if the engine finds you inside a convex hull, it will nudge you out again. Thus convex hull based shapes may be more suitable for your application. If they aren't too thick, it is still possible to go the whole way through, but less likely, and you won't get stuck.I would guess thicker walls would be better, more likely to be pushed out the right way, but I haven't tested that.

There may be scripting solutions to this problem for scripted vehicles. Perhaps a question in the scipting forum would be more likely to find out about that?

One other strange thing - it is easier to penetrate a triangle based shape if you collide with it's back surface (the one without the normal sticking out = the one that isn't textured). This makes no sense to me, but it is very clear if you do the appropriate experiments.

[Imagin Illyar]

Clearly the old sage never owned a crotch rocket

[Imagin Illyar]

I set up a test area on a 1/2 sim building platform with one thick wall set to convex hull and the other just a normal prim of the same size/shape.  They had about the same results.  Sometimes I go through, sometimes I don't.  I do thank you for the explanation though, hopefully some day collision detection will be a bit faster in SL.  In the meantime, I'll just have to get better at staying on the dang track

[LepreKhaun]

---

Imagin Illyar wrote:

Clearly the old sage never owned a crotch rocket

---

hmmm, maybe, maybe not...

[Imagin Illyar]

Well played sir

[Rolig Loon]

This is a recurring problem for people who write scripts for things like archery targets.  If you're not very careful (or lucky) an arrow can go through the target without being detected ot stopped.  I have tried several solutions.  Sadly, the best one seems to be to slow the arrows down so that they don't pass through the target in less than 1/45 of a second (the frame time in SL), and then quickly changing the arrows from physical to non-physical as soon as they detect a collision. 

[Kwakkelde Kwak]

I did some track work for someone, I didn't test the invisible walls myself, but was told my setup of 7 meter thick convex hulls worked perfectly. I set it that big so cars can't get stuck, even on a convex wall cars can get stuck if one part is on one side and another part on the other, or it's pushed through the ground or into the air very slowly.

Make sure you don't use connected blocks for corners, you will be able to slip in between. I used a double object, with intersecting blocks.

[Imagin Illyar]

Thanks for that info!  I did not try convex hull walls t hat thick but I will.  When you say not to use connected blocks on corners do you mean linked?  Did you use unlinked blocks that cross through each other?  Is the linking the problem?

[Kwakkelde Kwak]

If you want to use hulls (analyzed physics when uploaded) for a corner, you'll have to split the physical shape into several non intersecting blocks, as shown in the blue object. The problem then is, any vehicle can go through the gaps, no matter how small you make them. So what I did was splitting the object into two seperate ones, the white and the red. Because of the overlap, there are no gaps.

You could do the same with prim boxes, which I think would result in a lower physics weight. The downside would be a much higher download and server weight.

[Drongle McMahon]

"You could do the same with prim boxes"

That raises a question. How does the collision behavior of prim boxes compare with either kind of mesh shape? At first.I might expect it to be like triangle-based mesh shapes, because that's the type of shape used by most lagacy prims. Has anyone tested penetration of these? But then I remember that, provided they are only stretched and rotated, with no other distortion, prim boxes use the havok primitive box physics shape (hence the very low physics weights). Can you penetrate those? And what happens if you do? Do you get stuck inside?

[Kwakkelde Kwak]

---

Drongle McMahon wrote:

But then I remember that, provided they are only stretched and rotated, with no other distortion, prim boxes use the havok primitive box physics shape (hence the very low physics weights). Can you penetrate those? And what happens if you do? Do you get stuck inside?

---

You just answered your own question, then asked it again..or something like that.

Prim spheres, cylinders and boxes act like convex hulls. (Or really as physical spheres, cylinders and boxes) A physical box is an element just like a single hull or triangle is. From what I understand, you can't ever get stuck in an element.

A box can be scaled in all directions independently or as a whole, a cylinder can be scaled in height or as a whole, a sphere can be scaled as a whole. Any other alterations will make the physics shape triangular based, with the risk of getting stuck in them.

[Imagin Illyar]

Ok, I understand about the overlapping blocks on the corners.  Thanks very much for taking the time to make the diagram.  Is there a difference between prims or mesh for the hull blocks?  

[Kwakkelde Kwak]

As I said earlier, built with mesh the download weight (and graphical load) will be lower, since you can use as little as two triangles for the visible objects. Five prim boxes use 540 triangles, at least on the highest LoD. The server weight will also be lower, since you only need two individual objects. If you use prims you will need five for the same shape and even more if you want a smoother physical shape.

Drongle (or someone else) might know if the SL uploader will recognise the mesh blocks as boxes or as arbitrary hulls. If SL recognises the boxes there shouldn't be any differences in physics weight between mesh and prims. If it doesn't, prims will have a lower physics weight (and therefor lower physics load on the servers).

[Drongle McMahon]

Unfortunately, the uploader deosn't recognise parts of the physics shapes that could be Havok primitives. So each simple box, converted to a hull with "Analyze" has a physics weight of 0.36, while each legacy prim box has a physics weight of only 0.1 because it is recognised. Cylinders are more.

[Drongle McMahon]

"Prim spheres, cylinders and boxes act like convex hulls."

Hmm. A pity. I was hoping they might be even more resistant to penetration in the first place.

[LepreKhaun]

When factoring in speed, penetration is unavoidable. Moving at just 50m/s, the object's position is being updated in jumps of over a meter. I think the question is more of how the penetration is handled when it's sensed.

[Imagin Illyar]

I think you're right, LepreKhaun.  On my test platform I'm able to go through prims set to convex hull that are 10m thick.  I suspect you are correct that it's unavoidable.  I have noticed that errecting a mesh guard rail in addition to the prim convex hull walls keeps it to a minimum though.  

[LepreKhaun]

Well, looking at http://wiki.secondlife.com/wiki/Limits "Max. avatar speed - 250m/s (with only attachments to assist)" one could surmise:

At that velocity, the avatar's position would be updated in jumps of 5 1/2 meters. If it finds it's bounding box completely within a normal prim, it gets "stuck" within it. With a convex hull, it would be "pushed" in the direction determined by the centers of the objects; less than halfway, back to the side it entered, otherwise to the opposite side.

 

And that would make 10 meters nearly the optimal thickness.

[Imagin Illyar]

I tested 10m thick convex hull prims on my building platfrom.  Went right through them with about the same amount of frequency as I did thin walls and doubled walls.  I've had to conclude that it is just not possible to prevent this completely.  

[LepreKhaun]

I'd agree. Considering that the Havok engine is attempting to track the physical interactions of the land with up to 15 k prims and 100 avatars at forty five times a second, it does a surprisingly good job. A bit of inconsistency with handling the illusion of "solidness" when it comes to speed might be expected and Leonardo's work around is the only one.:matte-motes-big-grin-squint:

 

[Imagin Illyar]

Today I took on the tedious task of lining the entire track on both sides with the mesh guard rails.  I left the .5m thick convex hull walls in place.  After a good rub test I have to conclude that this has reduced the pass through quite significantly.  I was unable to go through at all at the speed I've been normally driving.  At ridiculous uncontrollable speed there was some pass through but not as much as with the walls alone.  I'm asuming that anyone who could actually control the bike at such an exteme speed would be beyond the richocheting off the walls stage  So indeed, the old sage was correct - first you get good, then you get fast.  

[Jer Straaf]

Why is everyone here dancing around the real issue? The real issue is MESH!

Prim vehicles do not get stuck in prim or sculptie walls, other vehicles, etc. Period.

Sculptie vehicles do not get stuck in prim or sculptie walls, other vehicles, etc. Period.

MESH vehicles will interpenetrate and get stuck inside, well, just about anything in SL.

In one of my games, I double-reinforced all of the side walls in my circuit so that there is a double-chance that it will detect the collision. However, there are many ramps and a player still has about a 1 in 10 chance of having their fun end with a MESH vehicle stuck in the floor. It was exasperating to make that game actually work in a reliable manner.

The flood of cheap MESH vehicles and other objects seemed at first like a windfall to game-builders like me. I turns out, however, that while they're pretty to be sure, they perform in a dynamic environment like fresh doggy doo doo. That's your problem, and nobody has a good solution except to avoid using MESH for anything other than tea sets and T-shirts, LOL.

So enjoy your MESH tea sets and T-shirts, because you sure as heck won't enjoy your MESH vehicles unless they are a parked, static prop. That's not the world I live in, I make Trains, Planes and Action Games. Poor MESH performance is a constant barrier to me, and obviously, to you, the OP.

[Kwakkelde Kwak]

---

Jer Straaf wrote:

Why is everyone here dancing around the real issue? The real issue is MESH!

 

Prim vehicles do not get stuck in prim or sculptie walls, other vehicles, etc. Period.

Sculptie vehicles do not get stuck in prim or sculptie walls, other vehicles, etc. Period.

MESH vehicles will interpenetrate and get stuck inside, well, just about anything in SL.

---

I had a go at a vehicle recently, earlier I did some tracks with collision walls for the corners. I haven't tested myself, but the person I made them for gave me the results.

My conclusion isn't the same as yours.

As far as I can tell, the problem is the physical shape of all objects involved. The physics engine recognises "elements". The problem with triangular based meshes (the ones you have when mesh items are not analysed on upload and are set to "prim", but also cut and hollowed and otherwise distorted prims set to physics type "prim") is every single triangle is treated as an element. So one element of the car can be on one side of a wall while the other is on the other. With the shear amount of elements it's not a surprise getting stuck is easy.

If you however analyse on upload, or set the physics type of your car to "hull", the physics engine works with (surprise) hulls. Every hull is an element and there will be fewer hulls than there would be triangles, hence less chance of getting stuck.

Short version, use hulls for you physical shape and chances of getting stuck will be pretty much gone.