Splitting meshes to save LI - but does it make any sense?

[ChinRey]

Take a look at these two shrubs:

The one to the left is made from two different shapes linked together. The download weight and land impact are 1. The one to the right are made from the same two shapes but they have been merged into a single mesh in Blender. The download weight and land impact are 2. (I didn't get the alignment between them exactly right si there are some subtle differences between their looks but that's irrelevant.)

I've mentioned many times before that if you know what you're doing, you can save land impact by splitting large meshes into several smaller ones. In this case I only saved a single LI but I've seen far more extreme examples, sometimes you can cut the LI by as much as 90% or more. That's a good tip for all builders of course.

---

It does worry me though because it doesn't make much sense. That is, it makes a lot of sense to split meshes for better LoD control but in a case like this, the difference in LoD handling is trivial. What this implies, is that two small files have a smaller combined size than a single larger one containing exactly the same data. That goes against all I thought I knew about computers. Can anybody think of a plausible explanation for this oddity and is it real or just a calculation error?

I have a feeling I should page @Beq Janus here...

[Candide LeMay]

Can you post the LI breakdown for each? And how does the LI change when you resize the objects (bigger or smaller)?

[ChinRey]

1 hour ago, Candide LeMay said:

Can you post the LI breakdown for each?

The split mesh is made from one 84 tri mesh with 0.3 download weight and one 64 tri mesh with 0.6 download weight.

The single mesh has 148 tris and 1.6 download weight.

The physics weight is of course 0.2 and the server weight 0.5 for each part.

The display weight is 429 for the linkset and 509 for the single mesh. That must mean the two smaller files combined actually are smaller than the big combined one. The formula for calculating display weight is published and well known and there's nothing else that can explain this difference.

All those figures are with all three meshes scaled to the same (1x1x1 m) size to eliminate the LoD swap distance factor-

 

2 hours ago, Candide LeMay said:

And how does the LI change when you resize the objects (bigger or smaller)?

That's a good question and something I didn't think of checking before. Interestingly, the larger the size, the less the difference.

 

[Candide LeMay]

Reading http://wiki.secondlife.com/wiki/Mesh/Download_Weight it makes sense that the single mesh has a bigger download weight - it's bigger, so its LOD model bytes are streamed to avatars in a larger area than the smaller split meshes. 1.6 download weight = 2LI vs 0.3 + 0.6 download weight = 1LI

[ChinRey]

28 minutes ago, Candide LeMay said:

Reading http://wiki.secondlife.com/wiki/Mesh/Download_Weight it makes sense that the single mesh has a bigger download weight - it's bigger

No, it isn't bigger . As I said, all the three meshes in the test are exactly the same size, 1x1x1 m.

[Candide LeMay]

24 minutes ago, ChinRey said:

No, it isn't bigger . As I said, all the three meshes in the test are exactly the same size, 1x1x1 m.

What does Firestorm report as object radius on the Object tab? Same number for all 3 meshes? If so then I don't understand why the download weight is different.

Edit: or maybe I do - even at the same size the single mesh is sending more data per lod level than either of the smaller meshes, so that would make its download weight larger.

Edited September 9, 2020 by Candide LeMay
edit

[ChinRey]

30 minutes ago, Candide LeMay said:

or maybe I do - even at the same size the single mesh is sending more data per lod level than either of the smaller meshes, so that would make its download weight larger.

Yes but ut shouldn't be larger than the sum of both the meshes in  the lnkset, yet it is.

[Chic Aeon]

Probably good to note that a larger single mesh will hold its LOD from a longer distance because of its size (lots of factors come into play of course).  I often see items made in parts where some of the parts hold their LODs well and some fall apart within a couple of meters.  Obviously this isn't a good thing.  That can be worked around but often isn't. So I think the better question is whether the item will WORK better as a single mesh object or in pieces.   

[Candide LeMay]

17 minutes ago, ChinRey said:

Yes but ut shouldn't be larger than the sum of both the meshes in  the lnkset, yet it is.

Why not? You have 3 separate meshes, each with its own download weight. They still stream (and LOD) independently even if linked together. If anything this is nice "cheat"/bonus of LI accounting for linked meshes.

[ChinRey]

23 minutes ago, Chic Aeon said:

So I think the better question is whether the item will WORK better as a single mesh object or in pieces.   

Yes but that's another topic really. This is about a build that only uses a single texture and with pretty much equal tris all the way so the entire thing needs the same LoD treatment.

Edited September 9, 2020 by ChinRey

[ChinRey]

3 hours ago, Candide LeMay said:

So its LOD model bytes are streamed to avatars in a larger area than the smaller split meshes.

No, it isn't, I've already told you that twice. There is no difference whatsoever between how the two variants are treated when ti comes to LoD. Both have exactly the same LoD swap distances and exactly the same number of tris in each and every LoD model.

