Why beginners don't learn the basics first?

[OptimoMaximo]

1 hour ago, OptimoMaximo said:

A normal map blue channel is always filled with white, as the tangent z axis of a vertex or face should never be bent and the bumping effect is given by distorting the pixels' x and y tangents

Can't edit the previous post with my own quote. 

[OptimoMaximo]

1 hour ago, Kurshie Muromachi said:

But don't you have to account for objects close to one another that are from separate creators?

Object to object occlusion can be achieved changing the settings and basically screening out surfaces that are closer than a certain distance from one another, which makes the calculations needed more affordable. I actually never tried it in SL, but usually in 3d applications and engines, one can set this threshold distance and the higher it is, the less expensive it becomes. 

Edit: on a second thought, I'd rather just use the realtime shadows and leave that object to object occlusion effect to that. Or the baked AO map for a specific model could include a tinting option to darken the AO texture for such cases or if it is mofiable add the AO shading to it to account for the other near object

Edited December 23, 2019 by OptimoMaximo
Mistypes

[OptimoMaximo]

Or better yet, a server side baked light map... I'm flying with dreams now, though 😂

[Kyrah Abattoir]

I ended up with a really nice & aggressive example of normal map magic the other day, I don't think it's worth a dedicated topic but i thought this might interest some people.

Normal mapping on:

Normal mapping off:

[Wulfie Reanimator]

1 hour ago, Kyrah Abattoir said:

I ended up with a really nice & aggressive example of normal map magic the other day, I don't think it's worth a dedicated topic but i thought this might interest some people.

I'm aware that the illusion beaks a little bit if the object was in motion (as in, we were able to inspect the model by orbiting the camera), but the forums need an "amaze" reaction.

Edited December 24, 2019 by Wulfie Reanimator

[Kyrah Abattoir]

It's a very specific case I suppose but because of the restricted view angle on the frills, the illusion is quite persistent.

[OptimoMaximo]

59 minutes ago, Kyrah Abattoir said:

It's a very specific case I suppose but because of the restricted view angle on the frills, the illusion is quite persistent

Plus the rest of the texturing will contribute to cover up most if not all of the illusion breaking cases

Edited December 24, 2019 by OptimoMaximo

[Cackle Amore]

On 12/23/2019 at 5:08 PM, Kyrah Abattoir said:

I ended up with a really nice & aggressive example of normal map magic the other day, I don't think it's worth a dedicated topic but i thought this might interest some people.

Normal mapping on:

Normal mapping off:

[Kyrah Abattoir]

I'm not going to name and shame since it's against the forum rules, but here is an interesting example of WHY ARE YOU DOING THIS?

This environement mesh was presented at a store I was in, and I think showcases the problems I've seen in pretty much all the products they showcased:

This does NOT include the mailbox, the statue or the bollards, these were separate objects, I'm only inspecting the road & wall section.

• Texture count: 12, 1024x1024, uses materials, 50mb of non-reuseable textures.
• The two pieces of road are separate mesh sections, but rather than having two (or even one with a tint) reuseable road textures, they are baked.
• Likewise, the bricks could be a simple repeating pattern, but it's baked too.

The sad part is that it's all fairly blurry in the end since there is only so much detail you can get out of a baked texture anyway.

Somehow, when we moved from prims to sculpts and then from sculpts to mesh, there is a huge chunk of skill and optimization techniques that simply disappeared from the talent pool, and now this is what's filling the gap.

Edited January 26, 2020 by Kyrah Abattoir

[Wulfie Reanimator]

10 minutes ago, Kyrah Abattoir said:

Somehow, when we moved from prims to sculpts and then from sculpts to mesh, there is a huge chunk of skill and optimization techniques that simply disappeared from the talent pool, and now this is what's filling the gap.

I believe this is because "proper mesh" is way more accessible than sculpt maps. The art of prims was pretty elusive as well...

[ChinRey]

On 1/26/2020 at 5:18 PM, Kyrah Abattoir said:

I'm not going to name and shame since it's against the forum rules, but here is an interesting example of WHY ARE YOU DOING THIS?

I'm not doing this.

But there's one thing we have to remember.

Here's a set of perfectly optimized poplar trees. The whole set is just 148 triangles and two reuseable 512x512 textures. All LoD models are 88 tris and there is no noticeable reduction of quality even with LoD factor 1.0 and the land impact is 2.

If all content in SL had been made this way, we could have far richer and more varied landscapes with only a fraction of the lag a typical SL scene causes.

