🪰 Viewer Bug Reports

Create a simple cube (mesh or prim) and scale it to 0.3, 4.0, 4.0. Create another cube, scale it to 4.0, 4.0, 0.3 and place it on top of the first one. Set the sun azimuth so that it shines onto the wide side of the first cube. Move away from the objects and observe that the shadow changes; there is now a fully lit band of light directly underneath the second object. This seems NOT to be not related to: • Materials/PBR -- adding a PBR material does not change this behavior. • Geometry -- the objects are watertight. • LOD -- a mesh cube with all LODs using the full geometry behaves the same. • Physics Shape Type -- Convex Hull and Prim behave the same. I have found only two factors that affect this: Top object thickness -- the effect kicks in farther away with thicker objects. The Draw Distance -- the effect kicks in farther away with lower distances. Interestingly, moving the top object up so that there is a gap between the two object changes the behavior and reduces the effect; see the attached image. PS: I realize that this may not technically be a "light leak" -- but I couldn't think of a better term. PS 2: I have tried to think of ways of designing around the issue, but I don't think there are any realistic options. Most non-trivial structures will encounter this issue in some form or other.

After login or teleport, it often happens that some objects (usually large props like parts of buildings, landscaping stuff) are not displayed until I (accidently) rightclick on them. In older viewer-versions you could toggle wireframe off/on to force all objects to be shown and there are other tricks to 'unhide' those objects. That issue is well known for many years, for example, look here: https://community.secondlife.com/forums/topic/459592-problem-larger-mesh-props-remain-invisible/ and its a mystery to me why it gets no attention from the devs. Its extremely annoying, almost a showstopper for me. It just happens a lot to me, no matter what viewer I'm using (FS and LL), what PC I'm using and how fast my connection is. I'm not using any exotic hardware or settings. After almost every teleport I'm standing on invisible floors, bouncing against invisible walls and looking at party rezzed buildings.

When taking a snapshot with Screen Space Reflections (SSR) enabled in the viewer, reflections visible on reflective surfaces in the viewer window are not captured in the resulting snapshot. This results in a discrepancy between what the user sees in the viewer and the final saved image. Steps to Reproduce: Enable Screen Space Reflections in the viewer settings (Graphics -> Advanced Lighting Model -> Reflections -> Screen Space Reflections). Position your avatar in a location with reflective surfaces (e.g., near water, mirrors, or shiny objects). Ensure that reflections are clearly visible in the viewer window on those surfaces. Take a snapshot using the in-viewer snapshot functionality. Observe that the saved snapshot does not include the reflections that were visible in the viewer. Expected Result: The saved snapshot should accurately capture all visual elements present in the viewer window, including screen space reflections. Actual Result: The saved snapshot is missing the screen space reflections, resulting in a visually inconsistent image. Workaround: None known. Affected Versions: [Specify affected viewer versions] Attachments: Snapshot_001.png - Result of the snapshot showing the missing reflections. Viewer_Screen_Snip_Capture.JPG - Screenshot of the scene as seen from the viewer in-world, with reflections clearly visible.

When a probe larger than 64x64x64 is created, all other reflection probes stop baking normally. They will still update on forced changes but will not update over time. Fixing this behavior or disabling probes above 64m are both acceptable fixes.

Sunlight/Moonlight anything to do with the current environmental sky lighting no longer causes this reflection shown in my uploaded example. It is still possible to get this reflection from neighboring light sources, like prim lights. Can this lighting effect be reintroduced into the environment lighting once more? Reasons for this technique being great is: ~Avatars Eye Lenses (Create a dome over the eye to act only as a glossy wetlayer) which allows you to add normals and other depth to the lower layers of the eyes. ~Any object that requires a 100% see through yet able to create a glossy effect without looking like a opaque window. There are many use cases for this but it brings great sadness that this method if being widdled away with latest tech and pbr can not even produce this glossy effect without introducing some opacity to the texture looking like a opaque window.. Please right now its still half working, being able to work with prim lights. But as a creator i am getting growing reports of my creations now longer giving this glossy effect, due to the environmental lighting no longer having a effect at all on it.

