Can multiple touches/collisions cause sim lag / memory issues?

Hi,

Any coding tips on handling multiple touches/collisions? Also can the multiple event triggering circumstance I mention below give rise to sim lag / memory issues?

I'm using the touch and collision event to trigger other code (e.g. registration of players), however I note when I bounce a ball (with physics - for testing purposes to emulate real players) up against my object to trigger it there are lots of collisions that are being registered (my object which it is hitting with the scripts does have muliple linked prims in it).

Any coding tips on how to handle this and make sure it doesn't give rise to lag (e.g. what if an object keeps triggering it)

Cheers

it depends on what you can & want to do. One solution is, if your object is simple enough to make the root prim an invisible box around your object, bigger then your object as a simple cube, or prism. This will simplify the bounding box of the object which in part will make the sim more stable and faster compaired to the more complex shapes. If you don't care about the collisions of the other prims you can use llPassCollisions to silence them.

I was thinking of also:
- keep track of touch/collision IDs when processing to ensure any one ID is not processed multiple times
- perhaps just only process the 0th item - so if there happen to be more than one touch/collision occur the user would just try again

You might want to check that you're using the collision_start() and not the collision() event. The latter fires continuously as long as the collision is happening.

arrr - thanks Argent - thats my problem then

In a general physics sense, yes, multiple collisions are exactly the source of sim lag.

My 300-sphere live-physics hourglass will significantly lag a sandbox, because for every frame the sim has to calculate the forces of each sphere touching one another.

In a maximal ball-pack arrangement, one sphere has the potential to push against 12 other spheres, which involves massive amounts of force-vectoring math between them all.

All this must be done every frame, even if the pile of spheres are all in a stable arrangement that will leave them motionless after all the math is done.


Though if you've ever seen a stack of 300 spheres in SL, they are NOT motionless. They have a small but clearly visible jitter and wobble, which is directly comparable to what we call Brownian Motion in real life. Every frame update will show the entire stack wobbling just a little.

The physics-silencer of the SL engine that stops physics processing on motionless objects does not work here, because the constant stack-jitter keeps overriding the physics-silencer and the stack will continue to lag the sim until:
- selected in editing mode (pauses physics on an object)
- deleted by owner
- separated far enough from other physics objects so they stop jittering and the silencer can stop calculating the physics on them


So imagine the speed and power of the physics engine required to run Real Life...

It's got a pretty high clock rate in our time, but we don't know how many Gods-World seconds it takes for each processor (entangled wave function) to calculate its interactions with other particles within the planck length and planck time.

However fast it is, the universe's basic instruction set seems quite simple. It may merely be no more than a large finite-state automaton, or n-dimensional turing machine.

With self-modifying code

aka, static.

Argent - actually did some more testing. Even with collision_start() and taking only the first item withinthe event, when you manually bang a physics objects up against the object with the collision_start() event you seem to get multiple collisions occuring

Guess this is not the best way to allow people to register...I'd betting use touch only I guess. I don't want to have to write throttling code to the collision_start event to cater for this