Extreme mesh optimisation

[ChinRey]

Here's something I don't understand.

I'm sure we all often make meshes where we don't need to keep all mesh faces in the high resolution model in all the others so the sensible thing is of course to reduce those faces to a minimum.

Reducing such a face down to a single small square reduces the download LI of course - there's often a lot of LI to save there. But - for some reason, reducing it further down to a single triangle actually increases the download weight slightly!

Can anybody explain why? Is it really easier for the computers to handle two triangles forming a rectangle than a single triangle on its own or is it just the weight calculation that is inexact?

[Drongle McMahon]

That sounds odd. I always use triangles! Have you looked at the uploader triangle and vertex counts to see if there has been an unexpected invrease? Is it definately the download weight that's setting the LI? Is your triangle/quad detaced or attached to the rest of the mesh? Can you reproduce the effect on a very simple model?

As far as I know, the download weight is still calculated from the mesh data size after compression. I suppose it's possible that the compression might sometimes work a bit less well, for some obscure reason, after removal of a triangle, and that could result in an anomalous change like that. 

I just checked with a completely flat subdivided plane (all normmals equal) and a curved one with otherwise the same goemetry and uv map. The download weights were 1.168 and 2.575, even though the curved one had slightly less triangles in the auto-generated LODs. I think this conforms that the loer download weight of the flat one is due to greater compressibility because of the identical normals (note that there is no indexing of normals in the upload format - each vertex has it's own normal whether they are identical or not). So unexplained differences in compressibility could cause unexpected differences in download weights.

[ChinRey]

Talking about the latest item I meshed here. I've seen the same thing happen several times before but it's easier to relate to one specific case for now:

---

Drongle McMahon wrote:

Have you looked at the uploader triangle and vertex counts to see if there has been an unexpected invrease?

---

Yes

---

Drongle McMahon wrote:

Is it definately the download weight that's setting the LI?

---

It isn't but that's irrelevant since I was talking about download weight specifically, not LI

---

Drongle McMahon wrote:

Is your triangle/quad detaced or attached to the rest of the mesh?

---

The quad-to-triangle conversion doesn't change this - not in the latest case.

---

Drongle McMahon wrote:

Can you reproduce the effect on a very simple model?

---

The latest build I noticed it on is a very simple model.

---

Drongle McMahon wrote:

As far as I know, the download weight is still calculated from the mesh data size after compression.

---

OK. That must be the explanation here. There are two possible explanation why reducing the triangle count on that atest build of mine would make the file less compressable but judging from earlier cases, it seems that right triangles with the legs aligned along the axis is more compressable than other tris. Well, they obviously are of course but I'm surprised the difference is big enough to be measurable - there can't be many bytes we save that way.

And of course, the more raw data the various models have in common, the more compressable the file will be. That's good to keep in mind.

[ChinRey]

Replying to my own post here but:

 

---

ChinRey wrote:

it seems that right triangles with the legs aligned along the axis is more compressable than other tris.

---

That is now confirmed. I tested two versions of the same object. Both of them with the same high, mid and low res models and the only difference in the lowest res models was that one had only right-angled triangles (8 of them) while the other had four right angled and four isoceles triangles. The one with all right triangles had a download weight of 0.707, the one with icosceles triangles 0.729.

Then I modified the low res model too, changing the isosceles triangles there (2 out of 10) to right-angled. That brought the download weight down to 0.700.

 

That doesn't seem like much but it can add up in a complex linkset and even in a single unlinked mesh it may well be just enough to decide whether the LI count will be rounded up or down.

 Add Drongle's observation about the significance of normals directions and there may be considerable LI to save by optimising a mesh for compressability.

But I did two more test and got some really strange results:

To check whether data concordances between models mattered, I repositioned two of the triangles that were identical in both the low and lowest res models. That actually reduced download weight to 0.687! Rotating one of the triangles 90 degrees brought it further down to 0.671.

I can't think of anything that can explain this. The two triangles I moved defined the outer limits of the lowest mesh model along the x and y axises but I only moved them slightly along the z axis. oving them didn't change which triangles were detacted and which were attached either. Can anybody explain this?

[Drongle McMahon]

If the movements changed the diagonal of the high LOD bounding box (the "radius" of the mesh), that would affect the download weight. Otherwise, if it's compressibility effects, I think they are generally unpredictable other than in a special case like lots of identical numbers. Since the viewer does the compression, the secrets should be there in the viewer source code, but I think they would be too hard for me to find.

[ChinRey]

Those final changes did not change the bounding box or overall dimensions of any model so it's that unpredictable factor then. Trying to figure that one out may be going a bit too far even for me - and I've been accused of trying to make SL run on a 386. :matte-motes-wink:

But I went over that build I was working on one more time applying the compressibility principle everywhere I could. The end result was a 20% reduction in download weight. That's on an object that was unusualy well optimised to start with and most of the things I did are easily incoroprated in my regular work routines without adding much to build time. I started this thread out of curiosity and didn't really expect it to have any practical significance but this is actually a good result and well worth an hour or two of testing and posting. :matte-motes-big-grin:

Thank you very much for your help, Drongle!

[Pamela Galli]

I have seen this from the beginning. Today, for example, I made a simple chest, 3 LI.   I shrunk it a little, 4 LI.  Shrunk it more, 5 LI.

 

BUT if I shrink it really tiny -- 2 LI!

 

I am sure someone can figure this out but to me it will always seem somewhat random.

[Drongle McMahon]

As all the weights are now calculated by the server (although the old code is still in the viewer), we don't really know whether anything has changed. So my old size-dowload weight stuff may not be completely accurate. However, there is one scenario where this behavior is expected ... for a LI that is based on a triangle-based (not analyzed) physics shape. That weight will increase as you shrink the mesh, until you reach a minimum size where it secretly switches to convex hull. Then it will suddenly decrease, perhaps becoming the download weight instead. The threshold size for the switch seems either to have been changed a few times, or to be dependent on the details of the mesh/prim. I just tried with a tortured torus and it was 0.2m. Foe mesh, last time I tested, it was 0.5m. In the ealy days of mesh I think it was 0.1m.

[arton Rotaru]

This sounds like you have a triangle based physics shape, set to Physics Shape Type: Prim. Any object which dimensions are below 0.2, 0.2, 0.2 will get a single convex hull physics shape assigned from the pyhsics engine automatically. No matter what it's initially set to.

So probably, while shrinking the mesh, your land impact is driven by the physics weight. Which can increase if the triangles get smaller, until it gets very tiny and the <0.2 rule comes into play. Then the download, or server weight is the dominant factor again.

[arton Rotaru]

<0.5 (in one dimension) is still true for the blocked "doorways" with triangle based physics shapes.

[Pamela Galli]

Guys (or ladies).

I appreciate the effort, but there is no way I am going to understand that. I will take your word for it that it is not random, but to me it seems like it is.  Sort of like the sun appears to move around the earth.

[arton Rotaru]

We may keep trying to explain though. :matte-motes-tongue:

[Pamela Galli]

---

arton Rotaru wrote:

We may keep trying to explain though. :matte-motes-tongue:

---

Oh of course -- there are probably a lot of people who understand this (ie math majors).

[ChinRey]

---

Pamela Galli wrote:

I appreciate the effort, but there is no way I am going to understand that. I will take your word for it that it is not random, but to me it seems like it is.

---

It can seem random sometimes to everybody, not just you, Pamela.

The four "weights" - both the three that are the basis for LI calculation and that fourth one that isn't - are really attempts to calculate how much load the object places on various parts of the computer network: simply put, the more data the model has, the more calculations it requires and the more frequent the model is actually needed, the higher the weights.

 

Usually, it is fairly easy to predict the weights and LI of an object once you've done a few hundred meshes (or other "new LI calculation" builds) but yes, there is this seemingly random factor too. Sometimes changes that should reduce LI actually increases it and vice versa.

I think Drongle found the explanation for this: compressibility. Those computers don't work with raw data all the time, they use compress it as often as possible. It's often hard to figure out in advance the compressibiity of the data, sometimes seemingly simple thing can be hard to reduce down, sometimes seemingly complex things are fairly easy to compress.