[Rya Nitely]

Hi ChinRey,

I've found this as well with my box hedges. I have them in two different sizes, small and medium. I tried to make a larger, longer hedge by joining the two mediums, and deleting the extra triangles (leaves) but it always has a higher LI when I upload it than  the two medium hedges linked inworld. The LOD is a single box of 10 triangles  (no bottom), and then just 4 triangles for the lower LODs. 

The two medium hedges linked inworld has many more triangles (all those unused leaves where the two hedges are joined) compared to the large single hedge.  I don't remember the exact difference in LI but I think it's 3 for the two medium hedges and 5 for the single large.

So yes, linking objects inworld is often better for LI, but it doesn't make sense.

[Beq Janus]

while this does not surprise me in the least, I can agree that it is annoying in the sense that you cannot reliably know that the way that you have assembled/disassembled a design is the best and most efficient. I'll explain why I believe the discrepancy is arising and hopefully form that you can see that it is to a large extent unknowable in advance and thus a frustration we live with.

In the general scheme of "my split thing costs less/more than my whole thing why?" type discussions, there's generally a couple of things at play, but mostly, in this case, it is zip compression I suspect.

There's no magic in mesh uploading and LI, no trickery, just some rather "simple" and "generalised" algorithms, which mean that while results across the full estate are more or less predictable at the individual level there are corner cases and nuances. 

The streamed data is based on the amount of compressed data. and thus my expectation here is that splitting them is giving a more compressible result. The compression used is zip, which, without trying to go too deep into tech looks for patterns in the data and replaces those patterns that occur most often with a "short" code. The more common the pattern the shorter the short codes (the most common ideally being a stored as a single bit). This is a very poor illustration of the actual zip-deflate algorithm, so for those interested in the real bit-twiddling you can go here

Given the above, the more repetition/ commonality in the data the more compressible it is. When you split the object something about the data is making it more compressible, that could be any number of things, such as facing the same direction (making the normals compress better)being more consistently planar making all the X or Y coordinates compress better. It is not worth second guessing mostly. I posted, once upon a time, about the oddity that can arise from using "use SLM" debug setting whereby you get a better compression. It is not guaranteed and 'use SLM' has other annoying side effects that can make it more hassle than it's worth, but the gains are (as best as I can tell from limited actual investigation) the result of a reordering of the mesh data when you restore from SLM versus the "natural" ordering that occurs when loaded from Collada. NOTE: It can sometimes be worse!

There is potentially, a most optimal sorting for any given  mesh that makes it more compressible, but it's not a one size fits all. 

EDIT - I forgot an important contributor to this saving...rounding "errors"
When we mix things up in the compression we might make a 0.1 or 0.2 saving overall. But this then results in a full LI reduction, why? In this case we were previously at or around 3.6LI and by fiddling around at the edges we made it 3.49LI, the magic of rounding then steps in and our 3.49 is 3LI instead of our 3.6 which was 4LI. 

This can be illustrated by linking two of the 3.6LI objects that were 4LI each and noting that the combined linkset is 7LI (3.6+3.6 becomes  7.2) conversely the 3.4 duplicated becomes 3.4+3.4 and will also be 7LI

END Edit

The other thing (and something  I think @ChinRey circumvented) was the different sizes. It is clear that when you split a large mesh into smaller parts there are very large savings to be made. That is not the case here but is part of the larger story that people will observe. To explain this consider a house, with windows and a door, and on the door is a very ornate brass doorknocker in the shape of a lion. The door knocker is 8k verts, the entire rest of the house is let's say another 8k, as single object we have 16k verts @ 5mx5mx5m (I like my houses cubic clearly). Big objects incur big fees on triangle/vert count and thus this will be a lot more expensive than ff instead I split the two items so I have an 8K 5x5x5 house and and 8k 0.5x0.5x0.5 door knocker. The catch with this is (what Rey was avoiding) that the small door knocker will LOD swap a lot sooner, in my example that is a reasonable expectation and a good trade off.

As I stated above, the equations are simple and consistent, but that is not to say that there are not inconsistencies. two small bushes will LOD swap far sooner than one large one, and thus the theory holds that a lower cost multiplier is used. if the large object gets a cost of X per triangle and the small object get Y per triangle that is nothing that enforces the n*X will be more than 2n*Y. If that works for you and you can handle the LOD swap distance then go for it. 

I can look at the specifics, but my guess here is that compressed_data (A)+compress_data(B) < compressed_data(A+B). keep in mind too that the streaming is for ALL the LODs so the generated LODs (if you use them) for a combined mesh may be less compressible than the generates LODs of the individuals.

Hope this answers some questions. It may be that something else, something I've neglected here, is responsible but that's my opening gambit. 

Edited September 13, 2020 by Beq Janus
forgot a bit