Unfortunately that's not possible. It's easy to say the content creators should learn the craft and blame it all on them. But I've spent thousands of hours studying, experimenting and discussing with other creators. And I'm a fast learner.

We can't really expect the average hobbyist to put that much time and effort into it and as for the commercial operators, they have to consider their bottom line. I have the optimization process farily streamlined by now but making something like this and listing it for sale on MP and inworld is easily more than a day's worth of work even for me. For somebody less experienced, it may well take a week. If I actually end up offering this group for sale, I'll be lucky if I end up making ten dollars from it.

The bottom line is that if you want to make a living as an SL content creator, you simply can't afford to make optimized content and if you have an RL job, you probably don't have enough time. That's not the content creators' fault.

Edited February 3, 2020 by ChinRey

[Tonk Tomcat]

Quote

The bottom line is that if you want to make a living as an SL content creator, you simply can't afford to make optimized content and if you have an RL job

I don't think that's the way we should see that, because that highpoly unoptimized mesh stuff that's all arround in sl and that 95% of all "creators" create just does not belong into any game nor into sl. SL is an old plattform, you can't even compare to an actual game (polycount-wise), more to maybe an actual mobile game. If you want to make a living with sl, you should be forced to optimize the stuff (because you want to be professional then - everybody else should be forced also, of course). I'm doing this since 14 years, and i'm still here. So it is possible. And it would be even more possible if everybody would be forced to spend the time to do so, because then you wouldn't have to compete to all that stuff that should never exist in here.

There is not a single game, nor any plattform, where you can upload crap like in sl. You will never see a single sixpack of beer with 1.3 million polygones. Only in sl. Because - i don't know why - Linden Lab just forgot to add a polygon limit into the uploader, and all the ppl go the easy way and upload what they have, because they can.

Every hobby amateuer cg artist creats low poly game ready mesh (you can check out a lot of them on artstation). Many of them create that just for fun, or for their portfolio in their freetime. So ppl have to learn that this is neccessary and they will learn that it takes time to create 3D content. Thats just the reality that didn't reach sl till now.

Edited February 3, 2020 by Tonk Tomcat

[ChinRey]

8 hours ago, Tonk Tomcat said:

I don't think that's the way we should see that, because that highpoly unoptimized mesh stuff that's all arround in sl and that 95% of all "creators" create just does not belong into any game nor into sl.

I agree with what you say and I've said similar things myself countless times. But my point is that it's too easy to just blame it on the content creators. Yes, there are a few rather shady ones but most of the builders I know of are actually doing their best.

[animats]

The tooling fights you if you try to do it right. The way this should work is that you make a high-poly model to look at, then mesh-reduce it using baked normals from the original. Repeat for each LOD. Create a very low poly impostor for the lowest LOD. Create mesh and texture files together, then upload all at once.

Try to do that for Second Life and you end up fighting the uploader over the "textures must be the same at all LODs" limitation, the "uploading a linkset produces random link order" bug, the "texture upload with mesh doesn't seem to work" bug, the "LODs get resized and recentered" misfeature, the "can't put multiple LODs  in one file" limitation, and the "physics model convex decomposer does dumb decompositions" problem.

(What do Optimo Maximo's tools for Maya do? He's tried to deal with some of this. Is there something to read on that?)

[OptimoMaximo]

7 hours ago, animats said:

What do Optimo Maximo's tools for Maya do? He's tried to deal with some of this. Is there something to read on that?)

Yeah I did what was possible to automate considering all the uploader issues you already mentioned. There is one more, which is that if your rigged mesh LoDs do not have the same exact list of joints as the high level, vertices go out flickering in their position, making the mesh sort of shaking. That's the primary thing that my autoLod script addresses, regardless whether LoDs have enough vertices to hold the weights (as opposed to Maya default that tries to optimize it by removing joints from the list if they don't have room to be accommodated onto a vertex). Also, while doing this for each LoD model, it reduces the triangle count precisely using a factor decimation, which is easier to account for the end user, based on the item's triangle count that is automatically detected (instead of needing a manual input from the user), renames the item accordingly and separates them into visibility layers named after the lod level, like lod1, lod2, etc, for convenience of, well, visibility and selection. It also allows to do the same procedure on custom models, ensuring weight and joint lists matching and name convention preservation, along with the visibility layer assignment after a prompt that asks what LoD this model represents. Even though it works great, each lod has to be exported separately because the uploader won't work it out in a single file. Moreover, the uploader will always assign a high LI and L$ cost because of the lowest lod triangle count. Since this tool is aimed to rigged content, impostors can't be used. In my tests, I did a huge monster avatar and made the LoDs following the animesh standards to avoid the extra triangles surcharges, meaning each lod was half the triangle count of the previous level. Rezzed on ground, it's around 650 LI, turned into animesh it scores 130. For its size (over 3 meters height and around 6 meters from nose to tail) its complexity isn't even that high when worn, surely less than a tiny by comparison human avatar made with one of the commercial bodies. In all cases, rezzed, worn and animesh, there is no visible lod transition happening when camming out. The problem of people wanting everything 1LI though renders the tool close to useless in their eyes, even if the model is actually optimized as heck for what it is (all depends from the starting model of course). 

