🪰 Viewer Bug Reports

• Use concise, precise descriptions• Do not include sensitive information. • Create a support ticket at https://support.secondlife.com for individual account issues or sensitive information.
Consistent "Service Unreachable" Warnings When Uploading 2K PBR Materials
Since June 10th, I have been experiencing a significant increase in "Service Unreachable" warnings while uploading 2K PBR materials exported from Adobe Substance Painter using the glTF PBR Metal Roughness workflow. The problem seemed to be concentrated between June 10th and June 12th, then improved and became limited to just a few random errors. Today, June 25th, the problem is back on my end. I have checked my internet connection, restarted my fiber router, and confirmed that my connection is stable, yet the issue continues to occur. I can log out and back in, successfully upload one material, and then immediately receive the warning when trying to upload a second one. If I bulk upload an entire material set, some materials upload successfully while others fail. Sometimes the material upload window gets stuck trying to save, and I can't close it because it appears to still be processing one of the texture maps. At that point, I have to relog. This issue seems to happen much more frequently with 2K textures. Since my UVs are optimized for that resolution, switching to 1K is not a practical workaround. Normal maps seem to be affected the most and fail more often, but on days like today I'm also getting errors when uploading base color and metallic-roughness maps. I know there have been previous posts about this issue, but I believe it continues to resurface and may still require investigation.
9
Ā·
SL Viewer
Ā·
tracked
Viewer-side scale interpolation does not finish
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).
2
Ā·
SL Viewer
Ā·
tracked
Stray Emission interaction between PSYS_PART_FOLLOW_SRC_MASK and PSYS_SRC_BURST_RADIUS
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
3
Ā·
SL Viewer
Ā·
tracked
Load More
→