Soft Linden commented at 2014-06-02T16:50:32Z

The attached example uses the default settings on a high end iMac. Seven of the nine desk lamps show as noise. The up-close objects are fantastic and well made, but the lower LOD doesn't even hint at what the object is.

Whirly Fizzle commented at 2014-06-02T17:01:38Z

...and possibly other settings - anyone know more?

Along with cranking up RenderVolumeLODFactor, the other longtime favourite is setting TextureLoadFullRes to TRUE.
Enabling TextureLoadFullRes is a very bad thing to advise someone to do, it can quickly cause out of memory crashes.
Unfortunately I have seen many product "help" notecards from creators advising their customer to raise RenderVolumeLODFactor to 20 (or some other ridiculously high number) and to set TextureLoadFullRes to TRUE.

We have a "Sanity Checker" in Firestorm viewer which will nag the user at viewer launch with a modal warning if they have made certain settings changes that are deemed dangerous - TextureLoadFullRes is one of them.

Soft Linden commented at 2014-06-02T17:14:30Z

I remember seeing a few product notecards that advised users to tweak various debug settings, but I don't remember which products had them off hand. If you (or anyone!) have any at hand, it would be helpful to paste those sections in this JIRA. No need to name and shame, just help ensure everyone understands the problem incentive.

Whirly Fizzle commented at 2014-06-02T17:21:47Z

Examples:

• One of the most popular bloggers recommends setting RenderVolumeLODFactor at 14: http://strawberrysingh.com/2012/08/16/debug-me/
• Slink recommends RenderVolumeLODFactorat 4,5 or 6: http://slinkstyle.com/tips-for-better-looking-sculpties/
• RenderVolumeLODFactor at 5: http://mpp-mainstore.com/tricks.php
• Recommends setting TextureLoadFullRes to TRUE for this mesh avatar: http://karasecondlife.blogspot.co.uk/2011/12/mesh-avatar-bel-new-horo-v3-mesh-avatar.html

I could find more horrifying examples then those, but you get the point ;)

Whirly Fizzle commented at 2014-06-02T17:29:29Z

Another fave is raising "MeshMaxConcurrentRequests" - though Monty is already well aware of this problem.
For ref see: http://community.secondlife.com/t5/Second-Life-Viewer/avi-dosn-t-load-correctly/td-p/2137193

Whirly Fizzle commented at 2014-06-03T02:24:54Z

Searching for "RenderVolumeLODFactor" within https://marketplace.secondlife.com/ - 16,200 results - it's a safe bet 99% of those results will be advising to set at 4 or above.

Random examples:

1. "RenderVolumeLODFactor - value 20.000" - https://marketplace.secondlife.com/p/reBourne-Colorado-Horse-stable-cowboy-ranch-Old-barn-Skybox-Ground-version-inclu-perfect-for-Champion-horses/2411202
2. "select 'RenderVolumeLODFactor", Change value to 10.000....done" - https://marketplace.secondlife.com/p/Twin-Round-sofa-set-with-7-sitting-poses/3631431
3. "Please set your RenderVolumeLodfactor on 8" - https://marketplace.secondlife.com/p/Nantucket-Promo/5751403, https://marketplace.secondlife.com/p/Store-Charleston-3/5721234 etc
4. "set the RenderVolumeLODFactor to 6 or higher for better looks" - https://marketplace.secondlife.com/p/HMC-Back-III-Civil-BOX/5509880
5. "for the best view set RenderVolumeLodFactor to 6 " - https://marketplace.secondlife.com/p/Stylia-PrimaPro-Mesh-Store/4105822, http://wiki.phoenixviewer.com/dev:start etc
6. "A value between 4 and 6 is recommended" - https://marketplace.secondlife.com/p/deHavilland-DHC-2-Turbo-Beaver/3189160
7. "Then keep the RenderVolumeLODFactor set to 5 as it increases the LOD : Advanced > Debug settings > RenderVolumeLODFactor > Value = 5 then Enter. Also check regularly this setting as it might change automatically when you change graphic preferences or when you change a viewer to another." - https://marketplace.secondlife.com/p/The-Swan-18-LI-Copy-an-modify-mesh-prefab/5972067, https://marketplace.secondlife.com/p/Duckboard-FULL-PERMS-Mesh-0500-LI/4656975, https://marketplace.secondlife.com/p/Torii-Shinmei-FULL-PERM-Mesh-1-LI/4641606, https://marketplace.secondlife.com/p/The-Batshelves-1-LI-FULL-PERMS-Mesh/5156478 etc
8. "RenderVolumeLODFactor > Value = 5 then Enter" - https://marketplace.secondlife.com/p/Chinese-Dressing-Screen-2/4944226
9. "For best results set RenderVolumeLodFactor to 5.0 in Debug Settings." - https://marketplace.secondlife.com/p/Goth-Dollhouse-BOXED/1800896
10. "Set the value of "RenderVolumeLODFactor" to at least 4 (I set mine to 16)." - https://marketplace.secondlife.com/p/UB-Emerald-Accessories/1580259?lang=en-US
11. "type: renderVolumeLODFactor - Set it to 4 or 5" - https://marketplace.secondlife.com/p/Stairs-Flanked-by-Pedestals-2-PRIMS/1647908
12. "Type: " rendervolumeLODFactor " and adjust it to 4 or 5" - https://marketplace.secondlife.com/p/YANAROXX-6-Xmas-Gift-Boxes-GIFT/2836328
13. "Set the value of "RenderVolumeLODFactor" to 4 that will make all sculpts looking great." - https://marketplace.secondlife.com/p/Sculpt-Nano-Prims-Octagon-Hexagon-w-Sculpt-Map-Full-Perms/877369
14. "RenderVolumeLODFactor - change the value from 1.00 to 4.00!" - https://marketplace.secondlife.com/p/Pirate-Mockingbird-Electric-Guitar/2093100

