🪰 Viewer Bug Reports

Depending on the running state of the script the glow and transparency appears to break. The provided script only handles the scale and movement of the object, it doesn't set any texture or material values which makes me think its movement related. https://gyazo.com/888c2c8c4b39f8772f8184890ca79bc6 Create a linkset of 65 cubes. Set them all to the default white texture in the blinn-phong texture window. Set the glow value to 1 and the transparent value to any non-zero value. Create a new script and insert the following SLua script. Watch the state of the glow and transparency when toggling the scripts running state. -- Neon Zombie 2026. -- SLua linkset movement testing -- 65 links total: 1 root, 64 children. Child cube default scale dynamically set -- Linkset local FIRST_CHILD_LINK = 2 local LAST_CHILD_LINK = 65 local TOTAL_CHILDREN = LAST_CHILD_LINK - FIRST_CHILD_LINK + 1 local GRID_SIZE = 4 local CUBE_SIZE = 0.025 local MIN_SEPARATION = CUBE_SIZE * 2.0 local volume_area = 0.06 local TIMER_RATE = 0.02 local SPRING = 16.0 local DAMPING = 0.90 local MASS = 1.0 local MAX_DT = 0.033 -- Collision local COLLISION_DIST = CUBE_SIZE * 1.75 local COLLISION_DIST_SQ = COLLISION_DIST * COLLISION_DIST local REPULSION_FORCE = 2000.0 -- Localized Math local m_sin = math.sin local m_cos = math.cos local m_sqrt = math.sqrt local m_pi = math.pi local m_random = math.random local function v(x, y, z) return vector(x, y, z) end local ZERO_VECTOR = v(0, 0, 0) local ZERO_ROTATION = ll.Euler2Rot(ZERO_VECTOR) local state = {} local primCache = {} local timerHandle = nil local startTime = 0 local lastTime = 0 local cubeSizeVec = v(CUBE_SIZE, CUBE_SIZE, CUBE_SIZE) -- Precompute float paths and stack positions, its much much faster. local function buildCaches() local gridHalf = ((GRID_SIZE - 1) * MIN_SEPARATION) * 0.5 for i = 0, TOTAL_CHILDREN - 1 do local x = i % GRID_SIZE local y = math.floor(i / GRID_SIZE) % GRID_SIZE local z = math.floor(i / (GRID_SIZE * GRID_SIZE)) local stackPos = v( (x * MIN_SEPARATION) - gridHalf, (y * MIN_SEPARATION) - gridHalf, (z * MIN_SEPARATION) - gridHalf ) primCache[i] = { stackTarget = stackPos, -- Expanded movement area amplitudes ax = 0.04 + m_random() * volume_area, ay = 0.04 + m_random() * volume_area, az = 0.02 + m_random() * volume_area, sx = 0.8 + m_random() * 0.4, sy = 0.8 + m_random() * 0.4, sz = 0.6 + m_random() * 0.4, phaseX = m_random() * 2 * m_pi, phaseY = m_random() * 2 * m_pi, phaseZ = m_random() * 2 * m_pi } state[i] = { pos = stackPos, vel = ZERO_VECTOR } end end -- Generates the destination coordinate for a specific cube at time 't' local function getFloatTarget(i, t) local c = primCache[i] return c.stackTarget + v( m_sin(t * c.sx + c.phaseX) * c.ax, m_cos(t * c.sy + c.phaseY) * c.ay, m_sin(t * c.sz + c.phaseZ) * c.az ) end local function updatePhysics(t, dt, snap) if dt > MAX_DT then dt = MAX_DT end local batchParams = {} local pIdx = 1 -- Immediate snap resolution if snap then for i = 0, TOTAL_CHILDREN - 1 do local link = i + FIRST_CHILD_LINK local target = primCache[i].stackTarget state[i].pos = target state[i].vel = ZERO_VECTOR batchParams[pIdx] = PRIM_LINK_TARGET batchParams[pIdx+1] = link batchParams[pIdx+2] = PRIM_SIZE batchParams[pIdx+3] = cubeSizeVec batchParams[pIdx+4] = PRIM_POS_LOCAL batchParams[pIdx+5] = target batchParams[pIdx+6] = PRIM_ROT_LOCAL batchParams[pIdx+7] = ZERO_ROTATION pIdx = pIdx + 8 end ll.SetLinkPrimitiveParamsFast(0, batchParams) return end -- Calculate Base Forces local currentForces = {} for i = 0, TOTAL_CHILDREN - 1 do currentForces[i] = (getFloatTarget(i, t) - state[i].pos) * SPRING end -- Collision Pass for i = 0, TOTAL_CHILDREN - 1 do local pi = state[i].pos for j = i + 1, TOTAL_CHILDREN - 1 do local pj = state[j].pos local dx = pi.x - pj.x local dy = pi.y - pj.y local dz = pi.z - pj.z local distSq = dx*dx + dy*dy + dz*dz -- If inside collision radius (ignoring perfectly overlapping zero-distance vectors) if distSq < COLLISION_DIST_SQ and distSq > 0.000001 then local dist = m_sqrt(distSq) local overlap = COLLISION_DIST - dist -- Calculate normalized repulsion vector scaled by overlap severity local pushMag = overlap * REPULSION_FORCE local push = v((dx/dist)*pushMag, (dy/dist)*pushMag, (dz/dist)*pushMag) -- Apply equal and opposite penalty forces currentForces[i] = currentForces[i] + push currentForces[j] = currentForces[j] - push end end end -- Batch Update for i = 0, TOTAL_CHILDREN - 1 do local link = i + FIRST_CHILD_LINK local s = state[i] -- Apply force to velocity, dampen, and update position local accel = currentForces[i] / MASS s.vel = (s.vel + accel * dt) * DAMPING s.pos = s.pos + (s.vel * dt) -- Dynamic rotation: makes the cubes tumble as they move local rot = ll.Euler2Rot(v(s.vel.y * 2.0, s.vel.x * 2.0, 0)) batchParams[pIdx] = PRIM_LINK_TARGET batchParams[pIdx+1] = link batchParams[pIdx+2] = PRIM_POS_LOCAL batchParams[pIdx+3] = s.pos batchParams[pIdx+4] = PRIM_ROT_LOCAL batchParams[pIdx+5] = rot pIdx = pIdx + 6 end if #batchParams > 0 then ll.SetLinkPrimitiveParamsFast(0, batchParams) end end local function onTimer() local now = os.clock() local dt = now - lastTime lastTime = now local t = now - startTime -- Update physics (snap = false) updatePhysics(t, dt, false) end -- Init local function startup() math.randomseed(math.floor(os.clock() * 100000)) buildCaches() -- Snap all cubes to stack immediately updatePhysics(0, 0, true) startTime = os.clock() lastTime = startTime if timerHandle then LLTimers:off(timerHandle) end timerHandle = LLTimers:every(TIMER_RATE, function() local success, err = pcall(onTimer) if not success then ll.OwnerSay("Runtime Error in Timer: " .. tostring(err)) LLTimers:off(timerHandle) timerHandle = nil end end) ll.OwnerSay("Asteroid Simulation Running. Touch to reset and scatter.") end -- Resets the layout. LLEvents:on("touch_start", function(detected) -- Randomize the float targets for a new pattern on every click buildCaches() -- Snap them all to the tight grid and let physics push them apart on the next frame updatePhysics(os.clock() - startTime, 0, true) end) startup()

Blinn-Phong textures with alpha channels appear excessively transparent in the PBR client, with thinner alpha edges. Adjusting the exposure to the lowest setting or changing environment settings doesn't help. This issue affects many products, and the only solutions are to double the layer or make textures more opaque and have two versions of the same product included with the purchase. However, this causes inconsistency for users who don't use PBR, as they will see the items differently than PBR users.

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

Reflection probes if they are rezzed by an object and part of a linked object are not activated unless this reflection probe (or link) specially selected and moved by hand. This is for reflection probes and mirror probes. Just create a basic mirror with proble linked and try to rez it by another object.