Lag - prims, meshes or sculpts?

[Chin Rey]

I've finally found some time to update my builders' blog. It's the first in a series of posts that are (hopefully) going to eventually cover all important aspects of lag. I started by looking at the geometry, comparing our three main building materials, prims, mesh and sculpts. I've tried to simplify as much as possible with a minimum of "tech talk" but it is actually a very complicated topic so if you are easiy bored, you may not want to read through it all in one go. Maybe bookmark it and keep it as a reference instead.

Feedback is always apreaciated, either here or on the blog. I do not claim I know everything about good building and there's always room for improvement.

Edit: Forgot the link! Here it is: Second Life (and Hypergrid) Builders' Manual: Lag: geometry (prims, meshes and sculpts)

 

[Chalice Yao]

This is a good writeup! Thanks for making it

I think It's important to stress for folks that, sadly, the reason certain types of mesh stress the CPU and GPU immensely is the result of bad coding in the SL client, as Chin already hinted at in her writeup. It's not a result of the technology itself - i.e. don't blame the concept of mesh!
Traditional games are stuffed with all kinds of mesh, rigged, unrigged...they don't even really use other types of content for the most part., and they perform well.

But in SL's case, there are of course the problems that


1) Rigged mesh always gets displayed at highest LOD by the SL client - no matter how far away the camera. Which also makes creators just drop all other LODs than the highest to a bare minimum in order to essentially get a minimized $L upload fee, LI cost and (sadly) having a very misleading low Render Cost value as a result...
...and because LL hates breaking legacy content, this might be something that will never get fixed. :|

2) Creators make rigged mesh that has a high five-figure, or even often enough a six-figure amount of triangles when made of multiple parts.

3) The SL Client code for making rigged mesh "move" is horrid, actually moving specific triangles of the mesh in turn in several passes - one for each type of rendering: Diffuse, fullbright, alpha'd, with specular materials, with normal materials etc. *AND* it does it all again for global shadows, if you have shadows enabled. *AND* again for every projector.
It's essentially what I did with the simplified Avatar Shadows option - it skips a pile of those passes that are just unnecessary for the avatar shadows, or downright removes some more visual ones. The speedups can be immense, but still...it's in the end a workaround to a bigger code problem.


Essentially, all three points combined is what is currently the biggest source of FPS drain when you have a pile of avatars around, and even more so when you have shadows enabled. Insane-polygon-count rigged meshes meeting bad client code that doesn't help, but instead makes things even worse.
So please; When making rigged mesh, optimize the geometry. No matter if you are certain hair makes or fashion-designers. Pretty very please. It's a big problem for all of us.


.

 

[Da5id Weatherwax]

3) The SL Client code for making rigged mesh "move" is horrid, actually moving specific triangles of the mesh in turn in several passes - one for each type of rendering: Diffuse, fullbright, alpha'd, with specular materials, with normal materials etc. *AND* it does it all again for global shadows, if you have shadows enabled. *AND* again for every projector.

YHGTBFKM......

You mean they don't do the sensible thing and transform once then render? They transform anew for every path through the render pipeline????? Tha's so mindblowingly fucked up.

 

[Bartholomew Gallacher]

Hi Chin, I do disagree on one point of the mentioned blog post, and this is the mentioning of MySQL.

Since we are talking here about Second Life nobody knows exactly nowadays what the Lindens are using to store the asset metadata. While it has been MySQL in the beginning for sure this has transitioned years ago to a different type of software. We don't know any longer which database engine Linden Lab is using internally; afaik the assets themselves are in the Amazon S3 cloud today.

In the context of Opensim MySQL is the default database, but not the only choice either. And there's also the option to only save the asset metadata in the MySQL-database, while the assets themselves are being saved directly in the file system, which is of course much faster than saving the assets in MySQL directly.

I also strongly disagree that MySQL per se is slow out of the box; on the contrary in former times it has a reputation to be really fast, because of the non-ACID compliant ISAM engine, which was the default way back then. Of course InnoDB takes more resources, but that's the price for ACID compliance, and doesn't mean that MySQL is slow, either. If a database tends to get slow its normally a sign of bad database design and/or no cache tuning for your specific work load.

 

[Chalice Yao]

YHGTBFKM......
You mean they don't do the sensible thing and transform once then render? They transform anew for every path through the render pipeline????? Tha's so mindblowingly fucked up.

Yeeeeeeaap. Eeeexactly. And if you are looking for spatial and temporal data locality in the SL client, you won't find it...

 

[Khamon]

For a moment, reading Bartholomew's post, which is correct in detail, I thought I was reading the 30th Anniversary of the Web thread.

 

[Bartholomew Gallacher]

Chin Rey: I disagree on your opinion about sculpted prims. The detailed explanation why can be found here: Mesh Vs. Sculpties - Tradewinds Yacht Club

