Henri Beauchamp

LOL ! Yes, please, turn that sh*t off ! Everything that does deep packet inspection is likely to badly interfere with ”unusual” or uncommon network traffic, and I doubt very much Netgear made their router aware of SL network packets structure... Another potential issue would be a poor NAT implementation in your router, that would not be capable of maintaining high enough a number of simultaneously opened ports for the same IP: SL viewers open a lot of ports to the same IP, and if one socket gets closed because the router table got full and dropped it, you get a disconnection... This happened already in the past with cheap WiFi routers, and one could wonder why a modern router would not properly implement NAT with full 65535 simultaneous ports per connection tracking, but with IPv6 becoming more common, we might see NAT support (which is used by IPv4 only) become ”lighter” (read: incomplete) in modern routers firmware... You could diagnose such an issue by reducing the number of simultaneous connections settings in the viewer (simultaneous mesh and texture fetches in network settings) and the draw distance (to reduce the number of connected neighbor regions).

Thing is, a short disconnection/reconnection may happen and go unnoticed, e.g. if you do not try and move your avatar while disconnected (you won't perceive the ”freeze” then, since the viewer would continue rendering like if nothing happened), and the glitch duration is less than 2 minutes or so (exact timing depends on last packets received by the viewer from the server(s), and on viewer hard-coded timeout). But yes, in principle, it should happen to you both at the same time, should the routing or ISP link be involved. I'd have a closer look at the physical connection (plugs) reliability at the router level, then: maybe your Ethernet cables contacts are a bit worn out, and the new router sockets are less tolerant to this than your old router... This would explain you both experience disconnections at different times. Also, did you try and put your old router in place of the new one, to verify the latter is indeed involved or not ?

Did you check the cable then ? It may happen that an Ethernet connector got bad contacts... In this case, you will probably be able to see it by looking at the LEDs on the Ethernet connectors of your computer or router: if they go off, then there is a bad contact (try and titillate the plugs: if the LEDs flicker, it's the sign of a bad contact). This would also show in the system log of your OS (but since you do not say which OS you are using, I cannot point you at the right log): the Ethernet driver will report the link going down and back up after some time. In any case, the symptoms you describe correspond to a connection loss: it could be a bad routing or a congestion somewhere on the route to SL servers (seen during DDoS attacks), your ISP's link going down (two minutes without a link are enough to cause the viewer to time out), a bad cable, or a hardware fault... To confirm it is not specific to the viewer, try and load a web page in a browser as soon as you notice the ”freeze” in SL: if the site does not load, it's a sign the problem is indeed at the Internet link level.

It's a WiFi router. WiFi is extremely sensitive to waves reflections and absorptions; there are even some recent ”WiFi radar” applications to detect people and their movements in a room ! This is even more prominent an issue with newest WiFi standards employing the 5GHz band (same radio waves band as what some military radars are using !). With such routers, the radio link quality can be affected by moving your computer by a dozen of centimeters, rotating the router antennas, closing or opening a door, moving a chair in the room, or having someone moving in the room. My advice is therefore to try and find a better place for your router (one in direct view of your computer, if possible)... And if you want a 100% reliable connection, do not use WiFi: use a good old Ethernet cable !

Your problem is likely due to the fact that AMD OpenGL Windows drivers are bogus and report weird graphics memory amount figures; here, it reports 8GB of ”Graphics Card Memory”, while your PC does not have any VRAM: it must share the RAM between the CPU and the APU (AMD's integrated GPU). What happens is that with only 16GB of RAM, the viewer ends up exhausting the available memory and when it does, new allocations fail and cause a crash. I do not know intimately Firestorm, but there might be a debug setting for limiting the graphics memory to use for textures: limit it to something your PC can handle (1 or 2 GB at most)... You can also use the textures debug console (CTRL SHIFT 3) and see what the viewer is doing with the textures memory and the detected ”VRAM” amount... EDIT: I just had a look to FS v6.6.8. To prevent crashes, in the ”Preferences” floater (CTRL P), ”Graphics” tab, ”Hardware Settings” sub-tab, you need to un-tick the ”Enable Dynamic Texture Memory” check box, and use the ”Viewer Texture Memory Buffer (MB)” slider above it to adjust the memory usage by the viewer: I'd recommend starting with 1024MB. Note that you will get blurry textures (this is normal with so little memory available on your system), so you may opt to try and fit more textures by checking ”Enable Lossy Texture Compression” (but be aware that this causes a lot of frame rates ”hiccups” and degrades the detailed textures), or to reduce your draw distance to reduce the number of textures in your camera field of view.

That would depend on the differential speed: a native viewer performing 5 to 10 times better than an one running under x86_64 and OpenGL emulations would certainly represent a big incentive...

There might be some hope in the future to run viewers at full speed (i.e. in native ARM code) on M1/2 Macs, on the condition to replace macOS with Linux... 😛 See this article about progresses done with OpenGL drivers (Mesa) for Linux on M1/2 Macs. Once the OpenGL driver issue solved, you could grab the Cool VL Viewer sources and compile them for native ARM Linux (as already done with some ARM SBCs)...

No, these are just the controls for viewing the crosshair. The settings for the broadcasting of your look at/point at info are in ”Preferences” floater -> ”Input & Camera” tab -> ”Input controls”. Do explore fully the Preferences, and you will find most of what you need there. 😜 No, it works the same as in other viewers inventory context menus: it replaces what your avatar is currently wearing with the contents of the folder; the contents of the folder itself is not modified in any way. You may create new outfit folders out of what your avatar is currently wearing using the ”Create” -> ”Make new outfit” inventory menu entry, which opens the ”make new outfit” floater. You should still be able to wear those moved folders from the inventory context menu (”Replace outfit” entry, usually) in Firestorm and other viewers. Items in italics are actually inventory links: you may create such links with the context menu on an item and ”Copy” then ”Paste as link” in a folder, and find the item pointed to by a link with ”Find original”. If you need more info, please ask on the Cool VL Viewer forum; you will also find many of your potential questions already answered there (using the ”Search” feature).

Yes, you can, but reciprocity is enforced... I explained how it works in my viewer in this forum post. It's a v1 viewer: it does not need the v2 ”Outfits” folder (but may still use it if present). Any folder can be an outfit (and you are free to place your outfits in any folder fancying you; e.g. I use an ”Avatars” folder at the root of the inventory, where I place all my avatar forms/outfits in sub-folders): either right click on the folder and use ”Replace outfit” in the context menu, or drag the folder onto your avatar. Yep, it's the v1 inventory tree: nothing is hidden (well, you can hide the ”Marketplace Listings” if you want and, by default, the ”Current Outfit” folder, which is not user-serviceable, is also hidden: see the options in the ”Folder” menu of the inventory floater). Yes: in ”Preferences” floater -> ”Cool features” tab -> ”User interfaces” sub-tab (do read carefully the Preferences floater items tool tips: they are worth a full user manual). Since my viewer implements client-side scripting, you may also use Lua to add any button/function fancying you on a side bar: See ”Help” -> ”Lua scripting help...”. There are also goodies in the Advanced menu... Well, I largely modified the way the viewer keeps everything in line about texture memory usage, so to avoid freezes and other such annoyances... This might explain that it works better on your aging system. The Cool VL Viewer being extremely fast (I reach 1400-1500 fps in my skybox with ALM off, 700+fps with it on), it can push your GPU to the max pretty easily. Use the frame limiting feature ”Preferences” floater -> ”Cool features” tab -> ”Misc.” sub-tab: ”Frame rate limit” spinner. The frame limiter will avoid ludicrous frame rates and the resulting excessive power consumption from the GPU, and thus cause much less heating and much less fan noise. Limit your frame rate to your monitor's vertical refresh rate (usually 60fps, but maybe 120 or 144 for a gaming monitor). It is also coded in such a way that it won't slow down anything (and even on the contrary, speed up textures rezzing, since it will dedicate the CPU-side ”free time” to more decoding per frame).

This is just a disconnection, and you simply have no other choice than quitting the viewer (the program itself should never ever crash in this case: if it does for you, please report it with crash dump and logs, since even such crashes are unacceptable for me). Another good reason for choosing NVIDIA: their drivers are rock-solid and never crash for me, even if some versions have had rendering bugs (but reporting them on their forum gets them promptly fixed). But these are promptly fixed as soon as you report them to me. In fact, with the exceptions of when I am developing and testing new code, I never crash with my viewer, or more exactly, the rare occurrences I crash unexpectedly, I fix the corresponding bug immediately so that it never crashes anymore there. 😛 This is in stark contrast to what happened with 32 bits viewers in the past, when you always ended up crashing at some point, provided you stayed connected long enough, due to the limited virtual address space and its fragmentation...

For SL, you do not need such a powerful video card, and 8GB of VRAM would be enough for modern SLing, even if more is always better (especially when visiting textures-heavy places with large draw distances). The choice of a NVIDIA card is however indeed the best (way faster drivers than the competition for OpenGL and even Vulkan). I am currently using a RTX 3070, and it is underused (with this card, I need a faster CPU than my 9700K @ 5.0GHz). Do care about the CPU mono-core performances, since they currently are the bottleneck for viewer frame rates. Also, I would recommend at least 32GB of RAM (when pushed to its limits, with 256 or 512m draw distances and in textures/meshes heavy places, the viewer alone can easily gobble up to 24GB or RAM), with 64GB as a very comfortable option (this is what I currently have).

Yes, the profile picture ratio used to be (approximately) 4:3 in v1 viewers and TPV viewers that re-implemented (or kept) the floater-based profiles when LL decided to commit the mistake to migrate to web profiles, where the profile picture was displayed with a 1:1 ratio... And now that LL (finally !) understood their mistake and reverted to floater-based profiles in their own viewer, they kept the web profile 1:1 ratio... Annoying, isn't it ?... 🙄

You can, using the Cool VL Viewer to export and reimport it (once done, you should have the newly imported list used by any viewer, since it will have been updated server side). Proceed as follow: Launch the Cool VL Viewer, log in with the avatar you want to export the list from (let's call it ”Avatar1 Resident”), then log out. If you never logged with your second avatar (let's call it ”Avatar2 Resident”) with either the Second Life official viewer or the Cool VL Viewer, then log in now with it, and log out (this ensures the proper per-account directory is created). From the settings directory (~/.secondlife/ under Linux, %AppData%\SecondLife\ under Windows, not sure which under macOS), inside the per-account sub-directory (here ”avatar1_resident/”), copy the ”mute_list.txt” file, and use it to replace the one (or add it when absent) inside the destination avatar directory (here ”avatar2_resident/”). Log in with the second avatar using the Cool VL Viewer: the mute list (AKA block list for v2+ viewers) should have been updated (”View” -> ”Mute list” menu entry to check) with the entries coming from your first avatar. You may now log out (the list will get uploaded to the server by the viewer) and may now relog with any other viewer. It is also possible to replace entirely the second avatar mute list with the one of the first: simply set the ”MuteListIgnoreServer” debug setting to TRUE (CTRL ALT S to open the debug settings editor) before logging out from Avatar1, recovering its mute_list.txt file to replace the one of Avatar2, and logging in with it using the Cool VL Viewer (the mute list of Avatar2 is then set to the exact copy of the one of Avatar1), at which point, do not forget to reset ”MuteListIgnoreServer” to FALSE before logging out. When using Linux (this should work with macOS as well: just replace ”~/.secondlife” with whatever directory name macOS is using) and the Cool VL Viewer only, you may also make it so that all your alts share the same mute list thanks to this feature, and thanks to the OS symbolic file links support (something Windows never properly implemented). Proceed as follow: Copy the mute_list.txt file from one avatar's per-account directory (e.g. ~/secondlife/avatar1_resident/mute_list.txt) to ~/secondlife/mute_list.txt. Create a symbolic link inside every per-account directory to that mute list file. E.g.: cd ~/.secondlife/avatar1_resident/ rm -f mute_list.txt ln -s ../mute_list.txt cd ../avatar2_resident/ rm -f mute_list.txt ln -s ../mute_list.txt Then log in with each avatar in turn with the Cool VL Viewer and log out. It will cause the common mute list file to get updated with each avatar's mutes, and each time you update the list from one avatar account, it will propagate to the other avatars on next login. Caveat: when running simultaneously two or more instances of the Cool VL Viewer with avatars sharing the mute list, the latter will be updated with the list currently known by the last logged out session, so you might temporarily miss a recent update to that list (but it will get resynced on next logins, eventually, since the server side lists are kept separate and used to update the mute list file as well with missing entries).

The GTX 660 and the Radeon HD 7000 have been released in 2012, so this should really not pose any issue for PCs equipped with a dGPU. Intel Gen9 (Skylake) was released in 2015, so PCs with just an iGPU would be the most impacted by the abandon of OpenGL in favor of Vulkan. You must also take into account that the upcoming PBR viewer will require at least the cited GPUs to work at acceptable frame rates; forward rendering got removed from it, and older GPUs, such as the GTX 460 or equivalent, are very bad at rendering in deferred mode (ALM now, PBR tomorrow)... I can only speak for myself, but I will likely make a poll on the Cool VL Viewer forum when the time will come, and if any user without a Vulkan capable hardware shows up, I will perhaps maintain a legacy OpenGL branch for some time...

No, this bug still plagues some (many, all, depending on traffic, perhaps ?) simulators (come see in my home sim, Hunburgh, if you want), and does not depend the least on what viewer you are using. It appears about two days after the last sim restart (and as a result my region gets restarted twice or thrice a week).

Chat excerpt from last Server Users Group: Feel free to nag LL harder about it, since this bug is now over one year old ! 😲

I actually considered implementing a Lua function for it... It was a (long) while ago, and I do not remember all the gory details which made me push the idea farther down my ”ToDo” list, but chances are they are related with how touch-events are dealt with, between viewer and server (asynchronous tasks are involved, with network messaging, which, while not impossible to deal with, do complicate things).

There is already an ”HUD objects scale” settings in viewers, and while it applies to all worn HUDs, nothing would prevent to make it a per-HUD setting (based on the HUD inventory name, for example). That won't be hard for LL to implement (the viewer name is provided to the login server: it's just a matter of setting a flag on the connected avatar as a result, and make it available to scripts). I really think this is an over-dramatization, since I do not see LL abandoning desktop PC SLers any time soon, even in the event of a massive mobile viewer adoption. Totally wrong ! With this principle, arts won't exist at all, buildings would all be of the same model, etc... And innovation could not even exist ! Again, I do not see the mobile viewer and its future users as a menace for existing SL contents, features, and users ! Much to the contrary, I see it as an opportunity to develop SL in new ways, that will benefit everyone.

While I am personally not interested at all in a mobile viewer (being the old fart I am, I do not even own a smartphone; perhaps I'd need a fartphone ? 🤪), I am nonetheless quite happy that LL is finally developing one ! Why ? Because, let's face it, SL urgently needs a way to attract more users to survive. LL cannot only rely on old time SLers to keep the business going. The mobile platform, while quite limited and imperfect for enjoying the full range of activities SL offers (I really don't see how you could para-RP on a smartphone, for example, or build, or script...), will give an opportunity for younger and/or less ”geeky” users to come to SL, and stay (the user retention has always been a BIG issue in SL). So yes, there will be newcomers with different views on what SL is to be used for, but we should not fear it, and on the contrary embrace it as a chance to see SL strive and develop in the next two decades, instead of slowly dying before a foreclosure... I'm not worried: SL is big enough for expanding the diversity of its usages without predating existing ones. Long Second Life !

Vulkan, yes. 😛 ”Next year” was just a vague mention. I won't bet on it, even if I am looking forward to it. Between the PBR viewer (and a few more months needed to finalize it) and the mobile viewer, I bet LL's programmers got enough work for quite a few months, before they can dedicate their time to such a big task. As long as you got a Kepler (GTX660) or newer GPU for NVIDIA, or a GCN (Radeon HD 7000) or newer GPU for AMD, or a Gen9 (found in Skylake) or newer iGPU for Intel, you are good to go. Yes, with likely a threaded renderer, meaning the CPU single core performances bottleneck would disappear...

It shows that your texture memory is under high pressure (bias is very high, at 4.5, for a maximum of 5.0, meaning the textures must be quite blurry since decoded at a lower resolution to fit the 384MB of max bound textures). I would bet this is LL's viewer and its old 512MB maximum for the texture memory setting (which is quite low for modern graphics cards that got gigabytes of VRAM)... But this is not really a worry as far as freezes are concerned (those would happen when the VRAM is full but here, ”GL free” shows 8700MB, so that's fine). In conclusion, I doubt the freezes are due to the hypothesis I first made (but you still can have a look at the texture console when they happen, to see if those figures get worrisome). From the Windows task manager, you should be able to see the GPU usage figure, per process... For more detailed info, you could use (from a terminal) nvidia-smi.exe (/Program Files/NVIDIA Corporation/NVSMI/nvidia-smi.exe), which should list the VRAM usage, per application. EDIT: I just saw this article about a bug that could cause high CPU usage in NVIDIA driver v531.18, so you might want to try the former version of the driver, or reinstall v531.18 without the telemetry (which would apparently be the culprit); NVCleanstall can do that for you...

Here is, for the record, the question I posted via the form: When I joined SL (2006), we could build everything with just the viewer build tools and a very basic texture editing software. Nowadays, short of using hyper complex software such as Blender, we cannot build any more modern contents (and this is going to get even worst with PBR materials); we urgently need some in-viewer tools to perform basic mesh modeling (with, e.g., pre-made basic mesh prims and a way to model them like clay, or a mesh hull generation tool that would create an optimized mesh hull out of a SL-prims based build), and materials texture maps generation (and baking, for the compatibility diffuse map). Is there any plan to bring this in the future, or will the Sansar mistakes be repeated and contents creation reserved to experts and professionals ?

What is the textures console saying (CTRL SHIFT 3) ?... Bias ? Bound GL textures ? VRAM usage ? This is a wild guess, but it looks like the VRAM getting full and spilling over the RAM (causing second-long freezes). FS (and LL, for the PBR viewer, at least) recently changed how they account for textures memory usage, but it may cause issues that were not previously seen happening... Also, try the Cool VL Viewer (it got fixes and different algorithms to work around such issues). There was an issue with some NVIDIA drivers and Discord, but it affected NVIDIA RTX30* cards only, and got fixed in their recent drivers (your 531.18 version should be fine). Yet, you could have a look at the GPU frequency and VRAM usage (per application) when the freezes happen, to see if any similar issue would be arising...

This problem is rather most likely due to bad/insufficient virtual size re-evaluation as the camera FOV changes (only a small part of the texture virtual sizes are reevaluated at each frame). Try the Cool VL Viewer (I reworked the texture fetcher and cache quite a bit): you won't see this issue, unless a texture got somehow corrupted (it happens, sometimes, due to network issues), at which point you still can force-reload it (right click on object and press CTRL SHIFT U). I also implemented a feature to load textures at proper resolution faster when moving around: ”Advanced” -> ”Rendering” -> ”Textures” -> ”Boost proportional to active fetches”. And you may also ”Boost textures fetches now” manually (CTRL B), which also happens automatically on login and far TPs, to rez the world hyper-fast.

Unlike what you are suggesting, the viewer does use the full range of LODs of JPEG2000 textures: this is thanks to this mechanism that it is able to use so little memory, when compared with what would happen if it had to display all the textures at 0 discard level (i.e. max LOD/full resolution). And yes, it makes a HUGE difference at both the RAM and VRAM consumption level, because it basically means that for each increased discard level, the displayed texture is four times smaller in size (pixels height and width are both divided by two at each level). E.g. a 1024x1024 pixels texture (as defined by the builder of the object using it) can therefore be finally used at 512x512, 256x256, 128x128, etc, depending on how important to the camera it is, i.e. how large is its ”display area” in the currently rendered scene; at 1024x1024, the (decoded) texture uses 4MB of RAM and 4MB of VRAM, while at 256x256, it only uses 256KB... If you want to see what would happen if the viewer were to load the full res textures, enable the ”TextureLoadFullRes” debug setting, and get ready for a crash (unless you are in a place where there are not too many textures), because the memory consumption will soon skyrocket, till your RAM and VRAM are exhausted. Also, the viewer is ”clever enough” to use HTTP range requests so to avoid having to re-download the low LOD part of the texture files (i.e. the already downloaded part) when it needs a higher LOD for it, and its textures cache is used intensively to avoid and re-download a texture when increasing its discard level to make room in memory for another, more prominent texture in your FOV; instead, the already cached raw texture is fetched from the disk cache and only re-decoded at a lower LOD.