You're not wrong stating that an impostor generator would be great, indeed houdini just does that also generating a texture for it. The problem though is that this method can't be really applied to everything (rigged meshes) and can't be realistically added to the uploader because of this. Rigged meshes can't get away with textured planes too well, perhaps in some occasions, because of their deforming nature. All the rest of the content would, instead, enormously benefit from that. 

Edited February 4, 2020 by OptimoMaximo

[animats]

Thanks. That's helpful. Optimo is working on the hardest problem - rigged mesh. What are you using for mesh reduction? Something in Maya?

The two big players in mesh reduction seem to be InstaLOD and Simplygon. Here's an InstaLOD demo video:

SL needs something like this. No, not the monster, the mesh reduction tool. The example in the video has 1.4 million tris before reduction, about 10,000 after, and it looks the same. That's the "High" LOD. The lower LODs are simpler. The original art has huge triangle counts; the creator didn't have to worry about that. Reduction happens downstream, with semi-automatic tools. You can go back and change the original, then rerun the reduction process.

I'm not promoting this; it's just to give a sense of what's possible with current technology.

Edited February 4, 2020 by animats
Expand data

[ChinRey]

17 hours ago, animats said:

The tooling fights you if you try to do it right. The way this should work is that you make a high-poly model to look at, then mesh-reduce it using baked normals from the original. Repeat for each LOD. Create a very low poly impostor for the lowest LOD. Create mesh and texture files together, then upload all at once.

Try to do that for Second Life and you end up fighting the uploader over the "textures must be the same at all LODs" limitation.

It's easy enough to work around and you only need three placeholder triangles for each LoD model. But Second Life is not a game and solutions that are good for games are not necessarily good for SL.

Unlike their successors, the original LL crew was very concsious about lag and their priorities to reduce it were clear:

1.  Bandwidth
2. Textures
3. Geometry

That's the opposite of what you usually want for a game but it makes sense for SL. Bandwidth first because the cpu is often too busy downlaoding content to serve the gpu effectively, textures before geometry because texture overload is by far the most common problem the cpu has to handle. Substituting textures for geometry is a very good and common lag reduction technique for games but in SL it's a high risk strategy and very likely to backfire.

[Wulfie Reanimator]

1 hour ago, ChinRey said:

It's easy enough to work around and you only need three placeholder triangles for each LoD model. But Second Life is not a game and solutions that are good for games are not necessarily good for SL.

Unlike their successors, the original LL crew was very concsious about lag and their priorities to reduce it were clear:

1.  Bandwidth
2. Textures
3. Geometry

That's the opposite of what you usually want for a game but it makes sense for SL. Bandwidth first because the cpu is often too busy downlaoding content to serve the gpu effectively, textures before geometry because texture overload is by far the most common problem the cpu has to handle. Substituting textures for geometry is a very good and common lag reduction technique for games but in SL it's a high risk strategy and very likely to backfire.

I strongly and respectfully disagree.

