🪰 Viewer Bug Reports

When I zoom out far from my own avatar at a club or other texture-heavy areas, say to simply look around, when I return the camera to my own avatar a lot of the textures on my avatar - including materials - are lowered drastically in resolution and it takes the viewer upwards of 20-30 seconds before they go back to full. A resident's own avatar should never have the textures lowered in resolution unless it's specifically set in graphics > advanced, and should always take priority in staying at max quality according to graphics settings. Go to a club that is avatar heavy, so lots of textures are around - shopping events will probably work here too Wait for the viewer to load everything it can do - draw distance was 128 with textures at 2k maximum for this When your own avatar has loaded fully, alt+cam onto yourself and zoom out about half way to the clip plane - just looking around the area for a few seconds will work here too Return the camera to your avatar Lots of your avatar's textures, excluding BoM, are now super blurry, and will take ages to load back again Image 1 shows how my avatar is supposed to look > image 2 is how far I zoomed out (just across the room at this club) > image 3 shows how blurry my avatar's textures become after zooming back in, which stay like this for 20-30 seconds.

I've become aware of a texture rendering issue that impacts textures when on a face. It's not so much an issue that only impacts PBR textures, but it is exponentially worse and makes certain designs as mastered in Substance unusable as PBR. I'm not enough of a rendering brain to understand what is going on here, but it's my belief this is not correct and is a bug. I hope that this will get in front of the right people to be evaluated and hopefully fixed. This is being demonstrated with a 0-25% gray bi-linear gradient, however anything that uses color and gradients near this will exhibit the same obvious defects. A single example using real-world art is included for reference. Texture UUIDs Dark gradient lossy: cac83520-08b2-500f-b683-1ede13d4e052 Dark gradient lossless: bd66f42c-6b56-780e-c183-3307151f8292 Raw files, non-anotated screenshots, and sample items shown are available upon request but I don't think they will be necessary. As I was sharing this around with creator friends moments before submitting this I was made aware this may be or have been a known bug, and can be alleviated entirely on the material side by setting the alpha mode selector to blended. Masked and opaque do still exhibit the shown issues. This made me frown. There is no alpha channel on the textures shown.

Requires AMD GPU, Adrenalin 25.10.2 or later. See attachment for a visual of the issue. Toggling AO makes no difference. Please note that there is a risk of this issue being prevalent for many months to come if Linden does not exert pressure on AMD to work together on a solution to this rendering issue. I'm speaking from experience with other software. The workaround is to revert back to 25.9.1 driver. Others complained here: https://reddit.com/r/secondlife/comments/1olf72w/skinclothes_glitching/

When performing a scripted object scale change, the visual interpolation does not finish properly: the object never reaches desired size until it is selected, or some other kind of change happens to force it to update. If the object is selected already as the scripted command goes through, the object just snaps to the correct size since selected objects do not viewer-side interpolate. This could be a bit of a hassle for resize scripts and the like. Can't reproduce the problem with position/rotation, only scale interpolation. Problem can be reproduced in release 26.2 and FS 7.2.4 but NOT in Cool VL Viewer 1.32.4. Reproduction script below: float STEP = 0.125; vector BASE_SIZE; integer flag; default { state_entry() { BASE_SIZE = llGetScale(); } touch_start(integer _) { flag = !flag; llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SIZE, BASE_SIZE+flag*<STEP, STEP, STEP>]); // uncomment these lines to use a fullbright toggle to force proper visual scale update //llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_FULLBRIGHT, ALL_SIDES, TRUE]); //llSleep(0.5); //llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_FULLBRIGHT, ALL_SIDES, FALSE]); } } Drop the above into a prim cube with size 0.5, 0.5, 0.5. Make a second cube to use as a visual comparison aid with either the initial size, or the target size 0.625, 0.625, 0.625. Uncomment the lines to use a fullbright on/off to force a visual update and awkwardly sidestep the problem. Included demo image also shows the issue: the z-fighting confirms the white cube (scripted) is the same height as the red cuboid (height = 0.5) initially, and same as the green cuboid (height = 0.625) at the larger size. However, when performing a scripted change, the size never reaches 0.625 or 0.5. Problem might be somewhere in LLDrawable::updateXform since it uses an exponential damping factor that can never reach 0 or 1 exactly (unsure why that wouldn't interfere with position or rotation though).

