Tateru at Massively has flagged the availability of a new viewer and includes the list of fixes, changes, improvement and other miscellany – and the list is almost mind-boggling in its length.

Aside from lots of incremental usablity fixes (and I’m all for incremental as long as they’re, um, incrementing in the right direction) there are a few things that I think are highlight changes with the new viewer:

Support for Mono
It’s finally here. Took time to arrive but you can finally compile or recompile scripts using the Mono engine. . Originally promised for the first quarter of the year, Mono is supposed to speed up scripts as seen in this comparison of animated sculpts:

Because Mono is optional, I can envision a time soon when sims are advertised as being “fully Mono compliant” much like we’ve seen those “developed for Windlight”. In theory, Mono should contribute, in addition to Havok, to a decrease in lag.

ComputerWorldUK recently commented, however, that Mono puts Linden Lab in the “Microsoft camp”:

“Rosedale seemed not too aware of the potential dangers of tainting his project with Microsoft’s technology, although he did say that other languages like Java, could also be adopted alongside it, so at least the use of Mono is not irrevocable if Microsoft starts to get silly. “

However, the latest release of Mono 2.0 builds, according to Ars Technica cross-compatibility with “.NET 2.0 and C# 3.0 on a broad range of platforms and architectures. Mono 2.0 benefits a wider range of developers, ISVs and end-users by allowing them to write their applications once and run them on any OS platform, dramatically increasing portability”.

For the Second Life user, the visible impact will be quickened response from Mono-compiled interactions. As in the animation above, you can start to expect less lag time between clicking something and a response, smoother animated prims, and perhaps a noticeable reduction in lag as more scripts are recompiled for Mono.

Touch Prim
Another key feature to the new release is support for Touch Prim – and while at first this doesn’t sound like a big deal, it is – mainly for how it sets up future enhancements to HTML on a prim.

The concept is that instead of just being able to touch a prim (click a button say) you can now touch a specific POINT on a prim. First, this can be a prim saver for things like vendors – instead of a single prim for each button or sign on a vendor stand, you can use one prim with a texture, and through Detect Touch be able to create “zones” on a prim and detect where a user is “clicking”. A big prim saver, a need to load fewer textures and, more important, will allow prims to eventually act like clickable Web pages.

The current limitation of HTML on a prim is that it runs through a parcel’s media channel. In the future, loading HTML pages as textures rather than as media would unlock a far deeper ability to “bring in” external content, and DetectTouch will allow interaction with that content.

Sculpted Prim Improvements
Finally Sculpted Prims load in a higher priority, and if you’ve ever visited a sim and waited for big amorphous blobs to form into sculpted prims you’ll know that it’s long overdue. Companions to this improvement include the ability to “flip” inside out prims rather than needing to flip them in an external program like Photoshop, and non-square prims, about which Shack McDougall, maker of the astonishing Prim Composer, has written:

“In the original implementation of sculpted prims, sculptmaps encoded a fixed number of mesh faces (32 x 32) in a 64×64 pixel texture. Larger bitmaps could be used (e.g., 128×128, 256×256, etc.) but they were still limited to 32×32 faces and served no useful purpose after lossless uploading was implemented.

A change is coming! The newest Release Candidate viewer (1.21) adds support for sculptmaps with a variable aspect ratio. As a result, we are no longer limited to 32×32 faces. 16×64, 8×128, and 4×256 faces are now possible by using a non-square texture of 32×128, 16×256, and 8×512 pixels, respectively. These new sculptmap sizes allow a mesh to have a different aspect ratio while maintaining 1024 as the maximum number of faces in the sculpt. By using sculptmaps with different aspect ratios, it is now much easier to model objects that have more detail in a particular dimension, for example, a rope.”

Something for Everyone?
There are a lot of “little things” in the new release. But what’s little to me might be a huge bonus to someone else. An example of this is a simple change: being able to save in-world snapshots in JPEG, PNG, or BMP format – and for anyone who’s struggled with changing file formats so you could upload them, share them, or use them for a specific purpose, this is a huge bonus.

Management of group functions and communications take an incremental step forward as well – but like other features, what might be a small thing for one user can be a huge issue for someone else. The same would apply to changes to terrain editing or estate management tools.

All in all, a feature-packed release, moving well past fixes and bug corrections and, without bringing in something horrifying (remember Dazzle?), manages to add up a lot of seemingly small changes that may have a big impact either in the immediate or longer-term capabilities on the Grid.