Why is there so much high-poly mesh in SL?

[ChinRey]

20 hours ago, Elvina Ewing said:

sighs...

no i am not all that interested in finding answers to how i can optimize my meshes' LoDs after i was just told any LoDs other than the highest don't even matter apparently. I'm just fine with the way it is, thank you.

Fair enough. I won't hold it against you.

Linden Lab should have provided relevant and correct documentation. They didn't.

Linden Lab should have provided adequate tools to monitor and control performance. They didn't. (They are trying to catch up with that now.)

Linden Lab should have made sure their product performs as well as possible considering the resources they have available. They didn't.

Linden Lab should have analyzed a new modelling tool/material from a modeller's/artist's point of view to determine which functions were essential and which weren't. They didn't.

Linden Lab should have analyzed development projects to try to anticipate future implications. They didn't.

Linden Lab should have lead by example, making sure their own official builds (whether they are made by employed/hired builders or bought on the market) are of good quality. They didn't.

This whole mesh mess is made to discourage technical quality and we can't really blame people for going with the flow.

As for searching the forum, yes, most of the information is here. Not all of it, I certainly have a few more tricks up my sleeve and I would expect the other contributors have too. (There are some I details I've nveer thought of posting, some trick I do reserve for myself and my closest friends (there are limits to my altruism too) and some others have shared with me in confidence so I have no right to tell.)

Anyway, I digress. My point is, although the info is here, it's very hard to find. It would be a gigantic task for somebody not already well and truly familiar with the forum to shift through it all and extract the relvant info. It's far more than you can expect from anybody.

But oh well, here is a brief explanation of the problems with automated mesh simplification in general and the uploader's in particular.

To make good LoD models you need to reduce as much as possible without it being noticeable. Remove essential parts and the model looks bad. Keep non-essential ones and you're wasting trianges, increasing the lag.

A computer does not know how your model looks. It doesn't even know what the word "look" means. All it knows, is that there is a long string of zeros and ones and it is told to modify that string according to an algorithm - a formula - created by some mathematicians and programmers long ago. Those mathematicians and programmers do know what "look" mean (hopefully, although sometimes you're bound to wonder). But they do not know how the mesh you are going to make some day in the future is going to look. They have to stipulate. Standardize. Assume. Guess. They can't even include all the factors they do stipulate with because it would be too complex for the computer to handle. So they they have to simplify the simplification algorithm.

The result is that an automatic simplification tool will always start removing details that should have been kept long before it has got rid of all the details that should have been removed. Even the very best simplification algorithms do that, it can't be avoided. I addition, an optimisation algorithm can only use two methods, it can do "vertice decimation" to merge several small triangles into fewer bigger ones or it can do "triangle decimation" to simply delete some triangles here and there. A human brain with a little bit of creativity can come up with several other ways to reduce the triangle count without affecting the look too much.

The algorithm used by the uploader is called GLOD - "Geometric Level Of Detail" - and it has two serious problems. One is that it's more than a little bit outdated, it was back in 2011 even. The other problem is that it's a very crude algorithm, preferring quick-and-dirty triangle decimation rather than less destructive vertice decimation and it has a tendency to hold on to even the minutest details along the edges of the model whilst chopping away big chunks in the middel.

All of this is well known to most regulars in this forum and we've enjoyed a little bit of GLOD bashing every now and then. But there seems there is a reason why GLOD is so poor at its job and it makes perfect for the job it was really made for. Apparently GLOD was an early attempt to make dynamic LoD models for situations where the computer only had a fraction of a second to come up with a new model. There's no time for detailed analyzis in such situations.

To even contemplate using something like that for the uploader is sheer lunacy of course. It's not as if it would matter much if it took a second or two longer for it to generate the LoD models.

Edited October 20, 2018 by ChinRey

[ChinRey]

2 hours ago, Elvina Ewing said:

so have i, but on top of it it is me who's been working in 3ds max for 12 years but neither of you seem to know much about it,

Look for the Optimize and MultiRes Modifiers.

Here's a good introduction:

http://mycreativedaddy.com/how-to-reduce-polygon-count-in-3ds-max-easily/

Edited October 19, 2018 by ChinRey

[Beq Janus]

46 minutes ago, animats said:

Bigger and better preview window in the uploader, so you can see what you're doing. (Beq Janus is putting this in Firestorm now.) This make mesh optimization during upload workable. Right now, you have no clue how well you did until you upload.

