Why doesn’t LL limit creators more?

[ChinRey]

6 hours ago, Digit Gears said:

If I as in charge of user content stuff in LindenLabs, I would disable the 'generate' option for the lowest LOD for a month just to see what would happen

If not disable it, at least not keep it as the default option. No serious mesh maker use LoD or physics models generated by the uplaoder of course but it can be useful for quick and dirty test uploads and of course for people taking their first babysteps into mesh making. However, I think most people who use generated models simply don't reflect on it at all. If they have to deliberately choose that option, there's a good chance at least some of them think twice and realize it's not a good solution.

[Cackle Amore]

32 minutes ago, ChinRey said:

If not disable it, at least not keep it as the default option. No serious mesh maker use LoD or physics models generated by the uplaoder of course but it can be useful for quick and dirty test uploads and of course for people taking their first babysteps into mesh making. However, I think most people who use generated models simply don't reflect on it at all. If they have to deliberately choose that option, there's a good chance at least some of them think twice and realize it's not a good solution.

Yeah, there really needs to be some way to help encourage people to make a proper LOD, since automatic anything in the creation process tends to be lackluster at best

[Coffee Pancake]

12 hours ago, animats said:

That"s the big-hammer solution to the problem. The combination of the uploader's bad mesh reduction algorithm and SL's huge LI benefit for a very low poly lowest LOD leads to those messes of see-through triangles in the distance.

No LOD for the lowest setting is not bad in all cases .. it's not even bad in most cases. Larger objects often wont ever show the lowest or even second to lowest LOD mesh on all the the most meager graphics settings. Smaller objects will suddenly vanish as the LOD meshes are reached much closer, however this is where context comes into play. If the small object is intended to be indoors, not rendering when i'm not in the same room is a good thing. Tiny objects need a high detail mesh right down to the wire, although if possible omitting the lowest is still not a bad idea.

Boils down to if no one will see it .. why have it.

The only way to work this out is on an object by object basis on the beta grid and do some testing before making the final object in SL.

There is nothing stopping creators putting multiple versions of an object in their package and just labeling then as 'max' detail (max detail mesh, all LODS), 'normal' detail (for the objects intended use case) and 'low' detail where only the first 2 LOD meshes are present and all other are empty. This would at least give you options for uses beyond the intended that wouldn't punish Li or render cost.. regions sizes chairs or small indoor stuff in an outdoor setting.

[ChinRey]

7 hours ago, CoffeeDujour said:

No LOD for the lowest setting is not bad in all cases .. it's not even bad in most cases.

This is one of the extremely few times I wished we had a dislike feedback otpion here.

Yes, no LoD/"zeroed out LoD" is bad in most cases, in nearly all cases even. As crude as SL's LoD system is, it is actually made so that all models are big enough to be visible on the screen and objects popping in and out of existence, and abrubt visual changes at the LoD swaps are just as annoying visually as LoD models that are poorly made in themselves.

There are two special cases:

Items that are only intended for confined spaces.

You can often compromise on the lower LoD models or those if you really, really want to. But make sure the item still looks good within the intended view distance and a little bit further just to be safe. Make sure it looks good with LoD factor set to 1 that is, not everybody have computing power to waste on icnreased LoD factors.

Items so big LoD swap distances are well outside default draw distance.

Don't zero out any LoD models for those. Use LoD above instead. It doesn't cost anything, neither in time, land impact or lag so you might as well give the few who use higher draw distances something nice to look at.

Edited March 7, 2020 by ChinRey

[Coffee Pancake]

I did say do testing on an object by object basis and it's no harder for creators to add multiple versions.

To be honest, I'd like to see the LOD system as it stands tossed in the trash and replaced with something like simplygon.

[animats]

13 hours ago, CoffeeDujour said:

To be honest, I'd like to see the LOD system as it stands tossed in the trash and replaced with something like simplygon.

Me too. Everyone who understands what it does realizes that the uploader's LOD generator is terrible. It has the advantage that it is fast, simple, and will work on bad geometry. Some of the better algorithms only work on watertight meshes - no missing faces, no reversed normals, etc.

There's also the weird restriction that all levels of detail have to use the same textures. You can't have some low-LOD model with simple geometry and simple textures. You have to pull in all the textures to render the lowest LOD. Huge waste for background objects.

A big technical problem is what to do for clothing LOD generation. What you want to happen is that fine detail in the high level gets turned into a normal map for the lower LODs, while maintaining the thickness of the cloth. It's unusual to do clothing the way SL does it, as back to back meshes with some space between them. Clothing mesh reduction needs something which recognizes thin layers as a special case. What's probably needed is an extension to Bakes on Mesh which bakes all the clothing down onto a mesh-reduced body, or something like that. The clothing experts need to figure out what to do here. What you want is for lower-LOD avatars to be turned into baked objects like video game characters. Up close, all the glorious detail of SL should show, but in the distance, it's got to go to keep the viewer from choking on crowds.

[French Couturier]

I've never had problems loading anything in SL, using a computer with 32gb of ram and having LOD level always set at 4. Then again I do not visit places packed with people very much. In my experience though one of the biggest things I've noticed that caused me lag is those scripted moving trees. I tested my fps before going to an area full of those trees and it dropped from 230 to 140. It's not just the poly count that affects performance but scripts in objects as well. Wouldn't be surprised if the scripts cause more lag than polygons.

Edited March 15, 2020 by French Couturier

[Coffee Pancake]

.....

1 hour ago, French Couturier said:

I've never had problems loading anything in SL, using a computer with 32gb of ram

SL wont use more than a couple of GB .. I guess windows and chrome will have to make use of the other 30.

1 hour ago, French Couturier said:

Then again I do not visit places packed with people very much

Avatars being the primary source of high detail models.

1 hour ago, French Couturier said:

In my experience though one of the biggest things I've noticed that caused me lag is those scripted moving trees.

That for the most part operate using a simple texture translation effect that's basically free to render. The motion isn't making your frame rate drop, it's just making it obvious.

1 hour ago, French Couturier said:

I tested my fps before going to an area full of those trees and it dropped from 230 to 140. It's not just the poly count that affects performance but scripts in objects as well. Wouldn't be surprised if the scripts cause more lag than polygons.

Scripts have nothing at all to do with your framerate. Those moving trees will still move after the script is removed. All the script in those does is set a primitive parameter that doesn't exist in the edit floater, once set the script is irrelevant (like setting hover text)

[French Couturier]

2 hours ago, CoffeeDujour said:

.....

SL wont use more than a couple of GB .. I guess windows and chrome will have to make use of the other 30.

 

How did you know I'm using windows and chrome?

[ChinRey]

11 hours ago, CoffeeDujour said:

That for the most part operate using a simple texture translation effect that's basically free to render. The motion isn't making your frame rate drop, it's just making it obvious.

Not anymore. It's animesh trees now.

Besides, unless we go back to Brice Bonetto's brilliant prim vegetation or LAQ's mesh take on his concept (which were uberlaggy anyway because of the excessive texturing), it's forced texture translation. Not the relatively render efficient llSetTextureAnim() function but step-by-step rotation using llSetLinkPrimitiveParamsFast() in an endless loop.