arton Rotaru commented at 2014-06-03T04:51:28Z

This is a very good idea!

Although, a lot of mesh creators blank out the lower LODs completely, because it results in a very low land impact. They then advertise these occasional high poly objects with "Super detailed, very low land impact" phrases, and give the advise that the rendervolumeLODfactor should be set to these ridicluous numbers. Some of them may consider it's not worth it to take the effort to make proper LOD models, because it often results in higher land impact, and can be worked around with the LOD factor setting. So I suspect this issue will go on to some degree, even with a warning.

Another aspect of this habit is, having people on these high LOD Factor settings, though even highpoly/high res textured meshes have very little land impact numbers, enables people to cram alot of these objects onto tiny spaces. Rendering most of them at it's highest LOD due to the setting, and afterwards they complain why Second Life has such poor performance for them.

Anyway, I also talk to people who aren't aware of the LOD issue, because they don't know how all of this works together. It will be a very good idea to show a warning!

Whirly Fizzle commented at 2014-06-03T13:33:56Z

How about force setting the RenderVolumeLODFactor to 1.125 each time the "Upload" button is clicked in the mesh upload floater?
Creators would then see their newly uploaded meshes on default LOD settings.
Simple, evil but effective :D

1.125 is the default setting for Low to High-Ultra. Ultra default is 2.000.

If RenderVolumeLODFactor was reset during upload, this could be accompanied by a modal warning saying somthing like "Your RenderVolumeLODFactor was reset to default settings. See to explain why".
Force resetting of RenderVolumeLODFactor could have a debug setting to disable the reset - though this may defeat the purpose.

Soft Linden commented at 2014-06-03T14:10:30Z, updated at 2014-06-03T14:11:09Z

Although, a lot of mesh creators blank out the lower LODs completely, because it results in a very low land impact
If this is the case, that sounds like a bug. I would expect the land impact to include a calculation where the complexity of the mesh is the max of (full LOD, some multiple of the low LOD). If it's only looking at the low LOD or if it's summing rather than selecting the max, that effects a disincentive toward efficient content.

Soft Linden commented at 2014-06-03T14:34:11Z

@whirly I think rather than slamming the setting, it would be worth a separate warning for content consumers. When manually altering that setting, the viewer could take a cue from Firestorm's dangerous setting warnings. Users would be warned that they are sacrificing framerate and scene load times by raising a given value, and could be guided to contact content creators to inquire about updates if content is indecipherable at lower LODs.

IMHO, the simple and "evil" option would be to rename these settings to more explicitly state what they do: Something like "RenderSacrificePerformanceFor" and see how mesh buyers respond to understanding the tradeoff they're asked to make.

arton Rotaru commented at 2014-06-03T15:00:55Z