The short version is that nowadays sculpted prims have become obsolete; all you ever did with them and more can be done with mesh. While you are able to optimise the polygon count of meshes, a sculpted prim normally uses regardless 1024 polygons (since most don't bother to use a smaller map), even if you need much less than that, which puts an unnecessary burden on the GPU.

Therefore sculpts should be avoided by any means.

 

[Chin Rey]

Chin Rey: I disagree on your opinion about sculpted prims.

The purpose with the article was to present the facts as well as possible, I really hope I didn't add too much subjective opinion there (although of course it's impossible to completely avoid that).

Sculpts are more streaming efficient than mesh, that's a documented fact. The file size examples I gave for mesh are according to LL's own Mesh FAQ, the sculpt file sizes are based on what you typically get form a JPEG2000 file with lossless compression.

Sculpts are much harder on the client cpu than mesh (they shouldn't be but the sculpt handing code is shoddy to put it mildly) and they can not be optimized as well as mesh for gpu performance. For those reasons I do agree that we shouldn't use sculpts very often. But I do not think we should rule them out completely. If we really want to optimize as much as possible, we need to look at the whole picture and not stare ourselves blind on pixel, vertice and triangle counts.

 

[Bartholomew Gallacher]

If we really want to optimize as much as possible, then we need also talk about user priorities.

For most users the top priority is a as high as possible FPS rate, then comes download speed; the only thing according to your blog post going on for sculpts are the lower download times compared to meshes.

By the way did you label your download speeds wrong; it should not be "1 kb" and "10 kb", but I think it is"1 mbit/s" and "10 mbit/s", otherwise it absolutely makes no sense at all.

And you absolutely left out the biggest download speed problem - oversized textures, which are in reality normally causing the download bottlenecks we all know so well. Since textures by far do outweigh the storage needed for the 3D data itself, they do matter much much more than the transfer speed of an untextured sculpts or mesh alone, which in relation makes a one digit percentage of the whole download package. Of course downloaded once and being in the viewer cache for some time helps a lot then.

Having said that, I continue to disagree on sculpts- those should be avoided. Period.

 

[Chin Rey]

Since we are talking here about Second Life

My blog is actually intended just as much for the hypergrid as for SL. But I couldn't post about it in both section of this forum of course, I ahd to choose one.

[QUTE]nobody knows exactly nowadays what the Lindens are using to store the asset metadata.[/QUOTE]

They did mention it's MySQL in the official blog quite recently.

As for the open soruce clones. opensim is My SQL based and so is Halycon as far as I know. Arriba sim was MySQL based but may have switched to MariaDB recently. Whitecore is entirely file based and much, much faster than eny of the others.

I also strongly disagree that MySQL per se is slow out of the box; on the contrary in former times it has a reputation to be really fast.

Fast is relative of course. Any general purpose relational database will perform at snail pace compared to lean and mean flat file databases that are built for speed and speed only - like Bigtable.

I can't say how much of the assets server performance is due to the software and how much is due to the implementation of course but it's easy to see that the database lookups can be a significant botleneck in the total rendering process. This is also refelcted in the way land impact is calculated. Server weight is LL's estimate of assets server load and they've given it a suprisingly high significance compared to the streaming cost.

 

[Chin Rey]

For most users the top priority is a as high as possible FPS rate

Then go for what gives the highest possible FPS. I'm seriously not trying to argue for any opinion in that article, I'm just trying to present the facts as well as possible and let people decide themselves what is the most important to prioritize.

That being said, frame rate is not only about gpu performance. It doesn't matter how strong your gpu is and how well optimized the end result is if the gpu spends most of its time idly waiting for data to process. Tests done by others and posted at the official forum, indicate that both streaming and cpu processing can be serious fps reducing factors.

By the way did you label your download speeds wrong; it should not be "1 kb" and "10 kb", but I think it is"1 mbit/s" and "10 mbit/s", otherwise it absolutely makes no sense at all.

Woops! Corrected those typos. Thank you!

And you absolutely left out the biggest download speed problem - oversized textures.

That's for a separate article.

Having said that, I continue to disagree on sculpts- those should be avoided. Period.

I may go along with you if you say optimized mesh. But consider this: 10 sculpts in a hair are 2560 vertices. Compare that to a 25,000 vertice fitted mesh hair...

 

[Vaelissa Cortes]

I may go along with you if you say optimized mesh. But consider this: 10 sculpts in a hair are 2560 vertices. Compare that to a 25,000 vertice fitted mesh hair...

25k would be refreshing. Hair these days has hundreds of thousands, to over a million vertices. It is bad.

 

[Qie Niangao]

Having said that, I continue to disagree on sculpts- those should be avoided. Period.

I realize this is a thread about performance and y'all can argue about that as much as you want, no matter to me. I will, however, speak up for sculpts because as much as they perhaps should be obsolete, the representation adopted for Mesh (binding the model to the instance) makes it useless for a host of applications requiring interactive redefinition of the geometry, for which sculpts are still viable. Put simply, a Mesh object is the only object type unable to be redefined to/from every other object type. That makes the world a sadder, less interactive place (Animesh's absurd overkill notwithstanding), even if the pixels dance a tiny bit faster.

 