This is coming... Though it's a lot more work than I had hoped, mostly beause I need to relayout the controls so that it doesn't look utterly awful.

I will also fix the broken shader in the preview so that we have 3 point lighting and get the degenerate triangles to display in RED so you can see it not in the black that is there at the moment.

57 minutes ago, animats said:

Single-file uploads from Blender, using level info in the file to distinguish levels of detail and physics. (Blender needs to generate a <level> tag in the DAE file for this, which, due to a bug, it doesn't. That's an accepted and assigned request in the Blender bug system now. Once in Blender, the SL uploader needs to recognize it.)

I don't understand this. The mesh uploader supports multi-object scene upload already, I've no idea what a level tag is for though. I uploaded the entire shattered floor of my Fantasy Faire build this year as a single file. It is the only way to get physics models that apply to a multipart mesh. 

1 hour ago, animats said:

Encourage single-file uploads, with all prims of an object and all textures.

The first part works, cluttering it with textures though I am less than convinced about. I think that only works for specific use cases. For me, textures are not part of the same workflow. I get the mesh right then the textures are baked out later. Normally in Quixel or Substance Painter, This is especially true when using materials and texture changers. 

1 hour ago, animats said:

Good medium LODs, generated automatically in the uploader At least a quartic mesh reducer rather than the current dumb decimator. A quartic mesh reducer tries to minimize the volume between the reduced mesh and the original mesh.

A better option to the existing GLOD is desirable, but keep in mind that one of the things that the GLOD solution does and which almost all other "simplifiers" do not do, is maintain UV layout. This is essential and frequently overlooked.

1 hour ago, animats said:

Objects should have a default color, the "1x1" texture. When rezzing, and still in "blob" mode, they should show in that color. That gets rid of grey blobs. Trees start as greenish translucent blobs. Dirt starts out as a brown area. Roads start out as a blackish area. Buildings start out in roughly the right color. Stuff in the distance won't look as bad, especially if a little blur is added during rendering.

The objects would typically appear in their assigned diffuse colour. The problem is that for most objects the base diffuse is white or grey because the texture carries all the diffuse information and to predict that would require you to know what the texture is (chicken and egg)

1 hour ago, animats said:

Texture loading priority needs a better look. The texture system has an elaborate system for loading textures by priority, but the scheme for setting priorities is suboptimal. Fetch the near stuff in the direction the avatar is looking first. Also, texture loading could probably use more bandwidth than it does. Some of the throttling dates from the UDP era when textures came from the sims.

This is too simplistic a view, there have been numerous projects to deal with the fetching and pipelining of textures. In particular to try to get the priority based on the most likely to render. This was designed to help videography and moving cameras, then there are additional demands for things like viewer 360. 

There is lots to do to make things better, and I think your list offers up a good selection of ideas. Better error reporting and feedback in the mesh uploader is my priority at the moment,

[Beq Janus]

4 hours ago, Elvina Ewing said:

no i am not all that interested in finding answers to how i can optimize my meshes' LoDs after i was just told any LoDs other than the highest don't even matter apparently. I'm just fine with the way it is, thank you.

This is most definitely not true, whoever told you that is talking nonsense. There is work ongoing to review the way that LI is calculated so that people who do not provide good clean LOD models will be penalised in terms of the LI.

There is definitely a balancing act between having a good lower (be it medium, low, lowest) that is neither too complex nor too simple. In an ideal world, the LOD models should decay gracefully with respect to the screen space that they occupy on a typical users screen. The primary driver in LOD creation is maintaining volume and silhouette, things look a lot better then. 

Edited October 19, 2018 by Beq Janus
Mis-quoted by silly forum software

[ChinRey]

Post deleted

Edited October 19, 2018 by ChinRey

[Beq Janus]

4 minutes ago, ChinRey said:

Umm Beq, I didn't say that.

? I didn't even think for a second that you did. 

[ChinRey]

Post deleted.

In case anybody wonders, Beq explained in the next post. TUrns out the forum software sometimes attributes quotes to the wrong person

Edited October 19, 2018 by ChinRey

[Beq Janus]

5 minutes ago, ChinRey said:

Can you please correct that quote then?

Fixed sorry about that, the silly forum software doesn't seem to track quotes very well

[animats]

49 minutes ago, Beq Janus said:

I've no idea what a level tag is for though.