• Obviously the first thing is that Second Life is a game as far as any sort of tech talk is considered, there's no way around that regardless of your beliefs of the platform in general.
• For online games, bandwidth is the #1 priority over anything else. It doesn't matter how good the game looks if you're rubber-banding, stuck running in place, or dying in safety because you weren't safe on someone else's screen. Players will get upset over ping before anything else. In SL, interaction isn't very time-critical and that has been normalized over its entire existence.
• Textures are a big performance cost in real-time rendering in general. Not just loading them into memory, but drawing them from memory onto the screen as well. I don't think there's anything special about how LL has "optimized" textures, besides using a weird format that allows for "texture LODs" while bloating the total download size. I think @NiranV Dean has talked about that in the past.
• The way creators use textures isn't anything resembling performance-concerned development. I don't think I need to bang the drum about 1024sq textures, but generally speaking you should treat textures just like geometry. "Average pixel density" per area should be a goal just like for triangles. The problem is of course that there is no quality control or an enforceable standard.
• Triangles are relatively cheap. The difference between SL and other games is that SL scenes tend to be fairly static. As in, new objects/resources being created is fairly low. There are exceptions, like sandboxes or combat sims, but your average mall/club/hangout area tends to stay the same. That's why most games need to optimize more heavily -- to account for more things appearing into the world.
  • The main exception is avatars, which are by far the worst offenders in terms of performance. They're like walking bombs, ready to destroy your framerate with all the excess everything.
  • In games, even avatars are created with resource budgets in mind. There's some upper limit of characters that will be in a scene and all of them have to work for that limit.
  • In SL, that limit basically doesn't exist. You can have up to (38 * 256 * 174752) triangles attached to your avatar. That's a "limit" of over a billion. Per avatar. More realistically I have seen multiple avatars in the same location with over a million visible tris, never mind all the other avatars and the world itself.

TLDR: If people would develop content for SL exactly as a game developer would, we would see a significant positive change.

5 hours ago, animats said:

SL needs something like this.

That's neat.

[Tonk Tomcat]

There is no one click and all is reduced program. Creating good mesh is actual work, so ppl have to learn that there is a step called "retopologize" in the workflow. Yes, that takes a ton of time and yes, it is neccessary to do. Rebuild the damn mesh by hand using the retopo tools of the software you have. It's in blender (Retopo in Blender 2.8), it's in maya (Retopo in Maya), or you can use external tools that are made just for the purpose of retopo (Retopo with TopoGun).

 

 

 

[Wulfie Reanimator]

44 minutes ago, Tonk Tomcat said:

There is no one click and all is reduced program. Creating good mesh is actual work, so ppl have to learn that there is a step called "retopologize" in the workflow. Yes, that takes a ton of time and yes, it is neccessary to do. Rebuild the damn mesh by hand using the retopo tools of the software you have. It's in blender (Retopo in Blender 2.8), it's in maya (Retopo in Maya), or you can use external tools that are made just for the purpose of retopo (Retopo with TopoGun).

While I agree that you're more likely to get the "best" result by hand (and I've even made threads demonstrating how easy it is), it's not inherently bad to use a "magic button that does it all." From the video above, you can see that the plugin produces very clean topology for hard-surface models (the gun), but organic shapes (the skull/helmet) are handled very poorly if (and only if) the goal would be to rig it. It's very much about context and trade-offs.

As you know, time spent is an important factor when working to a professional capacity. If you can just press a button to get a clean model in 5 minutes instead of spending 20-60 minutes on it, why wouldn't you do it? Same applies for all areas of the entire workflow. Not doing everything by hand doesn't reduce the value of the final product.

Edited February 5, 2020 by Wulfie Reanimator

[ChinRey]

3 hours ago, Wulfie Reanimator said:

I strongly and respectfully disagree.

If what you're saying is that there are other games that need the same priorities as SL to keep lag down, I'm quite happy to agree with you. I was thining of mentioning it myself but decided not to to keep it simple. We can discuss the differences between SL and the "generic game engine", there are quite a lot of them, and yes, some of them are certainly appropriate for other games/virtual environments too. But that's a it off topic right now. My point here was, as you also said, that textures are generally a more important cause of lag in SL than geometry. That means baking to save triangles as animats suggested (and as recommended by countless YT videos and such) is far more likely to increase rather than reduce the lag.

 

 

[NiranV Dean]

4 hours ago, Wulfie Reanimator said:

I strongly and respectfully disagree.