The land impact calculation is complex. It takes the dimensions of the objects into account as well. The bigger an object, the less effective are the lower LODs in reducing the land impact, namely the Download Weight.

On smaller objects, the biggest impact in reducing the land impact will have the low and lowest LODs. Rather small objects can have very high polycounts, but still very little land impacts. This is all ok, as long as you are on a default LOD factor setting. Because you'll only render a bunch of jumbled triangles when zooming out just a couple of meters. Very renderfriendly so to say. :) Second Life just looks like a world of spiky triangles then.

It's common to cut larger pieces in half, to reduce the bounding box size, to make the land impact reduction effect of lower LODs more dominant. Of course, this results in even more assets the GPU has to cope with, but also the objects will switch to lower LODs earlier. Wich require a higher LOD factor again, if you don't bother to make proper LOD models.

So the land impact calculation works as intended. It's a "one fits all" approach, which isn't ideal. But hey, to cope with it, is complex enough already.

Just an example: As a vehicle creator myself, I sometimes drive on some race tracks. Sometimes I see SUPER detailed car models there. Cars which have 200000 (and more) triangles in the high LODs. But once on the track, driving 5 meters behind them, I just see a driver sitting inbetween a bunch of triangles. :)

But such 200k triangle vehicles are advertised, and sold with a land impact of just 22. While my vehicles with about 18k tris, have a land impact about 43, for example. But mine stay recognisable as a vehicle from any distance with a LOD factor of 1.125.

Drongle McMahon commented at 2014-06-09T00:58:18Z

Soft, you might like to look at this forum thread which has some graphs of the relative dependency of download weight on the different LODs as a function of object size. The overriding effect of the lowest LOD for small objects is evident there. It was based on the calculations that are still in the viewer code, although I think all the calculation is on the server now. I don't know of any changes since mesh release.

Whirly Fizzle commented at 2014-07-07T00:32:56Z

This product notecard made me cry a little...

RECOMMENDED SETTINGS

Graphics > Hardware > Anti-Aliasing 12X

We also suggest disabling HTTP texture loading
Develop > Rendering > Full Res Textures

NC found in products at http://maps.secondlife.com/secondlife/The%20Shops/112/125/4
The HUD that comes with these products is also one of the culprets causing users to have bad texture thrashing lately. No doubt exacerbated by recommending users enable Full Res Textures.
A customer who bought a product here came into Firestorm support group asking why the viewer was telling her Full Res Textures was a dangerous setting to enable.

Soft Linden commented at 2014-07-07T01:06:02Z

Hopefully the author was making a joke. Those recommendations would utterly ruin performance for general Second Life use on any hardware that's shipping today.

I sometimes wonder: If after each crash, the viewer offered to reset all settings that are only accessible via the Developer menu, would people be willing to roll those back? Or if there were an option to list and optionally reset these in the Help menu, would people use it while troubleshooting? Or is there religion about some of these settings?

Whirly Fizzle commented at 2014-07-07T04:17:12Z

It's not a joke Soft. I wish it was.
How about making TextureLoadFullRes non persistant? There is no reason whatsoever a normal user should have this setting enabled. Having it reset to default each login would help. Those that need it enabled for debugging purposes will know enough to go and edit their settings.xml.
How about capping RenderVolumeLODFactor at 4 too so it cannot be set higher in debug settings?

Just a couple of examples (I can find you many more) of bug reports filed due to problems caused by enabling TextureLoadFullRes - VWR-29059 and BUG-5198

Whirly Fizzle commented at 2014-07-09T10:16:43Z

Here's another recent one busted for having TextureLoadFullRes set to TRUE and suprise suprise, they are reporting crashes: BUG-6604
At least it's possible to see when they have TextureLoadFullRes enabled in logs.

Whirly Fizzle commented at 2015-06-13T08:53:39Z

@Soft

Did this proposal ever make it onto the "to do" list?

My offering for the day...
Group notice sent today to a 10,956 member group (group 8ccc6c2e-44ff-6fbf-e222-9dccdabe1f32 if you want to check).

Group Notice From: ,

This should help members that may have issues seeing mesh or having it load correctly. When viewing mesh clothing.
If you need help just message me. See Notecard for information on LOD set to 8

NC text:
If your having problems with mesh loading or unable to rez mesh correctly please make these changes to your Viewer.

