Open sl-service-account opened 9 years ago
Extrude Ragu commented at 2015-03-19T20:49:24Z
Hello. I'd like to comment on this issue, as the developer of the Sim mentioned in this bug report.
This issue, to me as someone who is trying to create a new experience in Secondlife, is really hindering my progress. I spend a lot of time optimizing models specially for SecondLife, scripting automatic teleport HUD's, and preparing for SecondLife's Experience Key's project, only to find that all my hard work is being undermined by bugs in the viewers code introduced from Project Interesting.
As you can see from the report that Whirly has kindly made for me, lots of my models, both mine and other peoples in this region are being rendered incorrectly as a result of this bug. This bug in my simulator happens very often because people are going through the teleport doors very often as they walk about in my experience.
It is not inspiring confidence in the visitors to my sim, or inspiring me, that creating an experience in SecondLife is a good idea at this point. You must understand that this bug whilst might seem small to a Labs developer, has a huge knock on effect to the content creators in SecondLife and the patrons of SecondLife, when they are unable to view the world correctly.
With all that said, I hope the Lindens realize the importance of this issue and the negative impact it is having on the development of my sim and experiences that rely on teleporting users. If there was one thing, as a developer that I would like to ask of the lindens right now, is that this issue was being taken very seriously. :)
Whirly Fizzle commented at 2015-07-13T18:02:23Z
This is fixed in Lion: https://bitbucket.org/lindenlab/viewer-lion/commits/f3daa77529013737afe963c5508d65ada20aff6b MAINT-5015 (Nearby objects often load at wrong LOD at login or after intra-region teleports)
This is not a new problem but I have a fairly solid repro so thought it worth a fresh issue.
This has been a problem since the viewer-interesting changes and has been filed several times already. I linked the related issues.
Steps to Reproduce
You should be able to reproduce this on any graphics quality settings, but to make the repro easier, set draw distance to ~ 350m. Apart from raising the draw distance, default High settings should be fine. Also note that the value of RenderVolumeLODFactor does not matter - even if you raise RenderVolumeLODFactor to 4 in debug settings, the bug will still reproduce.
Teleport to http://maps.secondlife.com/secondlife/Surprise/145/74/3515 and wait for the region to cache.
After the region has cached, relog to last location.
After relogging, cam (or walk) around the platform and observe the trees and bushes and whether their foliage is visible or not.
Double click teleport around the platform and observe whether the foliage of the trees and bushes disappeared after the teleport.
There is another way to intra-region teleport on this region which reproduces the bug really well:
When the bug reproduces, right click the broken trees & bushes to fix them and then perform another intra-region teleport.
Observed Behaviour
Often when logging in at the repro location or after an intra-region teleport, random trees will have lost LOD, particularly on the foliage which is a seperate part of the linkset and they show at lowest LOD. Some of the bushes will be displaying lowest LOD (pretty much vanished).
From one side these trees will look like their foliage is invisible - See Fig 1 and Fig 3
From the other side, you will see the foliage is there, but loaded at lowest LOD - see Fig 4
When the bug reproduces, if you walk right up to a tree that displays with broken foliage, the foliage will not load.
If you alt+click on a broken tree and cam really close to it, the foliage will not load.
If you right click a broken tree, the foliage instantly appears and loads at full LOD - See Fig 2 and Fig 5
Sometimes zooming camera way out and back will force the foliage to correctly load but not always.
Fig 6 animated gif shows the problem still reproducing when RenderVolumeLODFactor is set to 4
This problem happens everywhere but is very easy to reproduce at this location - it should only takes you minutes to reproduce it.
Expected Behaviour
Objects should load at correct LOD at login. Objects that were displaying at correct LOD should not break after an intra-region teleport.
Other Information.
This bug is not limited to rezzed objects, it also happens to worn attachments (particularly mesh) at login or after a teleport - see BUG-6803
I cannot reproduce this bug on a pre-interesting viewer: Second Life 3.7.7 (289441) Apr 22 2014 11:15:59 (PreInteresting) http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.7.289441
Attachments
Links
Related
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-8806 | | Summary | Nearby objects often load at wrong LOD at login or after intra-region teleports | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Whirly Fizzle (whirly.fizzle) | | Created at | 2015-03-18T23:58:21Z | | Updated at | 2016-06-16T15:57:31Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2015-03-19T15:49:24.152-0500', 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': '.', 'What were you doing when it happened?': 'Filling in...', 'What were you expecting to happen instead?': '.', 'Where': 'http://maps.secondlife.com/secondlife/Surprise/145/74/3515', } ```