Lag - prims, meshes or sculpts?

[Vaelissa Cortes]

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.

Interestingly enough, this was actually possible with mesh objects (including the ability to mirror, invert, etc.) with an exploit that was patched a few years back.

 

[Argent Stonecutter]

Wasn't the mesh asset originally something that was applied to a prim rather than a prim itself, back when it was only in beta?

 

[Chin Rey]

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.

I find it hard to see how LL can manage to come up with a functional in-world editor for polylist mesh. There's a reason why nobody else has done anything like that and besides, LL hasn't done any creative development for over a decade now.

A procedural build system more advanced than prims might be a slightly more realistic option. Archimatix is becoming more and more common on Unity based systems, like Sinespace, so at least they have somebody to copy there.

 

[Chin Rey]

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.

The cpu load, yes. Prims are part of the original code and back then LL really went to great lengths to keep the load down. Both the sculpt and mesh handling code are tweaked versions of the prim code (sculpts and meshes even have all the prim twisting paramenters even though they'renot used for anything) and that tweaking didn't exactly improve efficiency.

The gpu load is a bit trickier and that's why I distinguish between "ptimized" and "unoptimized" prim buids there. According to Andrew Linden, the maximum number of vertices a prim can have, is 1024. That's not true (and it's more than a little worrying that LL's CTO for six years didn't know) but the numebr is not that much high - it seems to be about 1350. Obly a few prim shapes are anywhere near as heavy as that though and it's not the whole story either. Unlike sculpts and mesh, prims have quite efficient LoD models and that reduces their actual polycount significantly.

Wasn't the mesh asset originally something that was applied to a prim rather than a prim itself, back when it was only in beta?

That is correct. When a mesh is rezzed, it's first rendered as one of eight prim shapes (which one depends on the number of faces it has), then that prim shape is modified with data from the mesh' lowest LoD model, then the low LoD and so on until it reaches the LoD level it's supposed to have.

 

[Argent Stonecutter]

No I mean, in the original implementation didn't they have a mesh asset in your inventory that was dropped on a prim, like a texture? I thought I'd seen videos that showed that.

 

[Chalice Yao]

Originally, mesh could be loaded onto a normal prim like a sculpty, yes. They, if I recall, changed that to the way it is now before full mesh release, removed the UI elements from the viewer along the way....but guess what, the backend still allowed for setting a prim with the mesh info, sculpty-style, if a viewer sent the right commands...the only bad side effect was, I think, that physics were just like a sculptie's (i.e. a torus, methinks).
It's fixed tho.

 

[Argent Stonecutter]

So what was the reason for caponizing it?

 

[Chin Rey]

No I mean, in the original implementation didn't they have a mesh asset in your inventory that was dropped on a prim, like a texture? I thought I'd seen videos that showed that.

As far as I know, that's still how it's done. The only difference is that the entire process is hidden from the user.

So what was the reason for caponizing it?

There may have been several reasons. One obvious one is that LL already had problems with sculpt map switch animations causing serious load on their servers, allowing the same with the much heavier mesh assets files would probably hacve been more than they could handle.

Another possible reason is how mesh assets are adressed. All other SL assets use 63 bit UUID codes as unique identifiers. That is not a very efficient system for SL and LL has regretted implementing it - they've said that much. There's no way they can change the existing assets names of course but when they launched a brand new asset class, they went for a completely different solution.

 

[Chalice Yao]

Another possible reason is how mesh assets are adressed. All other SL assets use 63 bit UUID codes as unique identifiers. That is not a very efficient system for SL and LL has regretted implementing it

Worse. UUIDs are 128bit, actually.
And I am not sure what you mean by them using a different solution for meshes...mesh assets still use UUIDs internally, as shown by the CDN HTTP calls that grab them. (i.e. https://asset-cdn.agni.lindenlab.com/?mesh_id=<uuid here> ).

 

[Argent Stonecutter]

There may have been several reasons. One obvious one is that LL already had problems with sculpt map switch animations causing serious load on their servers, allowing the same with the much heavier mesh assets files would probably hacve been more than they could handle.

They don't have to provide a programatic "llSetMesh" call.

Another possible reason is how mesh assets are adressed. All other SL assets use 63 bit UUID codes as unique identifiers.

128 bit. And prims (mesh or not) have 128 bit UUIDs as well.

And the issue with UUIDs in Second Life is they pass them around as strings instead of bits. That's an implementation detail, and not an issue with UUIDs verses (say) URLs. Properly implemented UUIDs are very efficient.

 

[Bartholomew Gallacher]

The beauty of UUID generation is that I do not need a central authority; I can just roll the dice and the probability of a number collision, while non zero, when done right is negligible. I am sure this is why LL used this approach; it's reliable and cheap in generation.

 

[Chin Rey]

128 bit. And prims (mesh or not) have 128 bit UUIDs as well.

Sorry, 128 bit it is.

To clarify what I said. All assets in SL use UUID except mesh assets. The reason why they chose not to use UUIDs for mesh assets was, according to Linden Lab, that they wanted a more efficient system.

To clarify even further, a mesh asset is not the same as a mesh. A Second Life mesh is generated from two separate assets, it's the "prim asset" (not sure if that's the correct name for it) which is stored in the assets database and is exaclty the same as for a prim. Then there is the mesh asset which is stored and dowloaded as a separate file and superimposed onto the basic prim shape the same way a sculpt map is for a sculpt. The "prim asset" has a UUID (unique for each instance of the mesh), the mesh asset does not.

 

[Chin Rey]

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.

Going back to the sculpt issue for a moment. I happen to be working on something that is a different example of a situation where sculpts still are relevant right now. Here's a part of a landscape that needs to be filled up:

Gyazo

gyazo.com

A few rocks and some spots of bare bedrock will do nicely:

Gyazo

gyazo.com

The rocks are made from three sculpts and cover almost 6000 m2 of ground. The texture is the same as the ground texture for the mountains in the background (and it's a 128x128) so there's no additional VRAM. The rocks do not affect my frame rate negatively, in fact the fps is slightly higher with them than without. I'll have to add a few plants and other items to finish the landscape of course but it's still nothing to what I would have had to use without those rock sculpts.

 

[Chalice Yao]

The reason why they chose not to use UUIDs for mesh assets was, according to Linden Lab, that they wanted a more efficient system.

A Second Life mesh is generated from two separate assets, it's the "prim asset" (not sure if that's the correct name for it) which is stored in the assets database and is exaclty the same as for a prim. Then there is the mesh asset which is stored and dowloaded as a separate file and superimposed onto the basic prim shape the same way a sculpt map is for a sculpt. The "prim asset" has a UUID (unique for each instance of the mesh), the mesh asset does not.

Sooo...

...they wanted to store meshes with a more efficient identifier than UUIDs...

....so what they did was, make the whole system use TWO unique assets, one of which uses an UUID *after all*, which is also inseperable from the actual mesh asset....

 

[Argent Stonecutter]

To clarify what I said. All assets in SL use UUID except mesh assets.

If they don't have a UUID they're not assets. The asset system is referenced by UUID. They're a *resource* but they're not an *asset* any more than a stream (referenced by URL) is an asset.

If they *are* in the asset system, then they have a UUID even if it's not exposed anywhere.

 

[Chin Rey]

Sooo...

...they wanted to store meshes with a more efficient identifier than UUIDs...

....so what they did was, make the whole system use TWO unique assets, one of which uses an UUID *after all*, which also inseperable from the actual mesh asset....

It's not quite like that, it was the other way round. First they decided to split the mesh data into two separate assets, one with all the "old style" data and one for the new stuff. Then they decided not to use UUID for the new class.

They probably did it to save time - rather than write fresh code for mesh, they simply modified the existing sculpt code - but it does actually make a lot of sense performace-wise too. The "prim asset" contains all the prim properties, that is the parameters that can be modified in-world. The mesh asset contains all the parameters that are determined at upload and that's by far the biggest part of the complete dataset. If everything had been merged into a single asset, all the data would have had to been downloaded separately for each and every copy of the mesh.

 

[Chin Rey]

If they don't have a UUID they're not assets. The asset system is referenced by UUID. They're a *resource* but they're not an *asset* any more than a stream (referenced by URL) is an asset.

That's semantics. LL calls them "mesh assets".

 

[Chalice Yao]

They probably did it to save time - rather than write fresh code for mesh, they simply modified the existing sculpt code - but it does actually make a lot of sense performace-wise too. The "prim asset" contains all the prim properties, that is the parameters that can be modified in-world. The mesh asset contains all the parameters that are determined at upload and that's by far the biggest part of the complete dataset. If everything had been merged into a single asset, all the data would have had to been downloaded separately for each and every copy of the mesh.

I will check later if the CDN HTTP request UUID actually matches the temporary ID of the simside-object, or is unique for the mesh - because what you describe would be supported by the former case, and it would be HORRIBLE for things like Squid/HTTP caching >_> ( /?texture_id= is unique per texture asset, in contrast )

EDIT:
Nevermind! The changing UUID would make sense for rescaling unrigged mesh, texture modifications and the like. I get it now! Weeee.

 

[Bartholomew Gallacher]

I would be surprised if the CDN used by LL still uses HTTP; and Squid doesn't matter for HTTPS, because it's encrypted, and unless you are deploying your own man in the middle attack using SslBump or later features, it won't cache at all.

 

[Chalice Yao]

I would be surprised if the CDN used by LL still uses HTTP; and Squid doesn't matter for HTTPS, because it's encrypted, and unless you are deploying your own man in the middle attack using SslBump or later features, it won't cache at all.

Still perfectly reachable (and cachable last I tested) using HTTP, I'm afraid.