🪰 Viewer Bug Reports

In the texture/material properties of an item, the scale, offsets and rotations are set in the edit window. However, when any PBR material is applied, it resets to the default values of 1.0x1.0, 0u/0v, 0 degrees, cancelling any previous settings. This makes it very tedious to switch between different PBR materials. This is a request to make the scale/offset/rotation of an item PERSIST after they are set in the edit window when a PBR material is switched, instead of defaulting to 1x1, etc. with the new material, as is the case when any blinn-phong texture maps are changed.

"If the 2D don't work, the 3D don't work". I was at Sci Fi Con 17. All day long, no matter how many or how few avatars were on a region, textures took ruddy ages to load. Now one might say "There are so many textures at a big event it just takes a long time." But I'd walk into an enclosed room... where textures should be limited, yet the vendors on the wall just sat there and sat there and sat there. Textures RIGHT NEXT TO ME fail to load. One can stand there and stand there and stand there... and they still don't rez. I would click on a texture and tell it TEXTURE REFRESH... and it would ignore that instruction. I first reported texture issues and bottlenecks back in 2005. Now my computer and graphics card is hundreds of times more powerful... and textures still load at a snail pace. I will say the same thing I said back then: There is a texture bottleneck on SL. (Or, several texture bottlenecks, and it affects EVERYTHING.) With respect, I'm not asking for an explanation, nor excuses. I'm making a simple observation: After 22+ years online, Second Life should be able to very quickly load 2D textures in an enclosed room. Is this not correct? I suspect there will be people all too ready to give reasons why textures load slowly. To any and all such reasoning, I have one answer: Second Life needs to make textures load quickly. There's no argument, debate, discussion or excuse to that simple statement. Users need textures to load quickly enough that we don't get bored standing in a store (waiting for vendor textures to load)... and decide to go do something else. Like Netflix. ;D Because that's what it is: Second Life vs Netflix. Users have options on how to spend their time. When Netflix can stream entire videos realtime, surely Linden Lab should be able to send 2D textures across the Internet... yes? As a note: I'm not going to debate nor discuss or argue with those who are always ready to argue on these feedbacks. The feedback is posted, I've said what I came to say... and I have to believe the vast majority of SL users will agree with this: textures on SL need to load faster.

The orientation of a prim is affecting its bump-map shadow effect (relief). An upside down prim seemingly inverts the effect, turning an emboss into an engrave. This is showing in Firestorm and LL viewer, which was updated moments ago. The effect is shown in the images below -First is a single prim 1m square -Second section is a 4x4 grid of 0.25m prims, rotated differently but textures aligned -Third and Fourth are the same things using Materials rather than Blinn-Phong, which do not have the issue The bug is the Second section showing differing relief amounts even though they are co-planar and same orientation. The difference here is the orientation of the prims themselves.

While Edit window is open, right/left click on an avatar and it will often select through them. This often includes your own avatar, especially if it's the base body (like BoM). Right click out of Edit will pretty consistently bring up the correct item for inspection. This is a typical way I check to see what another person is wearing, and it's especially useful if I need to check links for particular names or features. More often than not, this is for moderation or when a friend is asking for help.

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.

In Pony Play we have something called "Quick Jump" this is where you put a tick in the setting "Preferences > Move & View > Movement > Disable waiting for pre-jump and landing". As a ponygirl this is absolutely banned. However, I see the quick jump motion from time to time even though I don't have this option ticked. It usually happens if I'm doing a series of jumps in a row. This occasional missing of the prejump and landing animations can be seen in SL Viewer, FireStorm viewer Kokua viewer and Alchemy viewer. I see it least often when using the SL official viewer, however the fact that this occurrs in all viewers suggests it is a bug in the under lying code. Observations in the Pony community suggests that this has got much more worse since the PBR update. The time when it is seen is when you hold the jump key to do a series of jumps. This bug has also been reported in Firestorm: https://jira.firestormviewer.org/browse/FIRE-34049 Videos have been made of the motion: Not working as expected https://youtu.be/1r5fyyj847g Now working as expected https://youtu.be/5noQgxkKM7Q No change in preference were made during this test. Video recorded using Firestorm 7.1.9.74746 I repeat the same motion can be seeing using SL Viewer, Alchemy Viewer and Kokua Viewer.

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.

Repro: 1) Go to: http://maps.secondlife.com/secondlife/Fenfarg/4/124/36 2) Wait for things to fully rezz around you 3) Rotate camera around your avatar, to make sure everything around you is rezzed 4) Change environment setting to Midday (the new PBR version) 5) Stand around, and rotate the camera around for 30s or so. 6) Things will go weird black and white, (See Attached Image) 7) Change to any other environment setting like Midday Legacy 8) Change back to Midday 9) After 30s or so, everything will go dark again. Issue seems to be limited to this specific area. But I have seen similar things happen once in a while in other places around SL, this one however seems to be 100% reproducible. Reproduced on both Official viewer and Latest Firestorm.

Tp to http://maps.secondlife.com/secondlife/Le%20Monde%20Perdu/87/179/26 set settings to ultra Open Snapshot to Disk Set resolution to 7680x4107 Save (though it might take a few refresh/saves to repro) Results: Viewer crashes. This is a brand new high end pc, I should be able to take high resolution snaps Event Viewer log entries: Faulting application name: SecondLifeViewer.exe, version: 7.1.15.13558, time stamp: 0x6849ff57 Faulting module name: nvoglv64.dll, version: 32.0.15.7652, time stamp: 0x6824e4c4 Exception code: 0xc0000409 Fault offset: 0x000000000106e00d Faulting process id: 0x7DB0 Faulting application start time: 0x1DBDC4D62E127B4 Faulting application path: C:\Program Files\SecondLifeViewer\SecondLifeViewer.exe Faulting module path: C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_2c61c4d89b199ea8\nvoglv64.dll Report Id: 66e51c40-46cd-4dde-b2a3-bb0c54d9c00b Faulting package full name: Faulting package-relative application ID: --------------------------- A TDR has been detected. The application must close. Error code: 7 (pid=32176 tid=15888 secondlifeviewer.exe 64bit) Visit http://nvidia.custhelp.com/app/answers/detail/a_id/3633 for more information. ------------------------------ Faulting application name: SLPlugin.exe, version: 0.0.0.0, time stamp: 0x6849fd08 Faulting module name: libcef.dll_unloaded, version: 118.4.1.0, time stamp: 0x651cb3d9 Exception code: 0xc0000005 Fault offset: 0x00000000046433f0 Faulting process id: 0x53EC Faulting application start time: 0x1DBDC4D702FA691 Faulting application path: C:\Program Files\SecondLifeViewer\SLPlugin.exe Faulting module path: libcef.dll Report Id: d393b7a3-1a0b-40ac-8190-ef4d9c3a1e90 Faulting package full name: Faulting package-relative application ID: I have the full sl log and the full event viewer log entries if needed. This repros with the previous version, I'd been trying document the crash when this morning I was prompted to update the viewer.

PARTICLE RENDERING: Please fix the system default particle rendering. Specifically, the white dot default particle in version 6 (pre-PBR) is perfect, but now in version 7 it shows up as a white center with a visible square outline. An alpha issue I believe. This is the system particle which is called by default when no texture is added to the emitter. It is the basis for so many generic particle generators. So it would be great if LL could just tweak this little one for us please and smooth away the edges :) ! https://gyazo.com/97e97aeb4f68771c3c0c9791d444da9c