What is this thing called lag?
Prims, Meshes and Sculpts
I suppose we've all heard it:
- Prims are laggier than meshes
- Meshes are laggier than prims
- Sculpt are laggier than meshes
- Meshes are laggier than sculpts
- Sculpts are laggier than prims
- Prims are laggier than sculpts
Rendering an object isn't a single operation. It takes several steps and the various materials we can build with load the different steps differently. There is no textbook answer to which material is the laggiest. A good general rule is to try to find a balanced combination to even out the load as much as possible.
The four main stages in the rendering process are:
- Asset lookup
- Download
- CPU processing
- GPU processing
Asset lookup
Each item, whether it's a prim a mesh or a sculpt, is stored as an entry in a huge database called the assets database. That database also contains entries for all other assets, every texture, avatar, region, parcel... absolutely everything that exists on the grid (and also lots of things that once existed but have been deleted). The Second Life assets database has billions of entries. Smaller grids have smaller bases of course but they also tend to have less powerful assets servers and even a fairly minor grid may well have millions of entries in its assets database.Ideally you want something like Bigtable (Goggle's ultra-fast database software) for this but it's expensive. What we use instead, is MySQL, an old open source datbase system that is not built for speed.
The result is that finding an item is quite a lot of work for the assets server. It doesn't matter if the asset is a prim, a mesh or a sculpt though. That is, prims are slightly faster since they only need the database data while sculpts and meshes also need an additional file. The difference is marginal though so as far as the assets server is concerned, it doesn't matter if it's prim, mesh or sculpts. It's the number of parts that counts. However, prim builds do tend to be made from more parts than meshes and sculpts so for that reason prims are generally heavier on the assets server than the other two.
Download
Prims
I don't have any exact information but we're talking low hundreds, certainly not thousands of bytes (not including the textures).Stipulating 0.5 KB transfer time for each prim will be:
- 1 mbit/s connection: 0.4 ms
- 10 mbit/s connection: 0.04 ms
Sculpts
An optimized sculpt without alpha channel will typically require somewhere between 6.2 and 6.5 KB of data. If the sculpt map has an alpha channel, the file size might be slightly more than 8 KB.A regular unoptimized sculpt map will typically have a file size of about 25 KB without and 33 KB with an alpha channel. So:
- 1 mbit/s connection:
- Optimized no alpha: 5 ms
- Optimized with alpha: 6.5 ms
- Unoptimized no alpha: 20 ms
- Unoptimized with alpha: 26 ms
- 10 mbit/s connection:
- Optimized no alpha: 0.5 ms
- Optimized with alpha: 0.65 ms
- Unoptimized no alpha: 2 ms
- Unoptimized with alpha: 2.6 ms
Mesh
The file size of a mesh is hard to predict but if we say 1 KB "overhead" plus 0.006 KB per vertice, we should be in the right ballpark. That means:- 1 mbit/s connection:
- 10 vertices: 8 ms
- 100 vertices: 12.8 ms
- 1,000 vertices: 56 ms
- 10,000 vertices: 488 ms
- 65,536 vertices: 3154 ms
- 10 mbit/s connection:
- 10 vertices: 0.8 ms
- 100 vertices: 0.13 ms
- 1,000 vertices: 5.6 ms
- 10,000 vertices: 48.8 ms
- 65,536 vertices: 315 ms
CPU processing
Before an asset can be sent to the graphics processor, it has to be decoded by the central processor. This part of the rendering flow has been all but overlooked until recently but it turns out it's a major bottleneck and it's not at all unusual for the gpu to spend more than half it's processing time idly waiting for the cpu to finish its part of the job. It's hard to quantify how much impact the various bulding materials have on the cpu load but the obvious differences are large enough it's easy to rank them:- Prims: very fast
- Regular mesh: quite fast
- Optimized sculpts: rather slow
- Unoptimized sculpts: slow
- Fitted mesh: very slow
GPU processing
The gpu load depends on a lot of factors, various graphics settings, the number of textures, special effects etc. But if we focus only on the factors directly related to the geometric shapes:- Optimized mesh: as fast as can be.
- Optimized prim builds: almost as fast as can be.
- Unoptimized prim builds: usually more than fast enough.
- Efficient sculpts: not ideal but not a serious problem unless there are lots of them.
- "Mole mesh": about the same as sculpts.
- Inefficient sculpts: can often cause serious problems.
- Unoptimized mesh: can be anything from not very good to absolutely disastrous.
- Fitted mesh: Poor and unfortunately that's not something we can do anything about. There are a number of bugs in the software that can't be easily fixed and mean that fitted mesh can't really be optimized.
(Mole mesh is my name for partly optimized mesh. The high detailed model is usually quite well optimized but the LoD models have far more triangles and vertices than they should have. It's what you get if you let the mesh uploader generate your LoD models and set the values for them high enough to avoid collapsing LoD. I call it Mole mesh because it's the method the Moles, Linden Lab's hired builders, use. I really don't know whether this method should be condemned or not. It's certainly not something a skilled mesh maker would do but not all builders are technically skilled mesh makers and Mole mesh is certainly a far lesser evil than the far too common collapsing LoD variant.)
Other building materials
There are five building materials I haven't mentioned above, rigged mesh, liquid mesh, animesh, system vegetation and particles. I don't really have much reliable data about these but:Rigged mesh and liquid mesh
These are similar to fitted mesh but use simpler rigging. There is no difference when it comes to the assets server and download file size and there shouldn't be any significant difference to the gpu load. The simpler rigging might mean less cpu load though and casual observation seems to confirm this.Animesh
Animesh is Second Life only and so new there's not much data available. We should expect abuot the same performance as fitted mesh though.System vegetation
System vegetation is Linden Lab's clone of a way outdated version of SpeedTree. System vegetation is fairly simple low poly procedural obejcts that shouldn't cause much load to any part of the system. There is however something strange about how their textures are handled and that may indicate unnecessarily high cpu and/or gpu load.Particles
Particles are sprites, free floating textures not applied to any surface. Unless there is something really weird going on in the software, they won't cause any assets server or cpu load worth mentioning. When it comes to downlaoding and gpu processing it's the same as for any other textures. But particles are nearly always partly transparent and they move. Both those two factors cause significant extra gpu load and excessive use of particles can be very hard on the graphics processor.Textures
Textures and their impact on lag need a separate article but that'll have to wait. Or maybe you should check out The Deadly Sins Of Texturing. It's not a complete presentation of texture lag issues but it does cover the worst mistake builders often make.There is one thing I really should mention here though:
Despite what some people seem to believe, there is no difference whatsoever how the software handles textures for prims, sculpts and meshes.No, there really isn't. Builders do tend to texture different materials differently but those are conventions. But as far as the software is concerned, all it knows is that it's supposed to slap this texture onto that surface. Whether the surface is on a prim, a sculpt or a mesh, makes no difference.
No comments:
Post a Comment