Sorry, meant "layer tag". Blender has layers, and the DAE format has a "layer" property for objects. But somehow that didn't get implemented in the Collada exporter. So you can't tell which objects are in which layers from a COLLADA file. I filed a bug report on that for Blender, and that's going into Blender. That would allow the uploader to map layers in one file to levels of detail and physics, instead of needing multiple DAE files. Long lead time item, but started.

[animats]

49 minutes ago, Beq Janus said:

I've no idea what a level tag is for though.

Sorry, meant "layer tag". Blender has layers, and the DAE format has a "layer" property for objects. But somehow that didn't get implemented in Blender's Collada exporter. So you can't tell which objects are in which layers from a COLLADA file. I filed a bug report on that for Blender, and that's going into Blender. That would allow the uploader to map layers in one file to levels of detail and physics, instead of needing multiple DAE files. One more bit of workflow cleanup.

[Beq Janus]

In related news fresh from today's TPV dev meeting:

My Mesh upload changes won't be ready before we release for Animesh (I doubt), it seems Animesh is almost ready to go and my changes are definitely not.

According to Oz, Arctan, the project to re-align LI and complexity is likely to be in the new year now. It will not be until after they release their new more robust and higher performance texture cache. which in turn is not likely to land before EEP, which they hope to get out before year end.

I'm looking forward to the texture cache updates. 

 

[Beq Janus]

8 minutes ago, animats said:

Sorry, meant "layer tag". Blender has layers, and the DAE format has a "layer" property for objects. But somehow that didn't get implemented in the Collada exporter. So you can't tell which objects are in which layers from a COLLADA file. I filed a bug report on that for Blender, and that's going into Blender. That would allow the uploader to map layers in one file to levels of detail and physics, instead of needing multiple DAE files. Long lead time item, but started.

you don't need them, in fact they'd confuse matters today and with the next release of Blender when layers are removed it will not make as much sense either. Also, any changes to the mesh upploader have to work for all toolchains so basing on a specific layout of the file is not going to be acceptable I suspect.

You specify the models using _LOD0, _LOD1 _LOD2 for lowest, low and medium respectively ( but frustratingly not _LOD3 for high) and _PHYS for physics.

That is expressed on the mesh upload page  here 

It is worth noting that as @Drongle McMahon stated in the comment on that post. The naming is for the objects not the files, you can call those whatever you like. This is the only way to get the right components associated with the right lod models and the right physics shapes when uploading a scene. For simpler single model uploads it is just as easy to use the legacy upload where it basically just takes things in order from the files and hopes for the best. (ok not quite but not far wrong in effect)

 

 

[animats]

49 minutes ago, Beq Janus said:

I've no idea what a level tag is for though.

Sorry, meant "layer tag". Blender has layers, and the DAE format has a "layer" property for objects. But somehow that didn't get implemented in Blender's Collada exporter. So you can't tell which objects are in which layers from a COLLADA file. I filed a bug report on that for Blender, and that's going into Blender. That would allow the uploader to map layers in one file to levels of detail and physics, instead of needing multiple DAE files. One more bit of workflow cleanup.

[animats]

19 minutes ago, Beq Janus said:

you don't need them, in fact they'd confuse matters today and with the next release of Blender when layers are removed it will not make as much sense either.

Layers are not going away in Blender. They're being renamed "view layers" and will have names.

Layer attributes are a standard COLLADA feature. It's just that Blender's exporter left them out. It's a bug.

You currently have to export the selections for each file with a separate Export operation, and then import multiple COLLADA files. That should be unnecessary.

[Beq Janus]

3 minutes ago, animats said:

Layers are not going away in Blender. They're being renamed "view layers" and will have names.

My point is that view layers are an arbitrary view they are not something suited to managing objects for export. I would argue instead that collections are a more correct vehicle for this, You would create a collection of high, a collection of medium etc. you are then free to use those on whatever layers you wish. Sometimes I want my windows and doors in one space, my walls and roofs in another, perhaps keep the LOD models together side by side while editing, letting collections do the work of associating groups of assets and letting layers be used for the workspace is probably how I will go with my tools; so I worry that layer tags would force a working method that would break workflows. My tools when I get back to writing Blender tools again are likely to migrate to use collections because this gives more freedom of association without affecting how I work in blender, they do use layers at the moment and that is not ideal (I end up having reserved layers for exporting via my tools, with different layers to control my workspaces and having to remember to make those objects visible in both the right export layer and the editing layer).

