Li/ARC accounting systemically rewards insane poly counts
tracked
Coffee Pancake
I present the same model (a small avatar accessory) with 2 different sets of LOD models. In each case the lowest LOD model has been 'zeroed out' to 18 tris as is typical in this use case.
Triangle counts are as follows.
* Model 1 - High 63040 (36k virts), Med 15760, Low 3940
* Model 2 - High 15760 (10k virts), Med 3940, Low 3940
Both of these models are visually indistinguishable in use.
The DAE files prior to upload are sized as follows.
* 63040 tris - 9.2mb
* 15760 tris - 2.2mb
* 3940 tris - 500kb
Working on the dae sizes alone ...
* Model 1 - 11.9mb
* Model 2 - 4.9mb
However ....
* Model 1 - Download weight 0.7
* Model 2 - Download weight 3.1
When worn ARC is equally broken (as reported in firestorm)
* Model 1 - ARC 319
* Model 2 - ARC 672
Objectively Model 2 is better for performance. Duplicating the mesh for 2 detail levels is punished to the point that using a sub division surface modifier to generate an insane 63k tris high model results in 'better consumer numbers' at intended object scale (it's also cheaper to upload).
In addition to model duplication being unnecessarily punished, the scale component of Li accounting is fundamentally flawed and pushes creators into a situation where large items need to be low poly and tiny (often worn) items are best high poly! No wonder everyone's avatar is solid in wire-frame.
This model is a small avatar accessory. Obviously the example mesh is over detailed, 'unoptimized' and created using techniques best suited to slow rendered content rather than real time. The point is why should anyone bother with 'low poly' when this gets the-job-done and is predictably rewarded.
Log In
Dan Linden
tracked
Dan Linden
Thank you for the report, Coffee!
Imported to https://github.com/secondlife/triage/issues/89
Attachments can be added to that issue, if you please.
Beq Janus
If only Canny supported attachments....
The ARC being broken is nothing surprising it is an almost entirely worthless metric that does more harm than good. However, LI is mostly more robust. The download weight is affected by scale and compressed bytesize so that raises a couple of questions:
Do both models have the scale applied? i.e. are they the same actual size as seen by the uploader on the scale tab?
The scale will also affect the relative weights of the triangles in each, meaning that for smaller items the high LOD cost weighted far lower than the low LOD cost as it is "less visible" in a scene and decays far sooner.
I've not checked if it still works on the latest blender but my SL addon "SLender" gives you the predicted per-triangle cost at each LOD. (https://github.com/beqjanus/slender - it was working on v3 but I've not touched it in ages)
Compressability becomes a factor, I've demonstrated in the past that ordering the indices differently can change the LI as it allows libzip to do its work better. Another thought is that possibly the quantisation to 32bit integer space is culling the stupidly dense a bit.
Interesting.
Coffee Pancake
Beq Janus Yes. Its the same model, same everything. I just applied a sub division mod to create the top LOD.