Why UUID Flipping is Bad

Introduction

Note: This discussion is a little old. Meshes are no longer addressable by UUID. The problems detailed below, compounded by server stability concerns, took the idea out of the running.

Please use Animesh instead!

With sculpted prims, many residents took it upon themselves to create "animated" objects by using LSL to change the sculpt UUID thinking this is a supported method of creating animated objects inworld. In truth, Second Life does not currently provide any adequate means of animating objects beyond position/rotation/scale. This article aims to clear up some of the rumors and speculation around why UUID flipping is good or bad, and why UUID flipping is being throttled for mesh to prevent the creation of objects that animate in this way.

What UUID Flipping Actually Does

When you change a mesh UUID, it sets off a chain of events that stresses the entire Second Life content streaming system. From the back end on down to the viewer:

• The simulator must fetch the new mesh asset from the asset server or load it from disk on its local cache, creating disk and network load for the host
• The simulator must parse the mesh asset and update the current object cost, possibly causing the object to be returned for overflowing prim parcel limits.
• Whether or not the object is physical or phantom, the simulator must construct some new physical proxy for the object based on its new size
• All nearby viewers must download the new asset or load it from their local cache
• The new mesh must be decoded into the mesh instance store
• The mesh in the instance store must be copied and transformed out into a vertex buffer for rendering
• Any render batches the object was a part of must be rebuilt
• The space partition the object was a part of must be updated

What the Load Looks Like in Numbers

Say you have a simple 5000 triangle horse with a modest 16 frames of animation. With the current average of 10 bytes per triangle, each frame of animation will eat roughly 50KB of bandwidth, making this 5000 triangle object use the same amount of bandwidth and storage as an 80,000 triangle object and use nearly 1MB of bandwidth to download all frames and LODs. Once the object is decoded, its memory footprint per frame would be around 250KB of vertex buffer data, or 4MB for the entire 16 frames, making it not practical to hold all frames in memory, so even after an object is downloaded, flipping frames would cause much disk access and frame transitions would be slow.

Alternatives to UUID Flipping

• Textures -- where possible, use texture animation or swapping of textures. This is particularly useful for blink animations
• Transparency -- Keep all frames rezzed all the time and use scripted calls to set non-visible frames to 100% transparent. This will cause the renderer to load the object once, and 100% transparent objects are not drawn. The "prim" cost of the object will go up, but this cost is reflective of the actual load of an animated object.
• Skeletal Animation -- wherever possible for attachments, use the avatar skeleton to animate the mesh.

The Glorious Future

Skeletal animation -- the animating of a single mesh by rigging it to an animated armature -- is the proper long term solution to creating fast, efficient, and attractive animated objects and avatars. The bandwidth and memory required is a tiny fraction of that required for UUID flipping, and the performance and visual results are much better. Any development effort that aims to support the future of animated objects in Second Life will focus on expanding avatar and object skeletal animation functionality.