Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Anti-lag suggestions

Mark Busch
DarkLife Developer
Join date: 8 Apr 2003
Posts: 442
04-20-2003 08:08
I would like to start a thread with some anti-lag suggestions. I believe one Sim-server can contain 10.000 objects. So be carefull with building (see tips) but also the way in which you set the status of the objects and they way you script them can be a great diffrence. I think it really sux that the server where neo-city is located (Varney?) is so slow.
So here are some idea's, please add your own if you know some other idea's

Playing:
-Take it easy
Don't jump around an around and around people and do gestures every second. This will not only annoy people but it will cause lags on slow PC's (server too?)
-Don't use swords etc. when not in outlands
My PC really lags when someone keeps waving a sword around.
-Don't click on scripted objects over and over again.
Specially for objects that produce sound. This also causes lag. The sound system was not designed for listening mp3's anyway (See some other threads). So please don't put these music boxes all over the world, and don't click them every second.
-Don't shoot with freezing or other guns in non-outlands world. That is realllly annoying and it causes lags.


Building:
-Use textures to make complex objects
For example a window. You could use 4 objects for walls (around the window), 4 objects for the edge of the window and 1 or more for the glass. Then if you get one wall with 2 or 3 windows you'll get a LOT of objects soon. It's not only expensive, but it doesn't look good and it slows down the server.
The best thing you can do it just make a wall. Then make a relative large texture (1024x1024) with 2 or 3 windows on it (and everything else you would want). You can use TGA-alpha channerls to make the windows transparant. That way you have a really cool looking wall (and a unique one) and it costs less (only 20$ instead of a possible 300$) and it won't slow down the server.
-Don't use physics if not nessesary. Physics involves collision detection and that slows down the server. Also for people who make elevators (see scripting tips)
-Hollow objects
One of the lindens should comment on this, but I've heard that hollow objects can slow down the server a lot when physical and colliding. Don't know about non-physical hollow objects.
-Boxes and other types.
My guess is (please confirm linden) that boxes are the easiest to do collision detection on. I wouldn't know if it's better to make a hollow box or use 4 loose boxes, but I do think that if you can use a box instead of a more complex object and get the same result: use the box