• Obviously the first thing is that Second Life is a game as far as any sort of tech talk is considered, there's no way around that regardless of your beliefs of the platform in general.
• For online games, bandwidth is the #1 priority over anything else. It doesn't matter how good the game looks if you're rubber-banding, stuck running in place, or dying in safety because you weren't safe on someone else's screen. Players will get upset over ping before anything else. In SL, interaction isn't very time-critical and that has been normalized over its entire existence.
• Textures are a big performance cost in real-time rendering in general. Not just loading them into memory, but drawing them from memory onto the screen as well. I don't think there's anything special about how LL has "optimized" textures, besides using a weird format that allows for "texture LODs" while bloating the total download size. I think @NiranV Dean has talked about that in the past.
• The way creators use textures isn't anything resembling performance-concerned development. I don't think I need to bang the drum about 1024sq textures, but generally speaking you should treat textures just like geometry. "Average pixel density" per area should be a goal just like for triangles. The problem is of course that there is no quality control or an enforceable standard.
• Triangles are relatively cheap. The difference between SL and other games is that SL scenes tend to be fairly static. As in, new objects/resources being created is fairly low. There are exceptions, like sandboxes or combat sims, but your average mall/club/hangout area tends to stay the same. That's why most games need to optimize more heavily -- to account for more things appearing into the world.
  • The main exception is avatars, which are by far the worst offenders in terms of performance. They're like walking bombs, ready to destroy your framerate with all the excess everything.
  • In games, even avatars are created with resource budgets in mind. There's some upper limit of characters that will be in a scene and all of them have to work for that limit.
  • In SL, that limit basically doesn't exist. You can have up to (38 * 256 * 174752) triangles attached to your avatar. That's a "limit" of over a billion. Per avatar. More realistically I have seen multiple avatars in the same location with over a million visible tris, never mind all the other avatars and the world itself.

Textures are relatively cheap to render once they are downloaded and decoded and pushed into GPU memory. It's hard to measure how much exactly as more textures automatically mean more everything else in a scene since a texture needs a surface and a surface in turn is something that needs to be rendered and has an impact too, its hard to determine how much textures really weight but i'd say for any GPU of the past 10 years it should be a no brainer, given it can stockpile all of them.

Triangles ARE cheap but don't be fooled. This is THE number one excuse for people spamming them "triangles weight nothing". Just because SL handles 20 million polygons per scene on average (that is a lot, a lot more than games often have per scene at any given time) doesn't mean we should throw them around like they are nothing because they infact weight a lot very quickly. Not only am i not sure whether polygons are fully calculated on the GPU (which i doubt they are) they also get calculated multiple times and run through several hoops. A mesh needs to be rendered once, if its rigged it also needs to be deformed which is additional performance impact (not nearly as much as rendering it twice but it adds up quickly) and if you use shadows you'll also see the same mesh being rendered again to be included in a shadow map, this can happen up to 6 additional times depending on how the sun angle is, and whether you also have projectors looking at the mesh in question. Say you have a very low angle and the shadow of your mesh is cast across the horizon you'll see your mesh getting rendered 4 additional times because its in every shadow map. Now lets take a 1 million polygon avatar, waste one million calculations to get the mesh and some extra to calculate how it is deformed, now rerender this mesh into 4 shadow maps and suddenly we're looking at 5 million polyon impact. This is a very simplified example but it should give you an idea how this works. Especially for Deferred Rendering (ALM) you should think about optimizing your stuff, most things you think are calculated on the GPU are actually calculated on the CPU and we have a very limited CPU budged, shadows btw are mostly rendered on the CPU the final shadow maps are just being transformed and applied into the scene on the GPU. I frequently see human avatars with 1 million polygons and more and i get IMs very frequently asking why people are being jellydolled despite them setting the complexity limit to 800.000 in my Viewer (this can only mean they are very close or beyond a million polygons). Belleza body alone has 500.000 polygons, Maitreya has 200.000 and both of them don't even include hands, feet, head and hair that post people wear, not to mention clothing which is based on these bodies thus they inherit the high polygon number unless someone would redo the clothes from scratch and optimize them (which no one honestly does).

[OptimoMaximo]

12 hours ago, animats said:

What are you using for mesh reduction? Something in Maya?

I'm using the polyReduce tool in Maya, passing it both optimal reduction method of the three available and the target triangle counts, calculated as division factors from the detected triangle count of the original model. This ensures that each lod generated model is exactly the number of requested triangles from the original model, give or take a couple of triangles sometimes. All the hard-coded settings are aimed at preserving shape, uv layout and material borders, with a further optional preservation marking method to save key edges from the reduction, so that shape preservation is enhanced from its default. Maya does an excellent job at it and the lod models keep being suitable for Rigging and deformation, well, within limits of course. 

I have tried instalod for myself, and I have to say that if it works great for hard surface models, when it comes to organic models its topology is definitely clean, yet not optimal and needs to be reworked quite a bit for deformation-critical areas, if it did not create the occasional spiraling, when trying to preserve quads. At that point I don't see a greater benefit in using it if I get an equally decent result using Maya's native polyreduce tool. Of course it can be beneficial to add it to another software to aid the work flow not cluttering the original scenes with lod models. But I would not use it on complex characters, with builtin clothing and accessories as it is done in games. For "naked" characters like the monster in the video it would be totally fine. 

