Henri Beauchamp

See this post and this other one: both describe known ”glitches” and how to diagnose them/work around them.

Not sure LL's infrastructure and the servers can cope with logged in users that would switch their IP address during the same session !... If your load balancing causes a change of ISP when connecting to another server (such as the arrival sim for a TP), then things could get messy. My advice: turn off your load balancing and see how you fare in SL (or how SL fares for you)...

It might be a cache and/or network issue, then: either the cache for that mesh got somehow corrupted or the mesh data failed to download completely (and the corrupted cached asset entry got since erased)... Let's see if this issue reappears, and if it does, do save your viewer log for closer examination !

If it is indeed a RenderMaxNodeSize issue, you may try and provoke it by changing its default value for something smaller (divide it by two or four): if the trees vanish, you got the most likely diagnosis. Another (more random) way to provoke it, is to place several such trees close together (in the hope the viewer will add them to the same render group which will then overshoot RenderMaxNodeSize and will get evicted from the render pipeline).

I did not say that it should be kept forever at a high value. I am just trying to diagnose his issue... Also, it must be noted that when people see this happening (e.g. in high mesh count/density places, when you get closer to some objects and they suddenly vanish), it is often wrongly diagnosed as a LOD issue, and people increase the LOD factor, making the issue only worst (since a higher LOD means even more vertices)...

This might be a complexity issue: when mesh objects got too many vertices, they may get evicted from the render pipeline (along with their render group, meaning several other objects may disappear as well). Try this: increase the ”RenderMaxNodeSize” debug setting value (say, to 256000 KB), and see if the trees reappear... Here again, the Cool VL Viewer got a work-around for this issue (governed by the ”Mesh objects boost factor” in the Graphics preferences).

I got the same issue in the past, just after the AWS ”uplift”... It ”resolved by itself” (read: AWS fixed their network/routing) after a few days... And for the past three weeks, I am seeing in the viewer logs another thing I saw back in that time as well, namely the ”event polls” failure warnings for some (not all) neighbouring regions... It does not bode well...