Having everything in one file is also of limited interest to me. I can certainly see where it may be desirable, but personally, I prefer to manage the files individually and have Blender output them all in one go when I ask it to giving it a root name for the scene/model and get it to generate the right sets of files. The main reason for this is that it makes it a lot easier then, to import it into other tools that will not understand multiple  LOD models in the same file. I certainly don't want texture in the model data as I rarely if ever texture in Blender, much as I love Blender there are far better tools for that. 

I think what we are showing quite well here is that while we all agree that the workflow is cumbersome, there is no simple solution. A blender user working on a single mesh object, textured in Blender, has a different set of needs to someone starting in Zbrush, moving through Maya or Blender and then on to Substance Painter or Quixel before combining all the artefacts in-world. If you are working with a scripter or animator, you are likely to release the mesh before you get to the textures (you may not even be texturing). Getting a single set of options that everyone is happy with is far from simple.

[animats]

Yes. Janus and Rey are writing from the perspective of people who generate large amounts of content. They can usefully use a more elaborate workflow than those who only generate a small number of items. I'm looking at this from the point of view of the occasional user. It's bad enough that they have to use Blender. The least we can do is have a simple workflow for the people who read the "Become a Creator" page on the Second Life site and wanted to try it.

[Kyrah Abattoir]

Lately for lod reduction i've been favouring a "hybrid" method of using blender's decimation combined with manual "hinting".

Essentially I'll set a decimate modifier (for each lod that is) and I'll look at what it's getting "wrong" (typically, getting attached to an unimportant detail). I'll then remove those details and see what its response is. And i'll keep doing this until i've reached an acceptable result (triangle and aspect wise).

It doesn't beat doing it 100% manually obviously, but I can get too attached to my own models sometimes and not realize how I can reduce them further for the lower lods. This hybrid approach solves that issue.

 

Also can I say that I intensely dislike the attitude some people can have when they aren't literally spoonfed a solution? The whole "Well If you want me to do my work better, you're gonna have to make me!" deal.

Hopefully the arctan project IS going to force people to "adapt".

Edited October 20, 2018 by Kyrah Abattoir

[Chic Aeon]

New "hobbiest" users DO have a choice and certainly the ability to make low poly mesh in SL using OMG FREE Blender. 

That WAS the whole point of the tutorial series I made and that have been very well received -- and hopefully taken to heart by a few folks. 

Making mesh for SL doesn't need to be complicated; creators just need to pay attention. 

 

Unhappily I have to say that in many many cases this problem has moved over to Sansar where folks are "encouraged" to download free mesh (often made for renders not assets). I went to an experience last night with some gigantic (but pretty) buildings that wasn't working well and using the DIAGNOSTIC TOOLS (available in the viewer) it was easy to see the problem. I let the new person know that their site was running at two-thirds what it needed to be for VR (worked fine in desktop but Sansar "is" (for now anyway) a VR platform).  I gave links to the diagnostic info and hopefully they will work it out.

 

Sadly I have to say that some of our top creators are making heavier mesh than they ever. I can only assume it is the "it must be super pretty and super clear" syndrome which I do understand. Personally I am happy that we are limited at least to 1024 textures and not the 4096 in Sansar. To be fair, those WORK in Sansar because it is a much more powerful engine, but only if used sparingly and with forethought. 

 

So no matter what the platform when there is user generated creations, there is going to be this problem. Either folks don't understand or they don't care.  Firestorm has given us diagnostics in some sense and that is great, but people have to USE them.   

 

The best we can do is try and pass along the info for the few that DO care and DO pay attention. 

[Klytyna]

13 hours ago, Elvina Ewing said:

it is me who's been working in 3ds max for 12 years but neither of you seem to know much about it

I used Max 4 a very long time ago... but I hated the bloody UI, so I stopped using Max 4 and got a copy of Cinema 4D, which I found I preferred, that was MORE than 14 years ago...

Should I assume that because I use an app you don't, and have done for more years than you've used Max, that you are talking out of your ass?

 

[Elvina Ewing]

13 hours ago, Beq Janus said:

This is most definitely not true, whoever told you that is talking nonsense. There is work ongoing to review the way that LI is calculated so that people who do not provide good clean LOD models will be penalised in terms of the LI.

There is definitely a balancing act between having a good lower (be it medium, low, lowest) that is neither too complex nor too simple. In an ideal world, the LOD models should decay gracefully with respect to the screen space that they occupy on a typical users screen. The primary driver in LOD creation is maintaining volume and silhouette, things look a lot better then. 