Single stray flash observed at initial emission when PSYS_PART_FOLLOW_SRC_MASK flag is set, and the PSYS_SRC_BURST_RADIUS rule is therefore disabled, i.e. zero, as per the wiki, no matter whatever value is found in this latter parameter. Perfect coding practise would see the radius explicitly set to zero, but in the event that the the value has been left non-zero and simply relied upon as being disabled, there is a single emission at initial burst which results in a flash at a distance of the radius set. When a timer is running this will occur once at each tick of the timer. Ideally, the radius should indeed be set to zero, which removes the problem, but as the radius value is disabled for the case where the PSYS_PART_FOLLOW_SRC_MASK is set, and correctly does so generally, the initial flash emission should not be happening either and is likely causing visual glitches in-world. To Repro : Drop a simple particle emission into a prim such as: default { state_entry() { llSetTimerEvent(0.25); } timer() { llLinkParticleSystem(LINK_THIS, [ PSYS_PART_FLAGS, 0 | PSYS_PART_EMISSIVE_MASK | PSYS_PART_INTERP_COLOR_MASK | PSYS_PART_INTERP_SCALE_MASK | PSYS_PART_FOLLOW_SRC_MASK | PSYS_PART_FOLLOW_VELOCITY_MASK, PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_EXPLODE, PSYS_PART_MAX_AGE,0.5, PSYS_PART_START_COLOR,<1.0, 1.0, 1.0>, PSYS_PART_END_COLOR,<1.0, 1.0, 1.0>, PSYS_PART_START_SCALE,<0.5, 0.5, 1.0>, PSYS_PART_END_SCALE,<0.8, 0.8, 1.0>, PSYS_SRC_BURST_RATE,0.1, PSYS_SRC_ACCEL,<0.0, 0.0, 0.0>, PSYS_SRC_BURST_PART_COUNT,1, PSYS_SRC_BURST_RADIUS,0.5, PSYS_SRC_BURST_SPEED_MIN,0.1, PSYS_SRC_BURST_SPEED_MAX,0.2, PSYS_SRC_TARGET_KEY,(key)"", PSYS_SRC_INNERANGLE,0, PSYS_SRC_OUTERANGLE,0.5, PSYS_SRC_OMEGA,<0.0, 0.0, 0.0>, PSYS_SRC_MAX_AGE,0.00, PSYS_SRC_TEXTURE, "dcab6cc4-172f-e30d-b1d0-f558446f20d4", PSYS_PART_START_ALPHA,1.0, PSYS_PART_END_ALPHA,0.0, PSYS_PART_START_GLOW,0.0, PSYS_PART_END_GLOW,0.0 ]); } } Observe the stray emission at each tick of the timer: https://gyazo.com/5f8a6b9a8e4c5a657d3d3d0aaa13ce36 Set PSYS_SRC_BURST_RADIUS = 0.0 Observe correct behaviour https://gyazo.com/1a5612c42c44afb0f50ec06b79fe262d

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.

FIX EEP, Mainland environment cycle are way too dark, see my forum post https://community.secondlife.com/forums/topic/428374-environmental-enhancement-project-aka-eep-feedback-thread/page/41/#findComment-2861867

Textures are extremely slow to render. This is happening to about myself and a dozen friends of mine. For some reason over the last two weeks textures in SL irregardless of if they are 1k or 2k are taking forever to render a great amount of the time. It also seems to be affecting performance of each viewer as well. I can provide images and video recordings if requested. Clean installing, clearing cache, increasing cache size limits, etc. all do not change the issue.

The moon texture clips with skydome geometry, regardless of what the sky detail is set to in graphics preferences. If the sun is given the same texture, it does not clip. Steps to reproduce: 1) Inventory->new settings->new sky. Edit the new sky. 1b) optional: set cloud density and coverage to maximum to see it easier, but it is noticeable as long as there are any clouds at all. 2) Move the sun and moon to the same azimuth and nearby elevations, I used 270 azimuth and 33 elevation for testing. The effect is worse at higher elevations. 3) Set the sun and moon to the same texture, for instance "moon" from the library. 4) Set sun scale to 10, moon scale to minimum. Move the camera around while viewing the sun; it does not flicker. 5) Set the moon scale to 10, sun scale to minimum, do the above; the moon flickers and clips against the skydome geometry. Changing the sky detail level in preferences changes the granularity of the flicker, but doesn't avoid it. In the attached screenshot, top is the sun, bottom is the moon, moon has been set to 0 brightness. Elevations 45 and 30 respectively.

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.