Physics behaviors

I'm still experimenting with physics. To prevent my mistakes from sending objects flying away, I have enclosed 3 physical prims inside a non-physical (transparent) box. Most of the time this keeps them contained while I tinker. But once in a while a prim will escape through the walls of the box and fly away.

So I think I need to know more about how physics work in SL. What determines whether a physical object can go through a wall? How come they usually don't, except when they do?

I tried setting the box itself to physical, but it floats around or tips over, so that's no good. The prims inside are not linked to anything, they are all individual root prims.

Lag?

i kind of get what you mean, set a timer to have it go back to a pos every 2 minutes or something with llSetPos()

That is a bug... I don't know how it behaves in Havok4.

Same in Havok 4. Or if not the same, at least the same KIND of issue. High velocities can fool the physics engine. This has become as much a feature as a bug, I think, since there are products like OmniPhase and TeleDash out there that let you "teleport" short distances through walls and such.

For some reason the physics engine only detects collisions if they are actually intersecting AT THE TIME the check is made. No attempt is made to compute the intersection of flight paths, even though this shouldn't significantly increase the runtime complexity (it DOES increase the LOGICAL complexity, but by the forth+ generation of a physics engine you'd think someone would add the logic...). Maybe LL re-introduced it as a feature for the reasons stated above. I don't know.

Anyway, the answer is that sometimes (not ALL the time) if an object's velocity is large enough, and the thickess of the objects that should collide thin enough, they'll pass right through each other.

and note dropping lots of little physics objects into a physical container is grinding on the physics engine, and will most likely slow a sim to a crawl.

Thanks for all the info. I do have a script set to return any object that escapes, but I was hoping to avoid it entirely. I have 3 prims in a container right now so I can watch their interactions as I experiment. I haven't noticed any particular sim lag, but I tend to run the scripts only for brief periods. Then I stop them and adjust the scripts some more. The prims are small (about 0.1m) and the container is a tube 0.5m wide/deep and 2m tall. The prims are solid, the tube is 95% hollow with a transparent texture, linked to a solid top and bottom.

Today I did notice that if the objects are bobbing softly (buoyancy is set) they stay put, but if I apply any type of impulse or spin they are apt to escape. It sounds like there is no good way around it, which I'm sorry to hear.

One other thing I don't understand. When I stop the scripts (I have a touch toggle to start/stop everything,) I set buoyancy to zero and the prims fall back down into a pile at the bottom, but they don't touch each other. There is always a substantial gap between them, and another gap between the bottom-most prim in the pile and the floor of the conainer. My prims are basic shapes (cube, sphere, and prism) without any twist or taper, so their bounding boxes should be the same as their shapes. Why don't they touch when they settle to the bottom?

Make the container thicker. Bigger and/or less hollow. That should help some.

To simplify some things already stated, and example is a ty pical bullet. Depending on the "velocity" of it, you will only hit targets at certain distance intervals because the bullet is literall "skpping" through space at however many meters per advance the scripter is making it.

So basically, if it is moving / projecting at 5m hops, someone 3m away from you will possibly not get a collision.... and therefore, anyone standing in between the 'gaps'.

I've been working on weapons a LOT lately for the arena and requests, I've found this to be true of any projectile.

Take care,
- Hap

Wider and less hollow really helps! I reduced the hollow percentage from 95 to 85 and made the tube .125m wider. Just that little bit did the trick, I haven't had anything escape since -- though I haven't really applied any significant velocity yet either. Still, the concept is great to know. Thanks!

hint: forget about it.

I have seen prims being pushed trough 3 meter thick solid walls, not by speed, but by other prims gravity on top of them.

its fast, not accurate!

This problem is due to the simulator framerate, and that the framerate can vary wildly for just one or two frames, which causes your objects to "escape".

Physics cannot be calculated continuously, and instead it is processed as "instances" with each frame. Between instances, objects will continue to move but object collisions are not processed between instances.

If there is a brief lag spike the object could move a lot further than normal before it is processed for collisions again. If it is moving very fast, it can travel several METERS further during a lag spike than under normal conditions, causing it to miss a large object in its path completely.


There is a way around this so that fast objects would not be able to hop over barriers. The problem is that it is mathematically intensive and would make the engine slower.

1. You keep track of the object's position from the last calculated frame
2. You find the location of the object in the current frame
3. You create a temporary fake stretched-out 3D mesh that connects the vertexes of the object's previous position with the current position. This temporary mesh spans the gap between frames and will collide with anything the object may have skipped past.
4. If a collision was skipped over, the object's position and force vectors are now fudged back to where it really should have been, if it had properly collided with the barrier.

For maximum collision-detection precision, this gap-spanning mesh must be recreated anew for every calculated frame, and would significantly slow down the engine. The gap-span collision mesh is a custom shape made for just that one frame, and is then discarded. The data cannot be reused.

-Scalar Tardis / Dale Mahalko

If you make a gun that shoots very small and fast bullets, the bullets can potentially hop over and miss the target. To make sure the bullet hits, you must stretch out the bullet into a very long shape so that it is long enough to span the gap between calculated physics frames.

This is done by making a small bullet that looks like the shape you want, and then attaching a long small-diameter invisible cylinder behind it that could be several meters long. If the bullet hops over the target, the cylinder will collide and that will make the bullet behave correctly, even during lag spikes. As such your bullet becomes an arrowhead with a long invisible shank behind it.

The cylinder acts almost identical to the temporary mesh calculated between frames as I mentioned above, except it is a permanent part of the object, it increases the mass of the bullet to beyond what it normally should be, and will make the bullet act weird when it falls to the ground since the invisible shaft is always attached. This hackery is not possible with more realistic physical shapes and objects, and seems to be specific to weaponry.

(I intend to wikify this information eventually.)

- Scalar Tardis / Dale Mahalko

If you want to make something like a bullet, I'd recommend making it indeed something like a long cylinder or box, and have the width be a little greater than it seems by means of a linked invisible prim, as well as longer.

It seems to make sense that if your object is moving at 100 meters per second, and the sim under normal conditions is processing at 45 frames per second (let's make it 40 to account for lag), then the object is moving:

(100m / 1s) * (1s / 40 frames) = 2.5 meters per frame.

This seems to imply that if the length of the axis the object is moving along is less than 2.5 meters, there is a large possibility that it could pass through objects in its path, since it isn't occupying the whole space of the area it is in during each frame. This isn't exactly scientific, but it seems to make sense to me. This would also imply that if lag causes the physics framerate to decrease, then the object would move a larger distance per frame, increasing its chances for clipping through instead of colliding.

So in general, assuming your target sim(s) perform normally, I'd make my collision boxes have a length of (velocity / <40 to 44> to ensure a good collision, but I'd also keep the velocity below a certain point as well.

Hopefully that general guideline will tend to work out.