huh?? ChinRey were extensively explaining the triple LoD bug on fitted mesh and she wrote earlier in this thread that because of these LoD bugs lower LoDs rarely get used at all. See page 2 of this thread. So, are you telling me it is NOT true?? Guys you are confusing me very much now. I repeat, i only make fitted mesh and this is what we were talking about. Optimizing fitted mesh.

3 hours ago, Klytyna said:

I used Max 4 a very long time ago... but I hated the bloody UI, so I stopped using Max 4 and got a copy of Cinema 4D, which I found I preferred, that was MORE than 14 years ago...

Should I assume that because I use an app you don't, and have done for more years than you've used Max, that you are talking out of your ass?

 

yes you definitely should, if i am talking about the app you use and i never have. Like, if i would be talking about Blender. However, i wasn't, but i was talking about 3ds max, the app i have more experience in using, apparently.

Edited October 20, 2018 by Elvina Ewing

[Kyrah Abattoir]

Said LOD bug is in the process of being fixed. That and the various ways to exploit the complexity calculation algorythm.

It's sad that some people only understand the stick.

Edited October 20, 2018 by Kyrah Abattoir

[Fionalein]

29 minutes ago, Kyrah Abattoir said:

It's sad that some people only understand the stick.

I already said in another thread that fixing this will break so much content that people will start voting with their feet... I do not believe the lab will do that dumb move until I see it.

But if they do at least our Miss Self Rightous " At least I didn't cheat" will have a short moment of triumph before the Lab switches of the light the then barren waste. ...

Edited October 20, 2018 by Fionalein

[ChinRey]

9 hours ago, Kyrah Abattoir said:

Lately for lod reduction i've been favouring a "hybrid" method of using blender's decimation combined with manual "hinting".

That's what I mean by manual optimization. Start with an auto-generated model and then tweak the result as much as you fell i neccessary and time allows.  I've found the limited dissolve tool to be more useful than the decimate modifier but the principle is the same.

I've heard of people who do it the other way round. They make the simplest LoD model first and then they add more details for the others. If you can do it that way, the manual LoD model may not take any time at all since it's probably how you would have made the model anyway. It only works if you have a very clear idea of the end result before you even start though. I'm a jazz musician so improviastion is second nature to me. Sometimes what I end up with isn't even the same kind of object. I can start making an ornate pillar for a doorway and end up with a vase instead. That 2 LI tree I showed a pic of is a good example actually. I never intended it to be a tree but it insisted.

 

3 hours ago, Elvina Ewing said:

huh?? ChinRey were extensively explaining the triple LoD bug on fitted mesh and she wrote earlier in this thread that because of these LoD bugs lower LoDs rarely get used at all. See page 2 of this thread. So, are you telling me it is NOT true??

No, Beq was explaining how it's supposed to be, I was explaining how it actually is (as she has explained in an earlier thread). The difference between the two is the bug.

There is a chance the bug will be fixed some day. If/when that happens, fitmesh makers will have serious problems unless they have prepared for it and made sure their meshes work well even without it.

What you do is your choice.

Edited October 20, 2018 by ChinRey

[ChinRey]

3 hours ago, Fionalein said:

I do not believe the lab will do that dumb move until I see it.

They are working on a fix, we know that, and it's not a dumb move. You can call it desperate if you like but it is a neccessary one. The cure may hurt badly but it only hurts once. Not fixing it will cripple SL's performance forever.

But "fix" is a relative term. You can stitch stuff together with a few bits of duct tape, you can go down and do a thorough repair job or you can ditch the whole thing and replace it with something new.

Those are the three basic ways the fitmesh LoD bug can be fixed (or "fixed"). There is also a combination of two of them (and of course several variants of each):

1. Ditch and replace: Develop a brand new automated LoD system for fitted mesh. Negative consequenes:
   • It's a huge project that would cost a fortune and/or take a tremendous lot of time.
2. Duct tape: Change the weight formulas so they reflect the actual render weight of fitted mesh. Negative consequences:
   • It doesn't actually solve the lag problem, it just brings it up to the surface.
   • The ARC of mesh avatars will skyrocket. A mesh avatar that shows up with a healthy 50,000-80,000 render complexity today may well end at several millions if the number was to show the actual render cost.
