Threaded Mode | Linear Mode

Tad Carlucci · 09-27-2019, 01:18 PM

Here, we're talking about simulator lag, which effects everyone. This is as opposed to viewer lag, which only effects one person.

Think of a period of time. Divide it into three parts.

1) Communications. Sending object information, textures, etc.
2) Scripts. Scanning for event handlers and the execution of any found.
3) Physics. Checking for interaction between physical objects, gravity, etc.

If there is too much to do in one of these parts, the remainder waits until the next time period. This effect is sometimes called "Time Dilation." It simply means there is more work to be done in a given time period than will fit into that time period. So time "slows down," letting things from this period wait until the next. A little every now-and-then is normal and is usually not noticable. When it becomes noticable, we lump it under the general term "lag".

---

Part 1

Lag in part 1 can come from having a lot of textures, large textures, and a lot of avatars, on the region or near the edge of any of the four regions touching it. Every avatar arriving needs to be told about all the objects and obtain their textures. Moving objects (not rotating signs or poofers, but things like avatars and cats walking about) need to send updates to every avatar.

One of the major sources of this type of lag is avatar-attached objects and their textures. You see a number allowing you to gage your complexity and (in many viewers) can choose to not have the objects and texture information sent for avatars over a chosen limit. This can help both you and everyone else (since they don't have to wait for the simulator to send you the textures for a complex avatar), but it won't fully solve the issue.

One thing with will also help is to divide an area up into separate, closed sections. If the simulator can determine that there is no way (due to walls, floors, etc) for you to see a moving object, avatar, etc, it won't send you the information and textures for them. This is why things can seem so much better if you go high up into the sky: there's just less to send you. Shopping malls can be designed with this in mind, but it means customers won't be able to see from one store to another, and can make it feel closed and claustrophobic; so you rarely see it implemented.

Another thing which estate owners can do (but not managers, or mere mortals like us) is to break things up. Avatars on the four neighboring regions need to get information about objects and textures from this one. Moving the regions apart can greatly reduce the lag during this first phase. But, of course, it means you can't walk or fly from one area to the other and must teleport. So estate owners can be hesitant. Plus, it's a hassle to get Linden Labs to move things around and they can get a bit snarky if you ask too much.

Object designers can help with combating network communications lag by using fewer textures and smaller textures. Unfortunately, this can mean less visually appealing obects. But, to be honest, most object designers don't really know about this and simply go for the largest (hence slowest) textures on the assumption that more is better. Nobody really needs a 1024x1024 texture on a nano-prim (which will rarely be more than a pixel or two on the screen) but you see it.

Similarly, mesh designers can use simpler models (and textures) for when you're further away from their objects, only using the larger (and more laggy) models and textures when you're really close. But few do. You already have to make and texture one model; who really wants to do it all over again two or three more times?

---

Part 2

Every time something happens (say, you touch an object, or someone says something), there is a possibility for every object to have a script which wants to know. The similator does not need to check EVERY object, however, only those which have scripts listening. There are also some optimizations the simulator can perform to reduce the "search space". For example, a whisper message only goes a little way and, so, the simulator can pare the list down to only those objects which are close enough and also listening for events.

So, it takes a bit of time to figure out who all needs to know about something. This is roughly linear on the number of objects (prims).

Then, of course, all those scripts must actaully be run. Well designed scripts are usually over-and-done very quickly. Not all scripts are well-designed. And, occassionally, there is no choice but to spend a lot of time on some calculation.

Scripts run in a series. One runs, then the next. This proceeds until all of them are done, or the (one-third) time period expires. When it expires, the currently executing script is allowed to finish. But all others need to wait until the next time slice. The scripts handing events from that next slice will need to wait until the hold-overs from this one all complete.

For most area managers, this is the only thing they can really manage. There are tools to locate objects whose scripts are using more than their fair share of time. And kicking those objects out can have a notiable effect.

But this mainls applies to poorly-written scripts. KittyCatS, actually, are fairly well written and, while, sure, they do contribute to script lag, it is rare to a cat to actually be the source of lag. Even regions with huge numbers of cats rarely experience script-lag from the cats. (This has been repeatedly tested.)

---

Part 3

The final part of each time slice is the physics simulation. This handles things like bouncing balls. Ineria, resistence slowing, or thrust accelerating, objects. For most regions the only physics of this sort is avatar movement. The biggie, though, is "collision detection" ... that is, when one physical object comes into contact with another. This can impart motion to an object (starting a ball to roll or bounce). Or it can stop movement (such as when you walk into a wall). All this takes time. Some of the calculations are pretty complex. And, while it can ignore non-physical (or phantom) objects, there are still a lot of objects which bump into each other.

To make it worse these colllisions can trigger scripted event. So a door which opens when you bump into it can add to both physics lag (detecting you bumpped into it) and script lag (doing whatever needs doing because you bumped into it), which can lead to network lag (as the door moves and that movement must be communicated to every avatar on the region and each of its neighbors).

Luckily, KittyCatS are not physical (and totally avoid this one-third time slice) when they're not moving. So they only contribute to physics-lag when they're walking about (sit/stand tail-wagging don't count). And we owners can control that simply by disabling the cat's ability to walk around.

This is also one area where mesh object designers can help by doing yet another model: the physic model. And, in fact, many do. But all to often that model is far more complex than it really needs to be. Take a house. All you really care about is that avatars can't walk through the wall (two triangles can handle that) but if you just use your visual model (or let the viewer try to puzzle it out when uploading your models) you're using a lot more triangles trying to bump around the window sills, door frames, chair rails, crown moulding, etc.