Hit "Control Alt D" to turn on your viewers Advanced Settings.
Goto: "Show Debug Settings"
Search for: RenderVolumeLODFactor change the setting to 8 hit enter.

No more problems seeing mesh load.

Information:
RenderVolumeLODFactor: Controls level of detail of primitives (multiplier for current screen area when calculated level of detail)

Whirly Fizzle commented at 2017-06-06T15:17:34Z

https://community.secondlife.com/forums/topic/407571-whats-wrong-with-this-picture/
sigh...

Soft Linden commented at 2017-06-06T17:48:39Z

We've got a classic Tragedy of the Commons scenario with rendering costs and low LODs. An individual creator doesn't have much incentive to create optimal content if the total scene render complexity is the only limit.

With avatars, it took making avatars invisible to many people when wearing highly inefficient mesh bodies or hair. Perhaps with individual objects we could do two things: 1. Ensure the low LOD objects are more often visible in low framerate situations, and 2. Make the trade off of disabling low LODs more clear.

Straw man proposal: Throw away the RenderVolumeLODFactor preference. Instead, derive it dynamically with two new settings. RenderFramerateTarget would be a target framerate. Among other things, it could be used to dynamically adjust the LOD factor based on sustained dips in average framerates. The other option would be a non-persistent toggle with a name like "RenderDisableSceneLODOptimization" that could be flipped for photos, etc. This would temporarily disable low LODs, and it could be made available in the snapshot floater or on a toolbar toggle. The setting wouldn't persist. The only option to make the behavior persist would be to set the target framerate down to a very low FPS.

Content creators are unlikely to tell users to set RenderFramerateTarget to 1FPS to avoid seeing bad low LOD models. If they do, customers will look for objects with higher quality low LOD mesh, assuming they can't all afford Titanium X Pascal bedroom warmers.

Whirly Fizzle commented at 2017-06-06T20:33:59Z

Content creators are unlikely to tell users to set RenderFramerateTarget to 1FPS to avoid seeing bad low LOD models

I feel you're being a bit optimistic there ;)
HiFi uses a similar system - their equivalent setting to RenderVolumeLODFactor is dropped lower when the viewer framerate drops below a set level.
This has caused multiple users to complain in the Hifi forums that some objects are always invisible or suddenly change to being invisible when another avatar enters the scene.
Other users then tell them how to set the RenderFramerateTarget equivalent setting to 0FPS to disable the object culling.

Soft Linden commented at 2017-06-06T20:58:35Z

It sounds like users are complaining about it doing what it's designed to do. They would also complain about framerate dips. The extra option means each user gets to choose whichever option the user prefers. Choose the accidental crowd bulldozer in a sea of beautiful 5FPS meshes. Or choose controlled and smooth movement, explore a sea of strangely made LODs with the occasional bright spot where a creator stands out for doing some smart extra work.

Whirly Fizzle commented at 2017-06-06T21:20:42Z

The other option would be a non-persistent toggle with a name like "RenderDisableSceneLODOptimization" that could be flipped for photos, etc. This would temporarily disable low LODs, and it could be made available in the snapshot floater or on a toolbar toggle.

Hmm isn't this what RenderDynamicLOD does now?
If you disable RenderDynamicLOD, you will always see the highest LOD model

I made a quick video showing how RenderDynamicLOD works.
I'm using Firestorm viewer but the same effect is seen on the LL viewer.
RenderDynamicLOD default setting is TRUE.
You can see that when RenderDynamicLOD is true, the LODs switch as the camera is moved towards & away from the object as expected.
Setting RenderDynamicLOD to FALSE always renders the highest LOD model
I often use this trick for photographs myself because when zoomed in using CTRL+0, the LOD switches to the lower models way too quickly (filed that problem at BUG-40757, though it is expected behaviour).

Luckily this setting doesn't appear to be well known or I'm sure we would see creators telling users to set RenderDynamicLOD to FALSE ;)

Video: https://gfycat.com/ElementaryPlaintiveAmericancrocodile

Soft Linden commented at 2017-06-06T21:40:56Z

Sure enough. I had it in my mind that this option only affected terrain.

It would be helpful if that setting didn't persist across sessions, or if toggling it gave a performance warning similar to what Firestorm does when forcing full resolutions textures.

Whirly Fizzle commented at 2018-01-21T15:28:58Z

Soft, see BUG-202959 for an interesting proposal related to this problem.