3. Thorough repair: Base the LoD swap distances for fitted mesh on their actual size or - probably better - their uploaded size. Negative consequences:
   • Practically all existing fitted mesh will be broken and will have to be replaced.
   • Replacement won't be available right away since fitmesh makers will have to learn how to make LoD models first and then they have to actually make it. (This problem can be minimized if LL gives us a warning well in advance but if the fix is going to be a part of project Arctan we should already have ahd that warning by now.)
   • Something will have to be done about the RenderVOlumeLODFactor problem too because there are bound to be fitmesh makers who keep buiding the old way and tell people they jsut have to crank their LoD factor up to a thousand.
4. The mix: Make s system with two different types of fitted mesh. New fitted mesh is handled the "thorough repair" way, existing "heritage" fitted mesh is handled the "duct tape" way. This the solution that would have the least negative cinsequences but:
   • It's still more complex than option 3 and a lot more complex than option 2.
   • Even though heritage fitmesh will still work, the ARC increase they cause, will make it useless in many situations and it crtainly won't be sellable for long.
   • Fitmesh makers will still have to learn how to make new styl fitted mesh and then produce it.
   • There will still be makers who insist that cranking up the Lod factor is the solution to all problems in SL and that it has no negative effect whatsoever.

There is one variant of the duct tape method that is worth a special mention: tweak the weight formula to insrease the numbers for fitted mesh a little bit - not enough to make any difference worth mentioning but enough you can claim you are doing something. I don't think LL is going for that non-solution; maybe if this had been 2013 but it's 2018 now. I know for a fact that they are at least seriously considering the more complex options first.

 

4 hours ago, Fionalein said:

But if they do at least our Miss Self Rightous " At least I didn't cheat" will have a short moment of triumph before the Lab switches of the light the then barren waste. ...

If Second Life had been that fragile, it would have collapsed ten years ago. The people who tells us that SL will end tomorrow are often right from any reasonable and logical point of view. But SL keeps going on anyway, defying all reason and logic. In that sense at least it is truly an alternative reality.

[Klytyna]

12 minutes ago, ChinRey said:

If Second Life had been that fragile, it would have collapsed ten years ago. The people who tells us that SL will end tomorrow are often right from any reasonable and logical point of view.

There is a significant difference between telling people that their system layers are unfashionable, or that flexi prim hair is unfashionable, and telling people that 95% of the boobs, butts, hands, feet, hair, bodies, heads, clothes, shoes & boots, jewelery, naughty bits, etc., that they have purchased over the last half decade are "many millions of arc and OUTLAWED!".

Four years ago when Project Stupid was announced, and touted briefly as SL-2, the fact that there would be no content transfer, and that content makers would "have to redo their entire store over from scratch for SL-2" was enough to drive a lot off the grid, as they didn't want to start over.

17 minutes ago, ChinRey said:

Duct tape: Change the weight formulas so they reflect the actual render weight of fitted mesh. Negative consequences:

... Self Important amateur Render Police Vigillantes running around screaming about "resource hogs "destroying SL" while initiating pogroms against anyone not wearing brand new 2020 edition "Arc Bigot Approved" mesh?

20 minutes ago, ChinRey said:

Thorough repair: Base the LoD swap distances for fitted mesh on their actual size or - probably better - their uploaded size. Negative consequences:

... Rigged/Fitted mesh hairs will behave like unrigged mesh hairs, that is, vanish at relatively short distances unless linked to fugging huge alpha blend textured invisible prim cube root objects to dodge the LoD systems failings...

... Causing virtually all worn mesh to degenerate into a mess of twisted triangles at comparatively short ranges causing new user retention to plummet even lower than it already is because "wow da grafix are crap, dis game r so suk, i r leevin"...

24 minutes ago, ChinRey said:

Ditch and replace: Develop a brand new automated LoD system for fitted mesh. Negative consequenes:

• It's a huge project that would cost a fortune and/or take a tremendous lot of time.

... On the upside, such a cost would force LL to abandon Project Stupid to save money to pay to save SL to save LL...

27 minutes ago, ChinRey said:

But SL keeps going on anyway, defying all reason and logic. 

There are limits, even to SL, telling a very large percentage of the population that almost every mesh based avatar construction item they have bought in the last 5 years is OUTLAWED, could well be one of them...

...

Realistically, the "cures" are WORSE than the disease, and time would be better spent finding ways to improve the systems ability to render what we have, rather than wishing that it had all been made differently years ago and too far back and too common, to reasonably change at this point.