General Tips

• Coronas will cause a significant lag if they overlap eachother when viewing them. This will happen if their size is large, or when you view them from a distance, or when you have them arranged to easily see through them such as building a line of them and looking down it. Many overlapping coronas can bring even a powerhouse computer to sub-1.0 frame rates.
• Obviously, high polygon objects cause lag. This is especially true with the new tbtree0## objects in Alphaworld, as they have over 1000 polygons. A forest of those will cause enough lag to notice it for most people.
  
  On the same note, try to optimize polygon count by making sure you're using the largest object for the job. For example you might have 5 wall001.rwx objects in a row, 20m long. You could replace this with 4 wallh01.rwx objects, shaving off 12 polygons. Or use 2 wall001h.rwx objects sunk underground a bit, saving 36 polygons.
  
  Use the scale command to manipulate an object's size in order to reduce object count. You can make a large wall object instead of a bunch of smaller objects.
• However, if you have to pick between more polygons and less objects, pick less objects. The browser seems to handle more polygons better than it does more objects.
• High resolution images will eat up video RAM, and cause lag for people with older video cards (32MB and below). Useful to keep in mind if you want to hang up a lot of images on the walls, for example. A 512x512 resolution image uses about a half meg of video RAM. If you're creating a custom graphic for a picture accepting object, make sure it's no larger than it has to be.
• Because textures use video RAM, avoid using too much variety in textures in a given area. Once a texture is a loaded, it doesn't matter how much you use it in the area - it will still use the same amount of memory. Try to establish a set of textures to use in an area, and avoid using variants of a single texture.
• Place a "create solid no" on objects which don't need solidity. The more the better. This disables their collision matrix, which increases overall performance. This only really applies to computers where the CPU is bottlenecking the graphics card.
• Make unseen interiors and rooms invisible. Then they won't be rendered, causing big performance gains. Place bump triggers near their entrances which turn them visible again. This method was mostly made obsolete by radius visibility, but it still has its place if you want to also shut down solidity while your at it. Also radius visibility does not instantly kick in since it needs to compute the radius, whereas this method is instant.
• Applying a mask to an object makes that object roughly 2x laggier than its non-masked version. Avoiding masking high polygon objects if possible.
• Sign objects with text on them are slightly laggy in numbers. You may want to place buildings that involve tons of signs (like a resident listing) not so close to dense areas, or areas that need high vis.
• Objects emitted by particle emitters are less laggy than normal objects. An emitter emitting one static particle is 15% less laggy than a standard object. However particle emitters use about 6x the space a regular object uses.
• Objects with insta'moves applied to them (eg create move 10 time=0 wait=9e9, to workaround cell space), are about 5% laggier than normal objects. Avoid using it if possible.
• If an area has no reason to have visibility greater than, say for example 50m, then zone that area with fog set to 50-50 (min-max). Objects outside that range will be clipped off. This can be useful for windowless interiors or underground builds.
• To object modelers: avoid using transform script. Things like scale, rotate, and basically anything with the word transform in it. This seriously bogs down their render time and the collision matrix because the objects have to be created on-the-fly instead of being pre-defined. Programs like Accutrans can convert objects to remove the transforms. By removing the transform script, I've seen fps gains of nearly 80% in areas heavy with the said objects. If your an Alphaworld builder, you can take advantage of the cleaned up objects through AWE

Radius Visibility

Radius Visiblity, or as I call it for short, Radvis, is a feature added in AW build 963. You can use it to prioritize when an object will be rendered. If you want an object to load only when you're within 50 meters of it, then apply to that object:

Listed below are some examples of how I use radvis, to help get you started.

• For objects that aren't viewable untill you get right up to them, such as something down a hole or around a tight corner, set the radius visiblity very low such as 10-20.
• For very tiny objects, like checkers, or hard to see features, a radius of 20 or 30 should work.
• Moving onto small outdoor objects, like things no bigger than 2mx2m, I usually do not give them a radius unless they are somewhat high in polygon count, such as if they were a sphere or other geographically intensive piece. Usually I set these to 60-80 depending on size.
• For indoor objects in buildings with windows, I'll set the radius anywhere from 30-80 depending on how visible it is from outside, and if visible, how noticeable it is.
• For indoor objects unviewable from the outside, I'll set the radius to whatever their distance is from the front entry of that room.

Remote Optimizations

The first four suggestions are about remote commands. Remote commands are when you name a set of objects (create name), and apply a command to them with another object, remotely. For terminology's sake, the object which applies the command is known as the texturer, or the texturing object. Some people call it the gear, and the use of such technique is sometimes called using astarts.

• Don't use them!...if you don't absolutely have to that is. Tests have proven that applying the texture directly to the object is faster than having a texturing object do it instead. This is especially true if the texturing object has to texture thousands of objects. The more objects, the more lag a texturing object will cause. If you're building in an area that will be the home to a number of buildings, it's highly recommended to prioritize lag over cell space by just using direct texturing.
• Remove zero delay. The 3rd number in remote texturing, unknown to many, represents how often the texture will be applied. Many people leave this at 0 which causes the computer to apply the texture as fast as it can, which obviously stresses it out and lags it. Below is a typical example of a zero delayed texturer:
  
  create animate me . 1 1 0,astart;adone texture wood1 name=a,texture metal2 name=b,astart
  
  Note '0' near the beginning. I advise you change it to 1000 (1000 milliseconds) which is a 1 second delay. Tests have proven time and time again that adjusting 0 delay poles in heavily developed areas can cause HUGE increases in frame rate. (tip: you could also use a 999 delay to save a byte)
  
  For very dense areas, you might considering using a 2 second delay (2000).
  Consider using a long delay such as 5-15 seconds for objects that aren't immediately seen, such as interior or underground objects.
• Don't use many duplicate texturing object. As you probably know, a texturing object only works when it's currently visible, which can cause a problem for larger builds. The common solution would be to build copies of the texturing object all around the project. However this will quickly cause a bunch of lag. I advise you only pick 2 corners of the project zone, and keep all the texturing objects there.
• If you have multiple texturing objects in 1 cell doing a lot of work, offset their delay by a hair. For example if you have 5 texturing objects texturing thousands of objects, they will all reapply the texture every 999 seconds, for example. This will cause a "lag bomb" every interval. The solution is to keep the texturing objects in separate cells, or offset the delay by 50 milliseconds or so.

See Also

• Cell Space Conservation