What happens if you right-click at the place the ”invisible” animesh trees are ?... There is a known bug in all viewers, that causes some objects not to appear after login, TP or region crossing, and right-clicking where they should be (i.e. selecting the objects) suddenly causes the objects to pop-up into existence... This is likely a race condition somewhere in the code (between the avatar position/region setting, the viewer object cache data updates, the render pipeline culling or rebuild queue... Probably one or several of those). FYI, the Cool VL Viewer got a workaround for this issue (that I even perfected in today's release), which auto-selects all rezzed objects on login, TP and region crossing, so to make sure all objects appear (and in the right position since some objects may appear in the wrong position after a sim crossing, for example). It also got a manual trigger for that ”objects rebake” of sorts: ALT SHIFT R.

It just got rolled to my home region (and a few others around mine in Zindra), which was so far running Second Life Server 2021-11-11.565737... Perhaps in reply to the concern I raised during the last Simulator User Group meeting about failed event polls in neighbouring regions, but I am still seeing these... Or perhaps was it rolled to regions that failed the first restart after the rolling release (mine and a few others around it were affected and took 3 hours before they were finally restarted).

Release notes for 2021-12-10.566713 are not accessible (access denied)... 🙄

You mean something like this ?... 😜 The textures in this test sim are not large enough to saturate the bandwidth... Note how fast the Cool VL Viewer rezzes it too (about 15 seconds, starting the timer at the ”Loading world” login step), here on a 9700K @ 5GHz with 1Gbps FTTH Internet link.

Same thing with Radegast: Login response failure: Notation LLSD parsing: Unknown type marker 'S'. I had a support chat with TJ who escalated the issue to the relevant team... Wait and see.

NFT = New Form of Theft ?... 🤣 EDIT: or (better ?): Nefarious Fake Trading

32 bits viewers are a thing of the past. Period. Even I, who is known for being very conservative with regards to ”novelties that are not so great”, ended up abandoning completely 32 bits platforms for the Cool VL Viewer. The reasons are many: A simple poll (and the subsequent abandon of the 32 bits compilation support which did not raise any protest) demonstrated that not a single user of my viewer (which is known for being used by many people with ”old” hardware, for it is easier on them) is missing it (i.e. no one was using a 32 bits Cool VL Viewer when I dropped support for 32 bits). All viewers need SSE2 support, and now (because of CEF v89+) SSE3: the latter is not available on any 32 bits CPU, and very few 32 bits CPUs offered SSE2. Even when running on a low memory system, and even though the 64 bits viewer binary does use more memory than the 32 bits binary one, the 64 bits binary is way stabler. Why ?... Because of virtual address space fragmentation. Keep in mind that, even on a 64 bits OS, the virtual address space is limited to 4GB for 32 bits binaries (and 3GB or even, horror, only 2 GB (for some 32 bits Windows systems) for programs running on a 32 bits OS: the rest is reserved for the kernel memory). Whenever the virtual address space gets too fragmented, some memory allocations will fail, because the memory manager will be unable to find a large enough contiguous *virtual* address space block. This got nothing to do with physical memory fragmentation (which is easily solved via MMU paging), but it affects all 32 bits programs (while the 64 bits address space being virtually illimited, it is never a problem for 64 bits programs). Over time and as the session lasts, your 32 bits viewer will end up crashing (or, in the case of the Cool VL Viewer and thanks to its memory safety checks and allocation failure fallback code, to notify you to please relog at once before it will crash !). The boost::fiber code now in use in all modern viewers (and which replaces a LL-brewed/forked boost::dcoroutine class) is totally bogus under Linux 32 bits and crashes immediately the viewer (so, I had to maintain a dual-path code just for 32 bits, with the use of an outdated boost library for it). Since, obviously, no other project is using boost::fiber in Linux 32 bits code, no one cares about that (or those) bugs... Don't take me wrong: 32 bits viewers were a better solution in the past (when there was no or few meshes, no materials, no Bento avatars, no animesh, etc, when having/buying 8GB or RAM was a luxury, and when some 64 bits CPUs were actually faster at running 32 bits code, which is no more the case), but now, they are simply deprecated. Conclusion: install a 64 bits OS and use a 64 bits viewer, even with only 4GB RAM: you will get a stabler SL experience, but of course, you will have to limit your texture memory to something reasonable (512 to 1024MB at most), and draw distances at 256m or less (depending on the complexity of the scene and the amount of neighbouring sims).

Memory allocations failures may happen if: You are using a 32 bits OS (time to upgrade, really...) or a 32 bits viewer on a 64 bits OS (this is totally silly: use the 64 bits viewer version !). If, while using a 64 bits OS and a 64 bits viewer, you do not have enough RAM+swap space and are demanding too much to the viewer; e.g. setting a very high VRAM texture amount (keep in mind that the viewer will use about 1.5 times of RAM for textures as you what set for the VRAM), or draw distances beyond 256m in sims with neighbouring sims all around (such as in main land). Not all viewers are created equal (mine is using less RAM and got many memory allocation failure checks and fallback code paths that prevent abrupt crashes), but all will fail at some point, when your system cannot cope with the amount of RAM they need due to the settings you are using. Nowadays, 8Gb or RAM is pretty much a minimum, especially in complex rendering situations. 16Gb or more is recommended, if you want to push the settings upwards (especially the draw distance and the texture memory).

I did add the ”sticking out tongue” smiley for a purpose... I'm quite the teaser, you know. Don't take it as an attack, for it is not ! 🙂 Err... On my calendar, the year counts 52 weeks, not 56... 🤣 As for the viewer branches, I do not always maintain three in parallel. The legacy branches only exist for a while whenever a breaking change happens in SL for ”old hardware”, such as the v1.19 branch (with 90 releases), which was the last up to date pre-Windlight viewer available to log into SL (many graphics cards could not do Windlight back in those days)... As for the experimental branches, they only exist when new features are introduced, that do need a lot of testing and debugging; the last such branch was for EEP (and the integration of the dual (WL+EE) renderer now available in my viewer). Finally, it also happens that I do not release a viewer on one particular week, whenever too few things happen on the coding front in SL. AFAIK, you and me are the only TPV coders/maintainers working alone on ”our” viewers, and our viewers are unique in the SL ecosystem, for they both provide unique features not seen in any other viewers. Believe me, I do respect you as a viewer developer, for I know first hand what it entails in term of dedication and perseverance ! But when I saw the breakdown of the years in days, hours, minutes and seconds, I laughed my ass out and just could not resist adding more (and bigger) numbers. 😜

Wow... Useless stats and shameless bragging !... I can do it too ! 😜 Let's see... Cool VL Viewer fact sheet: - First Linux TPV. First still maintained TPV (it was the third, fourth or fifth released TPV, since there was Nicholaz Beresford's and Dale Glass' Windows viewers, and perhaps a couple others, before I released publicly mine, but none of them survived). Only still maintained (and kept on par with LL's current viewer features) v1 UI viewer. - First (public) release on 2007-11-16: that's 14 years and a few days ago. I joined SL on 2006-10-06 and I made my own (private) viewer as soon as LL opened their viewer sources... - Number of releases: I lost the exact count because of the various branches (up to 3 branches maintained in parallel) and releases per branch to count before I opened my own forum to announce them. For the ”stable”, ”experimental” and ”legacy” releases starting from v1.19 (i.e forgetting probably a couple dozens in the various v1.18.* branches), here is the count I just made: v1.19.0/1/2: 90 v1.22.11: 11 v1.23.2/3/4: 18 v1.23.5: 37 v1.25.0: 41 v1.24/25: 42 v1.26.0: 32 v1.26.1: 9 v1.26.2: 26 v1.26.3: 9 v1.26.4: 99 v1.26.5: 22 v1.26.6: 21 v1.26.7: 21 v1.26.8: 94 v1.26.9: 37 v1.26.10: 21 v1.26.11: 21 v1.26.12: 50 v1.26.13: 19 v1.26.14: 14 v1.26.15: 13 v1.26.16: 16 v1.26.17: 14 v1.26.18: 36 v1.26.19: 38 v1.26.20: 50 v1.26.21: 17 v1.26.22: 67 v1.26.23: 19 v1.26.24: 24 v1.27.0: 4 v1.28.0: 20 v1.28.1: 10 v1.28.2: 48 and counting to date... That's over 1100 releases to date... So... What did I win ?... A cookie ? 🤣