login fly to a area away from where you logged in at look for missing items that were in world prior logout where the items are missing login > items reappear after logging into that location

Demonstration Video: https://youtu.be/eQ_YiWhfJWY It appears that projector priority seems to be using inverse the light radius to calculate shadow priority. Make 3 projector lights equidistant from each other pointing towards a centerpoint (for ease of seeing the shadows) Adjust the radius of the light furthest from your view larger and smaller and observe Adjust the radius of the light closest to your view larger and smaller and observe.

Reflection probes trigger an update every time you cross a parcel connected even when both parcels are using the same EEP setting and same large probe, that is disrupting, it should not trigger an update if both parcels are using the same EEP within the same region, same owner. It's very common in regions like Bay City, Nautilus (not limited to it... ), where we cannot merge parcels, that was not problem before PBR, and reflection probes are quite slow to update ( 1 to 3 seconds ) noticeably "brightening" the scene while its updating. In my case I have several in Bay City, and 3 scenes share two or more parcels connected. Left an example here: http://maps.secondlife.com/secondlife/Bay%20City%20-%20Moloch/162/227/26 2 parcels, same owner, same region, same EEP... 1 probe, 1 scene... can be observed by walking the concrete walkway. That only happens with "Use Shared Environment", does not happen if you select Midday (the new one) on the viewer as a fixed environment.

Working on a mesh lantern, the materials are doing a weird thing when I apply the scripting function to swap the material via UUID. Both materials have identical maps, one material has a different emissive tint (the lamp lighting in places). The function I am using in the script is llSetLinkPrimitiveParamsFast, no scripting changes were made to the material properties, just swapped out the whole material, A for B / B back to A, over the entire mesh object UV, not individual faces. The script has no errors, and though the materials are fully rendered and clear the materials are showing up with these odd edges, like the normals or smoothing groups are messed up, but they were not before scripting (see pictures). These artifacts are not everywhere on the whole object, but in random places all over it. In the FS client, If I rez the scripted object from inventory, it shows the glitched material. If I then drag and drop that same material onto the mesh from inventory, it suddenly looks fine. If I click the button to activate the script, it reverts back to the glitch and remains so no matter how many times it is turned on or off. So the script changing the material is causing the issue. I and others have checked all aspects of the scripting and the code and UUIDs are correct. Next I used the latest SL client and when I rezzed the item from inventory, the glitch was visible on the material, HOWEVER If I dropped the material from inventory onto the item, it cleared up and looked correct AND the fix was persistent before and after running the script that made the glitch revert back in FS. So initially, it showed the glitch, then if I drop the material onto it, it is fixed permanently. If I drag a "fixed" one back into inventory, rez it again to see if it remains fixed, it does so. Problem solved in SL client. When I went back in to FS, the ones I had fixed and left out while in the SL client looked correct still. When I clicked to run the script, they glitched again. If I dragged the material onto it, fixing the material, then clicked, it glitched then also. If I dropped the material onto it from inventory, fixing it, then took it back into inventory fixed, when I rezzed it, it was glitched again and operating the script would continue to be glitched. No permanent fix for the visual glitch, in or out of inventory. I repeated all these tests in the FS, FS Beta, Alchemy Beta, Black Dragon client and the results were all the same in every client except the official SL client, so I am assuming it is an issue with the script handling of PBR materials in all 3rd party clients. The SL client was able to consistently reproduce the correct rendering using the script, also upon taking the item into inventory and rezzing it again.

When looking out over water, and void regions, there is a distinct line at one point in the view with a sometimes quite large specular highlight that should not be present. The sun or moon reflections spread out to that line. It is noted that @Geenz is aware of this, that its been present in many 7.* viewers and that it could already be noted as an issue but low priority. Just reporting here as I had a clear snapshot of the issue. Attached. Try testing looking West at various times of day and in shared environment as sun is higher in west sky at http://maps.secondlife.com/secondlife/Damiano/49/5/21