Written by Awportals.com

[quote=Awportals]This article was kindly provided to the Chronicles by ScottyDM and is sourced from the Activeworlds Newsgroups.

For more information please see http://www.skunkwks.com/
[/quote]

I see three areas in which performance can suffer in AW:
* Download performance
* Memory performance
* Frame rate performance

Download performance is easy enough to understand and can be helped by doing stuff like stripping out all comments and excess white space from an RWX file before you zip it, or squeezing your JPGs a bit harder when you encode them, or using midi files instead of MP3s.

Of course some of these things produce distasteful results.

Memory Performance

Memory performance is something most world owners don't seem to understand. Stacee touched on it when she talked of picture and texture intensive areas.

I don't know about today's AW browser, but as of only a couple of years ago (version 3.x) textures were stored in memory in 16-bit BMP format... there is no compression.

[rimg]/media/imglib_general/perfguide/scaling.jpg[/rimg]

Resizing Images

Plus, when textures were downloaded they were scaled up to the next larger power of 2 that was a square shape.

For example, a 200 x 200 texture would be uncompressed then scaled up to 256 x 256, which takes 128 KB of RAM. The original JPG might be only 4 KB, but what ends up in memory is a lot bigger.

In one instance a friend had a sprite of a chandelier with a texture and 1-bit mask that was something like 350 x 700.

I took that basic texture, cropped off the edges (lots of waste), scaled it down to 256 x 256 (which distorted it), and created a fresh 1-bit mask. When the new texture was applied to that tallish quad, the distortion was stretched away and the chandelier looked good again.

The Experiment

As an experiment we created two sprites, one using the original texture and mask and the other with the new.

I then exited AW, fired up Windows Task Manager, restarted AW and entered friend's world, and noted the memory AW used - then placed the object with the new texture and see that memory blipped upward by 130 K or so.

Then placed the object with the old texture and see that memory blipped upward by more than 2000 K.

AW had uncompressed that 350 x 700 texture then scaled it up to 1024 x 1024, which requires 2 MB of RAM. The interesting thing was, you had to almost get on top of that chandelier to see any difference in quality of the textures.

Image Sizes

[wcimg=Table of Memory Usage]/media/imglib_general/perfguide/memuse.jpg[/wc]
Why does this matter? Well, if you have 300 textures in one area do you want them to take 2 MB of RAM each or 1/8 MB of RAM each? And remember that pictures placed by the picture command are treated by the rendering engine as textures.

It's pretty easy to go way over 300 textures in some areas. First you fill up your video card's RAM, when that overflows it goes into your PC's RAM that's alloted to aworld.exe, and when that overflows Windows takes over and pages things on and off the hard disk.

The result is that AW seems to freeze for a second or two (sometimes longer). You can't move and can't type.

If you have Windows Task Manager open you'll see "Mem Usage" for aworld.exe is scrolling up and down like mad during these frozen moments. Hold still and once you unfreeze you can chat again and your frame rate looks fine. But if you turn in place AW freezes as all this memory management kicks into gear swapping the textures you now need for textures you don't.

Frame Rate

Frame rate performance is all about the rendering engine.

This is more of a black art as it's highly dependent on the video card and the rev of AW. Remember the old tur_tree set? It used used about 30 clumps or so for each tree (I know of no purpose in having clumps in a static object).

Back in v3.0 days if you put 20 tur_trees in a scene your frame rate would take a noticeable dive. Well, a couple of revs later, and without a hardware upgrade, tur_trees worked much better. AWI programmers fixed something.

Poly count does matter. If you're stuck with the software renderer you'll probably see a linear effect between polys and frame rate--double the polys and you halve the frame rate. Not so with a video card that has hardware T&L support (every 3D card sold today).

The card uses a pipeline and it cannot render the scene faster than the slowest component of the pipeline.

If the texture engine happens to be the choke point, you might double the polys and see no change in frame rate. Also the card and AW both put an upper limit on frame rate. When you're at the limit you can change scene complexity and see no change in frame rate.

Well, if one million-poly model works, what happens when you put it in your world twice? Three times? And what about everything else you put in your world? Also, even when your card's pipe is limited by the T&L engine there are nonlinearities in how it behaves.

If you throw so many polys at it that it cannot hold them all in the card's memory, then frame rate will take a sudden dive.

Also, just because you have the very latest card with a gig of RAM doesn't mean everyone else does too. You did build your objects and world so you could show them off, right?


[rimg]/media/imglib_general/perfguide/cylinder.jpg[/rimg]

Polygon Waste

So don't waste polys! But how do you waste polys?

* When you need a skinny stick you take your modeler's default of a 16-sided "cylinder" when 6, or at most 8, is plenty.
* When you grab that 1500 poly teapot example model and use it in AW--it's a teapot, it's tiny, nobody will ever see the difference between a 1500 poly teapot or a 200 poly teapot unless they're scaled down to the size of a bug.
* When you use polys to do what can be more efficiently done with textures, such as modeling the planks on the side of a wooden ship, or rivets on a boiler.

Do you remember Sirroco world? v2.1 AW and it was one of the best looking worlds and would still blow away many worlds today - all done with textures (and low-res textures too).

And whatever you do, don't even think of modeling the insides of a thing when nobody goes inside that thing - and remember those telephone poles with the wires? Each wire was a 16-sided "cylinder", which is a complete waste.

The point isn't that one model will break the budget, but that when you put it in a world with hundreds of other objects and they've all got these excesses, [limg]/media/imglib_general/perfguide/rwx.jpg[/limg]then you have problems. It's sloppy and it's careless and it's stupid.

That said, there are times when you need verts in the middle of a flat model - for example a floor that you want to interact with spotlights. If you need it, you need it, but don't waste polys.

Light Sampling

If at all possible, use lightsampling vertex rather than lightsampling facet.

On my previous 3D card I ran a test with a million-poly object (the only object in the world for that test) that showed about a 30% improvement in frame rate with lightsampling vertex.

Now if you're making a gem and you need the facets to show up, then you have to use lightsampling facet.

Also lightsampling vertex will make curved shapes look smooth and may make it possible to eliminate a lot of polys (to the tune of a factor of 4 or higher).

Plus the way models are stored in Open GL (don't know about Direct X, but I've heard it's similar) lightsampling vertex will make the model take slightly less memory.

Other Issues

Use single sided polys. The rendering engine will sort through and throw out all the polys that face away from the viewer, which will nearly double your potential frame rate.

Don't use wireframe unless you have to have it. In testing I saw about a 5x drop in frame rate. Looks cool tho.

I suspect that 1-bit masks render faster than gray-scale masks, but I have no tests to back it up.

Extensive testing leads me to believe that protos do not impact frame rate, but I suspect that clumps still have some effect (despite AW's improvements). I suspect that during the conversion process a model with protos is "flattened" while clumps must remain separate.

That's about all I can think of at the moment.

Conclusion

In conclusion, if you make your models more efficient they will probably be simpler and therefore render faster, take less memory, and download quicker.

If you do it right, they'll look at least as good as before.

If you make your textures smaller they will take less memory and download quicker (and probably put less drag on the texture engine and therefore render faster).

Again, if you do it right they'll look at least as good as before.

It's worth a shot.