No... That is why, for the past 14 years, you have had (and will keep having in the future) the good old (and totally productivity and screen estate geared), v1 UI in the Cool VL Viewer... 😛 Firestorm simply reimplemented (part of) the v1 UI floaters, among which the search one. It however lacks the ”All” search tab (it only implements it in its web flavour, not in the old search style). There are quite a few useful things that do not exist any more in v2+ viewers... Terrain-only tiles tab in the world map, chat input line, etc... Not to mention, on the renderer side, ”Classic clouds”, animated trees... All of which you still can enjoy in my viewer. As for the new-new web search (since this is actually the 3rd web search version), here is my take on it (posted as a comment to Inara Pey's related blog post) : Sadly, and unlike what LL did when they updated the first web search version to the second, they do not provide a way to use the old style search (for years, the Cool VL Viewer had a ”Use new search” check box in its web search tab, to allow switching between the two)... As a result, and for the next Cool VL Viewer release, I reworked the web search tab in the Search floater (it is now combo-less, search input line-less, with just the ”Back”, ”Forward” and ”Reload” buttons) and switched to the old v1 ”All” search for results when using the search input box in the status bar... Sadly and once more, LL opted to keep the new search secret till released, instead of communicating with viewer developers: the result is this total mess... Congrats, LL ! 😞

Or that is not a v1 UI viewer... :-P

The map server base URL is transmitted to the viewer in reply for the ”map-server-url” request parameter sent by the viewer on login; i.e. it can change over time. Some viewers (mine is one of them) log it in their log file (e.g. ”INFO: LLStartUp::idleStartup: Got map server URL: http://maps-cdn.agni.lindenlab.com/”).

As I described in my previous post, this is a viewer bug, that so far has not been addressed by LL and is present in TPVs using LL's code for the Marketplace. Try the Cool VL Viewer, which uses a modified (and fixed) code...

v495.x (x=any, so far, 44 included) got a lot of problems, such as performances issues, suspend/resume, sync, Vulkan, Wayland, dbus, etc... Just have a look at NVIDIA's forum. The latest is not always the greatest.

Under Linux, the current NVIDIA driver v495 (”new feature branch release” driver) got issues. Keep using v470 (”production branch release” driver) for now...

The reason for the ”small” size of the part is that the rest of the improvements (rigged matrix caching) were already implemented by me in the Cool VL Viewer months ago and with an even faster algorithm... 😛 The only improvement (three lines of code but it makes a very obvious difference) brought by LL's latest code over mine, and which I backported, is to avoid uploading repeatedly and uselessly the (cached) rigged matrix into the shaders... Which would happen hundreds of times per second for each avatar wearing a rigged mesh (depending on your frame rate).

SL's privacy agreement only rules out your privacy with regards to SL services, not what you can or must not do with other residents' private matters... The chapter 6 of the TOS (conduct by users of the service) makes it however very clear, in 6.1: Emphasis mine. The Community standards (which rule out how you shall behave and what you shall not do in-world) also make it very clear: Emphasis mine again. Now, giving the excuse that your relay warns the user ”after the very first message a user chats within it's range” is not enough: what about that first message (which, as I understand it, gets transmitted before the resident could see the warning) ?... What if the user wishes to chat freely (chat is not a group that you join after reviewing its charter and agreeing with it) and yet not gives their consent to see their prose transmitted outside SL ?... What if the user cannot see this warning (e.g. on a second visit) or forgot about it, because they muted you for having annoying objects that keep spamming them with object IMs ?... Information of the user and explicit consent given by the user are not the same things ! I am sorry, but the chat (*) relay you are using is against both the TOS and the Community standards. Period. ___________________________________________ (*) It might be OK for a group, as long as the information about the relaying is given in the group charter (by joining the group, the user gives their consent).