[Chalice Yao]

That makes the world a sadder, less interactive place (Animesh's absurd overkill notwithstanding), even if the pixels dance a tiny bit faster.

I am..really not sure why you define Animesh as overkill.
The only complaints I'd have about Animesh would be that it uses the default SL avatar skeleton only. It's silly that it does not allow for optimized, custom ones for non-attachments, with only the bones an object actually needs.
And the second complaint would be the fact that because of the aformentioned performance issues LL introduced into rigged mesh forced them to severely limit the possibility of Animesh attachments and putting high LI costs on in-world objects. It's a classic tale of LL not fixing root problems but instead limiting the potential of what's new.

But aside of that, 'Animesh' is only something special and 'new' in SL. Anywhere else, it's simply the standard.

P.s. while I can see some potential fancy uses of being able to 'switch out' the mesh of an object on the fly with another one (for creature transformations and the like...), it'd also have to have an interval throttle, IMO.

.

 

[Qie Niangao]

Animesh is fine for hand-crafting objects that behave like pets or NPVs, or even maybe foliage, but it's yet another virtual world platform feature born of video game envy. There's no way to algorithmically define the deformations at runtime (beyond lamely choosing one of a set of canned anims), so there's still no way for a script to devise new geometry for the already-rezzed mesh.

I'd be fine with a throttle; for my purposes the throttle could be once per fortnight. But give me a way to send a message across the grid that remotely defines a shape that has never before existed at that location (or better, anywhere in SL). I'd gladly trade every Animesh NPV and pet that will be plaguing the Marketplace.

 

[Chalice Yao]

but it's yet another virtual world platform feature born of video game envy.

Wat.
...I kind of expect my virtual world platform to support 20 year old video game technology. Seriously.
We finally have a half-assed attempt, but it's embarrassing enough that it didn't support it a decade ago already.

Now, that said, the fact that something *new* like programatically changing/deforming a mesh using LSL would be quite neat is a whole different animal, and I agree with the principle.
But:
I think the first step of giving the standard concept of mesh a more Virtual World tuned foundation would have to be an in-world mesh editor. *That* would be the foundation to put other Virtual World features on top, IMO. It would be *great*. I want one, badly.

It'd be very analog to the historical development of Prims - give us the tools to make the mesh in-world (Even if it can never match fully fledged third party tools), then give us the scripting tools to change it dynamically. That'd be neeeeat.

 

[Qie Niangao]

I think the first step of giving the standard concept of mesh a more Virtual World tuned foundation would have to be an in-world mesh editor. *That* would be the foundation to put other Virtual World features on top, IMO. It would be *great*. I want one, badly.

It'd be very analog to the historical development of Prims - give us the tools to make the mesh in-world (Even if it can never match fully fledged third party tools), then give us the scripting tools to change it dynamically. That'd be neeeeat.

Absolutely. Given my 'druthers, though, those would share a common API to mesh geometry creation... and in some bright future, "the" in-world mesh editor would be plug-and-play for multiple purpose-fit user experiences of mesh creation.

Again, though, they crippled the very representation of mesh, unnecessarily adding a barrier of major refactoring and data migration between SL and the future.

 

[Amity Slade]

In what cases can you do something better with a scuplt better than you can do with a mesh?

I will, however, speak up for sculpts because as much as they perhaps should be obsolete, the representation adopted for Mesh (binding the model to the instance) makes it useless for a host of applications requiring interactive redefinition of the geometry, for which sculpts are still viable.

That is a good case which I had not considered.

I cannot think of any other cases in which a sculpt can do something better, or more efficiently, than a comparable mesh. The fact that mesh allows for more abuse from poor optimization does not mean sculpts are more efficient. It means that creators should learn optimization as a basic content creation skill.

The efficiency comparison should be apples to apples- not scuplt to poorly optimized mesh. A scuplt map represents the equivalent of 1024 vertices (I think)- so the comparable mesh would have 1024 vertices.

 

[Da5id Weatherwax]

Prims, sculpts, static meshes, rigged meshes.. they all have their use cases and these use cases have been somewhat dynamic over the years as the options available and the underlying code has evolved.

Using the right one for the situation that applies, and optimizing it to the best of your ability is never wrong.
Doing otherwise is never right.

 

[Argent Stonecutter]

Is the CPU and GPU cost of a geometric primitive really that low? Some prims have an awful lot of vertices. Consider a path-cut twisted torus.