Scripting hints:
-Don't use scripting when not nessesary. I guess this point is a little weak, but maybe you'll get what I mean. I guess I mean don't leave any unwanted scripted objects to die, because they do use processing power. Only make scripted objects when it actually serves some kind of purpose.
-reduce amount of events.
For example the listen. If you want to listen for the owner to say "fire!" you can do this
llListen(0,"","","";) and check in the listen it it's the owner and if he said the right words. This way every time someone says something the event listen will be triggered!!!
You can also do this
llListen(0,"",llGetOwner(),"fire!";)
Then the SL-system (which can check muuuch faster then scripts) will check to see if the listen event should be triggered. Also you don't need to check in the listen event for the owner and text anymore (unless you've got multiple listens)
-return as soon as possible in an event.
If you're in an event (say listen) and you need to check some things, you could check them all in one big if
if (bla==3 and bla2==4 and bla3==7)
but then it will have to check all those 3. The best thing you can do is to check each thing seperatly and return if it fails:
if (bla!=3) return;
so try to figure out on which contruction of checking the script will return as soon as possible (also think about what kind of check will fail the most of the time and put this on top)
On a return the event is closed and the next can be executed. This will really improve your scripts.
-If you have to calculate the same value over and over again, do it once and store it.
for example (useless example, can't think of anything better). You would want to say the sentence Hello <avatar name> 5 times in a sensor event.
if you do:
llSay(0,"Hello " + llGetDetectedName());
llSay(0,"Hello " + llGetDetectedName());
llSay(0,"Hello " + llGetDetectedName());
llSay(0,"Hello " + llGetDetectedName());
llSay(0,"Hello " + llGetDetectedName());
that will cause each say to get the detected name again, and construct a sting with "hello " concatenated with that name. This is much better
string line= "Hello" + llGetDetectedName();
llSay(0,line);
llSay(0,line);
llSay(0,line);
llSay(0,line);
llSay(0,line);
(ofcouse you can use a loop to do this but that's not the point.)
This way it will have to construct that line only one time: so it will be faster. These are just little things, but it will not only make the server faster, but your events will happen faster so it works better when there are a lot of events.
-Put (moving) objects to non-physical if not used. You can imagine that collision detection uses a lot of processing power. So when you've build an elevator or an car it will keep doing collision detection, also if you think it stands still. So you can easily use the command llSetStatus to put it to non-physics. This way you'll save the server collision detection time. And you can walk onto it much easier (specially on an elevator.


Well I guess this are some basic ideas I've come up with. Feel free to comment on these or come up with some other suggestion. I would also like it if someone from Linden would confirm or deny these tips, or even give some for themselfs.
Jericho Powers
Hero Without A Cause
Join date: 31 Dec 1969
Posts: 166
04-20-2003 10:26
Good suggestions. I tend to go a little high on the polygon counts but in scripts I always try to do things like not leaving objects physical when not in use and setting listens with my key and avoiding timed things like sensor repeat and such. If there are any other suggestions from anyone please post.
_____________________
Gibson, thereabouts.
Dionysus Starseeker
Mostly Harmless
Join date: 31 Dec 1969
Posts: 764
04-20-2003 10:34
Another problem may just be to update graphics drivers. I didn't know about this until two days ago, and my frame rate has gone up by about 10-15 FPS. (Generallized comment, not intended to criticize anyones intellegence, but mine)

Edit: Hehe... Omit my senseless, inadvertantly off-topic statement... (oops) :rolleyes:
_____________________
Life beyond Second Life? Nah...

"...you will get as many answers as people you ask." -- Kenichi Chen *hehe... yep*
Mark Busch
DarkLife Developer
Join date: 8 Apr 2003
Posts: 442
04-20-2003 10:38
Yes upgrading you video card drivers could give you more FPS, but the idea of most of the suggestion is to give the SERVER a higher FPS and obviously using diffrent drivers won't do that :D
but Thanks for the suggestion :)
Jake Cellardoor
CHM builder
Join date: 27 Mar 2003
Posts: 528
04-20-2003 12:38
These are good suggestions. I do have a question though:

From: someone

You can also do this
llListen(0,"",llGetOwner(),"fire!";)
Then the SL-system (which can check muuuch faster then scripts) will check to see if the listen event should be triggered.


How do you know the SL system is muuuch faster than scripts? I expect you're right, since I doubt LindenLabs has implemented just-in-time compilation of bytecodes into machine code, but have you done tests to compare the performance of the two?

The lsl2_reference.htm file mentions that the Reference manual will provide detailed information on the execution model, but I haven't seen a copy of that yet.

Likewise, a few of your other suggestions would be unnecessary with a good optimizing compiler, but I'm sure LSL doesn't have one, so scripters should certainly try to do some optimization on their own.
Mark Busch
DarkLife Developer
Join date: 8 Apr 2003
Posts: 442
04-20-2003 12:54
I don't know the exact implementation of the system as well, but if you look at the server FPS of 3000 frames/sec and then you see how slow a simple loops runs in a script then you'll know the diffrence.
No matter how much you optimize the script code, it will always be interpreted and also a lot of security checks are done on the scripts I think (sandbox).
Also I think keeping the event-queue (if they use that) low is a good idea. Just imagine the diffrence between a single check executed by C++ if (owner!=listenowner) return; (or whatever they use) and the execution of the script.
I have not checked this but I can imagine a script that listen to everything and assuming the script takes more time to execute the checks then the time between two spoken lines, the event queue will be built up and at some point it might all go wrong (I guess some lines never will generate the listen event)

I am not a programmer of SL so I don't know how they build it so it would be nice if someone from linden confirmed or denied these lag causes that I've written down.
Ama Omega
Lost Wanderer
Join date: 11 Dec 2002
Posts: 1,770
04-20-2003 17:20
Putting more information into your llListen(...) will run smoother than the if statement for the simple reason that the server will have to call the event handler in your code less often. Anytime an event handler is called is a context switch, which involves a lot of little activities (swapping in of variables, etc.).

Don't use excessive timer events. For rotating an object use llTargetOmega rather than a timer event that rotates it a little each time - it is smoother and all the processing is done client side not server side which means less server lag. Same for texture animations - use llSetTextureAnim instead of a timmer event with llSetTexture calls.

Don't script or model things that aren't going to get noticed. If the hollow side of anything isn't going to be seen then don't model it hollow. Don't set texture animations on textures that no one can see.

More on hollow: A hollow cylinder is easier on the simultor than a tube. Hollow tori and cylinders are hell on servers, especially small ones. Now for a hollow tori it won't make the hole bigger, rather it will be like a shell of a donut, if that makes sense. The same with a tube. A normal tube has 2 curved surfaces and 2 flat, a hollow tube has 4(!) curved surfaces and 4 flat ones. And in most cases no one will see the hollow part, especially on really small items.

This is just computer modeling. Just because something is hollow in real life (say the spoke on a tire or the tire itself) doesn't mean it should be in SL. No one is ever going to see that hollowness, but the server has to keep track of it all the same.

There is a great tutorial somewhere about making a wall with a window in it from 2 primitives (the wall and a window frame to add thickness) and some good transparent textures.
Jake Cellardoor
CHM builder
Join date: 27 Mar 2003
Posts: 528
04-21-2003 10:05
From: someone

originally posted by Ama Omega
There is a great tutorial somewhere about making a wall with a window in it from 2 primitives (the wall and a window frame to add thickness) and some good transparent textures.


It's here:

http://www.ingiebee.com/SL/walltextures.htm
Mark Busch
DarkLife Developer
Join date: 8 Apr 2003
Posts: 442
04-21-2003 10:24
Thanks for the great tips Ama Omega, I hope that people will read and use them, because I've noticed some more sim's that have dropped to 30 SIM fps....
Huns Valen
Don't PM me here.
Join date: 3 May 2003
Posts: 2,749
06-10-2004 23:59
Please do not make things up and then state them as fact :)

Read this instead: http://www.badgeometry.com/wiki/Lag