[BUG-6243] Provide an informative warning when creating sculpts or mesh that may render improperly for others #14124
Comments
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
Along with cranking up RenderVolumeLODFactor, the other longtime favourite is setting 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:
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. |
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? 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". |
Soft Linden commented at 2014-06-03T14:10:30Z, updated at 2014-06-03T14:11:09Z
|
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...
NC found in products at http://maps.secondlife.com/secondlife/The%20Shops/112/125/4 |
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. 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 |
Whirly Fizzle commented at 2015-06-13T08:53:39Z Did this proposal ever make it onto the "to do" list? My offering for the day...
|
Whirly Fizzle commented at 2017-06-06T15:17:34Z https://community.secondlife.com/forums/topic/407571-whats-wrong-with-this-picture/ |
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
I feel you're being a bit optimistic there ;) |
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
Hmm isn't this what RenderDynamicLOD does now? I made a quick video showing how RenderDynamicLOD works. 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. |
How would you like the feature to work?
If a user has a very high RenderVolumeLODFactor (1.0 or greater = "Medium" or higher) 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
Make the warning indicate that objects that look good for this user may look "broken" to users with normal settings
Link to a public wiki page where contributors can detail/debate problems
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
The text was updated successfully, but these errors were encountered: