🪰 Viewer Bug Reports

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

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.

I spent days trying to find the bug in my flight physics code that was causing this, only to discover that it was the viewer camera all along. The problem is that sometimes the aircraft flies "visually" smoothly at any speed up to 100 meters/sec; and other times it's visibly jerky, appearing to "vibrate" (change in apparent size many times/sec) as though the camera was acting like a spring instead of being fixed in place behind the vehicle. I'm using the eye/offset calls: llSetCameraEyeOffset(eye); llSetCameraAtOffset(offset); This is because the "newer" (21 years old instead of 23) follow cam is missing features that would be necessary to produce the same behavior, and I find it unsatisfying and confusing to use for aircraft. I instrumented my vehicle with code that captures llGetVel() and llGetOmega() 20 times/sec (rotated into the local reference frame), then uses llSetText() to display mean, standard deviation, and range once per second. What I discovered: Sigma (standard deviation) for local X can be very low (0.0 to 0.02) in level, unaccelerated flight regardless of whether the visual apperance is jerky or not. There is no difference. When it's visually smooth, sigma can actually be quite a lot higher, closer to 1, and it still looks totally smooth. This happens during accelerating and turning. Local Y's sigma is typically very close to 0 in either case. Local Z's sigma is typically very close to 0 in either case. All three axes of llGetOmega() are always zero unless the aircraft is turning, climbing, descending, or yawing. If the statistical analysis is not enough of a smoking gun, here's another: When the aircraft is flying smooth, and I refocus the camera on my avatar, it starts getting jerky, like the camera is damping at some wild speed. Single-frame jumps of tens to hundreds of pixels along the axis of motion. The attached screenshot is the llSetText() stats output when the camera was jerky. Zero standard deviation in this regime + jerky visuals, vs. standard deviation WAY higher during maneuvers when the camera is smooth, provides strong evidence that this is a viewer bug. My code is invariant either way. My stats are invariant either way. When flying smoothly, refocusing the camera makes it do the jerky rendering thing. And sometimes it does the jerky rendering thing whether I do that or not.

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.

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/

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.

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.

Even with auto adjustment on very permissive settings (desired framerate=1, avatars only) and bandwidth at 6,000 kbps, the new viewer doesn't like to render objects until I'm practically right on top of them (maybe 3 or so seconds away) while flying. I've got draw distance set to 280 meters (higher than usual) and it's still doing this. I can see far-away land just fine. Once the objects are loaded, they will stay loaded unless I leave the area and come back (respecting draw distance), so this seems to be about the initial loading. (Edit: Nope, I'm seeing this even without leaving the sim. Flying through Bethel, I don't see the bridge until I'm within about 30 meters. In Rizal, the boat house doesn't show up until about the same distance as well.) This is not a good experience for aircraft, and I don't think it's fun with boats either.

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.