Anyway, manual retopo keeps being king. In the last 3 Maya iterations, from 2017 to 2020, a new couple of tools have been developed, polyRemesh and polyRetopo. The first is great and fixes surface errors on scanned models, retriangulating it in a clean fashion. The latter though suffers of the same exact problems instalod does: great for hard surface, meh for organic, plus it needs an extra manual step to transfer UVs over from the original model as the new surface does not get uv preserved (no biggie though). I still have to push all the possible settings though, so I may come across a combination that does a good job in the widest range of occasions, so I may have to come back on my steps an rectify my statements. 

[Wulfie Reanimator]

6 hours ago, ChinRey said:

If what you're saying is that there are other games that need the same priorities as SL to keep lag down, I'm quite happy to agree with you. I was thining of mentioning it myself but decided not to to keep it simple. We can discuss the differences between SL and the "generic game engine", there are quite a lot of them, and yes, some of them are certainly appropriate for other games/virtual environments too. But that's a it off topic right now. My point here was, as you also said, that textures are generally a more important cause of lag in SL than geometry. That means baking to save triangles as animats suggested (and as recommended by countless YT videos and such) is far more likely to increase rather than reduce the lag.

I might agree on account of SL not having very complex shaders that could be used in other games to get even more detail onto the screen from textures alone. Parallax mapping and cel shading especially come to mind, but any custom shader (for pixel, vertex, or geometry) would be great. I still disagree with the argument that using textures for detail would cause more lag. Only if the textures are many or unnecessarily large and the detail isn't substantial.

6 hours ago, NiranV Dean said:

Triangles ARE cheap but don't be fooled. This is THE number one excuse for people spamming them "triangles weight nothing". Just because SL handles 20 million polygons per scene on average (that is a lot, a lot more than games often have per scene at any given time) doesn't mean we should throw them around like they are nothing because they infact weight a lot very quickly.

Don't worry, that's not what I'm saying. I'm currently studying and writing my own (basic) renderers in C so I have a particularly good grasp on the concept that "nothing is free."

6 hours ago, NiranV Dean said:

Not only am i not sure whether polygons are fully calculated on the GPU (which i doubt they are) they also get calculated multiple times and run through several hoops. A mesh needs to be rendered once, if its rigged it also needs to be deformed which is additional performance impact (not nearly as much as rendering it twice but it adds up quickly) and if you use shadows you'll also see the same mesh being rendered again to be included in a shadow map, this can happen up to 6 additional times depending on how the sun angle is, and whether you also have projectors looking at the mesh in question.

Generally speaking you should be able to cache those calculations so that you don't have to literally go over the whole mesh all over again, especially the "relevant" faces so you wouldn't even check the shadow-side of an avatar for example, so the subsequent passes over the same mesh/object should be significantly cheaper. I don't know if viewers do this, though.

[Tonk Tomcat]

7 hours ago, Wulfie Reanimator said:

While I agree that you're more likely to get the "best" result by hand (and I've even made threads demonstrating how easy it is), it's not inherently bad to use a "magic button that does it all." From the video above, you can see that the plugin produces very clean topology for hard-surface models (the gun), but organic shapes (the skull/helmet) are handled very poorly if (and only if) the goal would be to rig it. It's very much about context and trade-offs.

As you know, time spent is an important factor when working to a professional capacity. If you can just press a button to get a clean model in 5 minutes instead of spending 20-60 minutes on it, why wouldn't you do it? Same applies for all areas of the entire workflow. Not doing everything by hand doesn't reduce the value of the final product.

Yes, it maybe work for some special cases, but all in all you do that by hand, or have to rework the hard surface objects by hand after using a reduced version as a start. You can see that process in every workflow of all studios for games. But espectially for organic stuff, clothing and avatars you rebuild by hand. And don't forget you can't compare sl to a common current game. Those use modern game engines, those have minimum hardware requirements. Here we literally play a 15 year old game and ppl connect to sl with old machines or old laptops. And everything you see get's loaded/streamed on demand, not like a game where you have a loading screen and stuff gets preloaded. So we have to optimize the content like for a mobile game i would say, trying to have the polycount as low as possible and think about texture usage. The texture usage is something you learn in time, but creating low poly mesh is something every amateur normally learns when he starts doing mesh work. I'm totally self taught, i never had a single mesh item that looks like most of the stuff you see today. And i don't know who startet this to spam sl with all that highpoly stuff. If linden lab would make the ppl more aware of how things should be and give them the retopo links i posted above for example, that probably would help. If you don't say anything, you see whats happening. Here some nice example: