Lag Worst Offenders

Here's something I'd like to see: A comprehensive list of what types of objects or script functions cause the most lag on a sim. Avatars and physical objects would obviously be near the top, but what comes next? Which shapes cause trouble? What should you avoid using in a script to keep lag down?

I'm a lag bomb

I'd like to know this, too. I'd also like to see a way to see which objects in a sim are causing the most lag.

What types of objects cause the most lag?

Is Charlie Omega an object?

The Charlie object.

Oh I think this is a great idea btw... maybe a rating system like 1-3 for more or less lag. Just so the scripters can be more efficient without having to do trial and error.

Just from observation seems it's
1. av's. a lot of textures to send to everyone.
2. a lot of prims in a small area or in the view distance. tons of textures
3. physics
4. particles
5. audio spam
6. chat spam

Remember that there are probably four types of lag:

1) Local transmission lag - Delays only you see because your computer is still streaming data about objects/textures/sounds in your area. Other internet blockages can also cause this.

2) Graphical lag - A delay only you see because there is too much stuff on-screen for your computer and graphics card to handle.

3) Physics lag - The game server lags due to complex physical collision calculations.

4) Script lag - Scripts lagging the server because there are too many, or some are badly written and inefficient.


When it comes to physics, prims with more trishapes are harder for the physics engine to calculate collisions with. So the four basic shapes in order of collision evilness would be: torus, sphere, cylinder, cube. (Each of the others are just shortcuts.) Making any of them hollow increases their evilness. Cuts should actually help, since that removes some of the trishapes. Twists, while they shouldn't add any additional trishapes, can form concave surfaces which will also make them more evil, though not so much for speed as for accuracy.

In scripts, short durations on repeating functions like llSetTimerEvent and llSensorRepeat are bad. Make them as high as you can. I'm sure there are more things that are bad here, but those two may be the worst.

(These are mostly just educated guesses on my part...)

Here's what I've heard from Lindens. All the info below is from not just one Linden, but multiple Lindens, so unless software changes over time have rendered it null and void, it should be reliable. I always caution though that nothing is more reliable than current info direct from a Linden dev.

- Textures are basically not a problem. They load quickly. One thing that may seem to take longer is texture 'baking'. Textures for your av are all loaded to the server, and then 'baked' into 1 image which is what gets displayed. What we refer to as textures 'rezzing' is actually textures baking. The context for this conversation was avs, and I don't recall if this applies to all objects or just avs. Length of time for textures baking depends on your puter/graphics card.

- Torii are the worst and basically don't use them unless your life depends on them which should be like never. Next worst is rounded objects that are hollowed and/or cut. For example, a cylinder that is hollowed and then cut in half to make a curved wall. Next would be squared objects that are hollowed and/or cut, for example a wall made from a cube that is flattened and hollowed in the middle for a window. Andrew told a friend and I some time ago it's better to always use 4 cube objects than to use 1 cube object and hollow in the middle. Oh and twisting is another culprit. I would really like an update on this, with an updated order of precedence from worst to least 'offending'.

- Here's a copy of an email from a Linden. Because my post is getting lengthy (sorry) I've cut things that are not terribly important. I'm 99.99% sure it's okay to share this:

Objects without scripts don't add much load to the server, apart from the load needed to transmit it to clients. Objects with scripts add some load. Scripts that touch the physics system (move objects around) cause more load than ones that don't. Scripts that cause objects to collide with each other (like rezzing two objects overlapping each other) really kill the physics system.

The red and blue flashes (*from Candie - this is the Debug > Show Updates he's referring to*) indicate how much network traffic an object generates. Red is a "full update" and blue is a "terse update". Full updates are about 5 times as much data as a blue update. Thus continuous red worse than continuous blue worse than occasional blue.

Some scripts, however, must generate those kinds of updates. For instance, if you change the llSetText hovering text above an object, it will always generate a red update. Thus, if you do that continuously, it will cause a lot of network traffic.

There isn't a good way to measure script usage in a sim. The actual load by the scripts themselves isn't too bad (unless they poke physics). It's mostly calculating the updates and sending them to clients.

This will all get much better in 1.1. Doug and Cory have a new, much smarter system for computing and transmitting updates. It's significantly faster. Nonetheless, minimizing red updates where possible is helpful.

=========================

I hope this info helps.

Candie

Editing to say: Tiger, didn't see your post - I was writing mine at the same time apparently. Saw what you said about cuts - that does seem logical.

With cuts, the amount of data sent from server to client isn't significantly different. But cuts do affect 3D rendering (in a good way), which in turn affects physics since Havok uses the 3D data of the object to compute collisions.

By cutting away half of a torus, you add a few triangles to form the flat surface of the cut, but you remove a whole LOT of triangles that made up the missing section.

I couldn't find a good picture of this that showed the actual triangles, but here's a shot that shows rectangles. Just imagine each of those rectangles to be divided in two by a diagonal line, and you'll have what our clients are translating the parametric data the server sends to us into, and then handing to our graphics cards.

So you can see where our graphics cards will have to do less work with cut objects because they have fewer triangles.

The physics engine on the server will also have to do less work, since it detects all of it's collisions on the triangle level.

As for hollowing, that does add triangles without taking any away. But that can give you a savings over using four solids. With four solids, there are triangles you can't see hidden where the cubes overlap. A single hollowed cube doesn't have those triangles. Also, the server only needs to send one set of parameters instead of four to you. I'd like to hear Andrew's reasoning as to why four separate prims are better than one in this case.

I wanted to do a little investigating, but I can't find a wireframe toggle in the game... But I thought I had seen it before. Did I miss one?