Active Worlds 3.2 also contains the following miscellaneous changes:

Download progress bar

There is a new progress bar displayed at the bottom of the browser window, indicating how many files are left to download in the current scene:

Note that this reflects downloads based only on the currently visible objects. As you move through a world and encounter new objects, the progress bar will reset itself to represent any new files that need to be downloaded.

New universe options

Universe administrators have a couple of new options available in the universe attributes dialog. The most interesting is a new universe welcome message, which is like a world welcome message except that it is displayed to all users entering the universe, regardless of which world they start out in. The universe welcome message can also be used to send universe-wide messages to all users, since changes to this message are seen immediately by everyone.

Administrators can also now set the latest and beta build numbers of the world server appropriate for their universe. Version 3.2 and later of the world server will display a message in the event log indicating a newer version is available, if so indicated by the build numbers. Generally, as with the browser build numbers, universe administrators should only set the world build numbers to values recommended by Activeworlds Corp.

Improved MIDI playback

Beginning with version 3.1, Active Worlds began using Microsoft's DirectMusic for the playback of MIDI files. However, this turned out to create a significant number of new problems for MIDI playback. In version 3.2 we have abandoned DirectMusic for MIDI files and are trying a new approach: we now simply pass MIDI files to Windows Media Player, which is the same mechanism used for MP3 files. This seems to produce far superior MIDI playback quality than the old DirectMusic approach, and with far fewer compatibility issues.

New web settings

There is a new web settings dialog which gives you better control over how Active Worlds displays web pages.

New world options

World owners have several new options at their disposal, including the ability to use skyboxes, set a minimum visibility, and disable the repeating ground feature. See world features for details on these new options.

Hardware "T&L" support

The term "T&L" refers to "transform and lighting." Transform and lighting are two computationally intense (in other words, slow) stages of the 3D rendering process that have traditionally been performed in software. However, the latest generation of 3D accelerated video cards (including the Geforce from Nvidia and the Radeon from ATI) can now perform these calculations directly in hardware, relieving the burden from the main system CPU. The Direct3D support in version 3.2 has been updated to take advantage of hardware T&L if it is available in the local 3D hardware. OpenGL mode can also use hardware T&L if your video card and drivers support it.

New transparency algorithm

Version 3.2 uses a new version of RenderWare, the 3D graphics engine, in order to take advantage of its support for hardware T&L, OpenGL, and software rendering. Unfortunately, in this new version they dropped all support for the automated handling of transparent polygons. This will cause noticeable changes in the rendering of some objects that use transparent materials (which includes any objects that use masked textures.) We have spent considerable effort trying to replace their algorithm with our own. Our algorithm is simpler, and in some cases actually works better than their old algorithm, but in other cases it can produce noticeable artifacts. Some objects may have to be redesigned in order to reduce these artifacts. Unfortunately there is not much that can be done about this at this time.

Transparent polygons are difficult to render because they can't use the normal "Z buffer" technique for determining which polygons are visible to the camera (also known as "hidden surface removal.") Z buffers work by figuring out which polygon is the closest visible polygon at each pixel, and setting each pixel to the color of the closest polygon. This doesn't work for transparent polygons because many other polygons may be visible through (i.e. behind) the transparent polygon. So, any transparent polygons in a scene have to be handled separately from the opaque polygons.

In summary, the new algorithm works by saving the drawing of any transparent objects until last, and then sorting the transparent objects by distance from the camera, and then rendering them back-to-front. This handles most common cases of multiple overlapping transparent objects, but it will often not correctly handle the case of complex polygonal meshes that are transparent and overlap with themselves as viewed from the camera's position. In these cases, the artist can use the new RWX commmand opacityfix to instruct the engine to spend more time attempting to render a particular transparent object correctly. The opacityfix command is optional since its algorithm is much slower and should only be enabled when deemed absolutely necessary for a particular object. COB users can access the same functionality with the new group name "aw_opacityfix".

There are some cases that simply will not work, with or without the opacityfix command. One example is the commonly used trick of making trees or plants by placing several masked quads at different angles, all intersecting at a common vertical axis in the center. For objects like this, there is no correct order in which the quads can be rendered such that rendering artifacts don't occur, since every quad is both before and behind every other quad. The only solution for such objects is to break them up so that the quads don't overlap, but rather simply meet at the center at a common edge, typically by breaking each quad in half at the center.

Another case that often doesn't work is when you have a large transparent object (such as a ground object) behind a smaller one. This case fails because the larger object often appears to be closer to the camera than the smaller one, but it actually isn't, so they get drawn in the wrong order. Really the only practical way to fix this problem is to break the large transparent object up into smaller pieces, either by making it into separate objects, or by breaking the existing object up into many smaller and separate clumps in the RWX file, or by breaking the existing object up into smaller polygons and using the opacityfix command.