Open sl-service-account opened 10 years ago
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago Whirly Fizzle commented at 2014-06-02T17:21:47Z
Examples:
I could find more horrifying examples then those, but you get the point ;)
sl-service-account
commented
10 years ago 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
sl-service-account
commented
10 years ago 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:
sl-service-account
commented
10 years ago 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!
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
10 years ago 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?
sl-service-account
commented
10 years ago 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
sl-service-account
commented
10 years ago 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.
sl-service-account
commented
9 years ago 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)
sl-service-account
commented
7 years ago Whirly Fizzle commented at 2017-06-06T15:17:34Z
https://community.secondlife.com/forums/topic/407571-whats-wrong-with-this-picture/ sigh...
sl-service-account
commented
7 years ago 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.
sl-service-account
commented
7 years ago 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.
sl-service-account
commented
7 years ago 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.
sl-service-account
commented
7 years ago 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
sl-service-account
commented
7 years ago 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.
sl-service-account
commented
6 years ago Whirly Fizzle commented at 2018-01-21T15:28:58Z
Soft, see BUG-202959 for an interesting proposal related to this problem.
How would you like the feature to work?
Allow the user to permanently suppress the warning if they aren't concerned about it
Why is this feature important to you? How would it benefit the community?
There's a trend toward selling content that doesn't render properly on a viewer with default viewer settings. The low LODs are nonsense jumbles or have significant issues like coincident surfaces at a medium distance. This content needs to be displayed at its full LOD even when not close to the object. I believe that a significant part of the problem is that creators crank the RenderLODFactor (and possibly other settings - anyone know more?) for everyday SL use or for taking high quality product photos. They then forget that this setting is raised and proceed to create new content without experiencing how it will look on a normal viewer on a lower-end machine, or even a high end machine without modified debug settings. By presenting a warning when creating content while the setting is cranked, many creators will take the cue and create content that looks good for everybody.
Attachments
Links
Related
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-6243 | | Summary | Provide an informative warning when creating sculpts or mesh that may render improperly for others | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Soft Linden (soft.linden) | | Created at | 2014-06-02T16:28:43Z | | Updated at | 2019-12-04T13:41:27Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2014-06-02T12:01:37.754-0500', 'How would you like the feature to work?': '* If a user has a very high RenderLODFactor or other configured setting that affects LOD selection for sculpts or mesh, present a warning when selecting a sculpt texture or uploading a mesh object\r\n* Make the warning indicate that objects that look good for this user may look "broken" to users with normal settings\r\n* Link to a knowledgebase article where contributors can detail/debate problems\r\n* Allow the user to permanently suppress the warning if they aren\'t concerned about it', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "There's a trend toward selling content that doesn't render properly on a viewer with default viewer settings. The low LODs are nonsense jumbles or have significant issues like coincident surfaces at a medium distance. This content needs to be displayed at its full LOD even when not close to the object. I believe that a significant part of the problem is that creators crank the RenderLODFactor (and possibly other settings - anyone know more?) for everyday SL use or for taking high quality product photos. They then forget that this setting is raised and proceed to create new content without experiencing how it will look on a normal viewer on a lower-end machine, or even a high end machine without modified debug settings. By presenting a warning when creating content while the setting is cranked, many creators will take the cue and create content that looks good for everybody.", } ```