Henri Beauchamp

I do not see any stuttering in your video... Just FPS rates variations depending on the camera FOV and the amount of objects to render in it, which is perfectly normal. Watch the texture console (CTRL SHIFT 3) and look at the VRAM usage. It is likely that, when a lot of textures are around and you move or cam around, LL's viewer fails to keep everything in the VRAM (the console will then report 0MB free in VRAM), forcing the driver to start and spill GL textures and vertex buffers into the RAM, causing stutters, freezes, etc... Sadly, your only option is to switch to a TPV, since LL removed from their PBR viewer the possibility to adjust yourself the VRAM usage. Also, most TPVs offer a frame rate limiter, which you might want to use, to avoid FPS yo-yo and useless heating (and fan noise) of your GPU when it renders way above your monitor native Vsync rate (which is perfectly useless). If you are not adverse to the v1 UI, have a try at the Cool VL Viewer: I spent a lot of time (both programming and testing) to optimize it and prevent VRAM usage overshoots; it also got a ”smart” frame rate limiter which uses the ”free time” between frames to rez meshes and textures faster.

Stupid question, but did you check Windows' sound mixer while the media are playing ? Depending on your system audio devices, it might happen that the viewer cannot ”catch” the audio level properly for your audio output device, and then it must be done from the audio mixer of Windows, or even from some mixer your audio device vendor is providing with their drivers...

To be honest, and for being myself spending 95% of my SL online time in adult regions, I do not think any significant number of child avatars are roaming them (I could likely count them all on the fingers of a single hand in one year worth of SLing): also, most of the times I witnessed such a rare occurrence, they were either politely asked to change their look or leave, or were ejected by the region owner/moderators. I personally have no problem at all with the principle of adult region = child avatars forbidden. The only problem I have is to determine what a ”child avatar” is exactly... A change in the current policy, even if not more restrictive than the above principle could lead to another period of paranoid, knee-jerk reactions from land owners/moderators (or even any resident using them), with many non-child avatars being considered as ”too childish” to be accepted. I already experienced such an issue, back when the first child porn hammer struck, while my own avatar, even if young (and rather effeminate-looking), is/was definitely not a child (as tall as myself in RL, clearly identified as adult in the profile, never wearing childish attire, never playing childish anims (AO & Co), and always role-played as a young adult, never as a child, not even as a teen): I then had to leave a few regions I used to RP in, because of such knee-jerk reactions, which never happened again ever since, in the past 15+ years or so... But I guess I might be faced with the same occurrences again, now... 🫤

It happens that the parcel info arrives late (especially after login). Like many things in SL, you just need to be patient enough...😉 But when it happens, moving to another parcel will help to kick the server's ass and make it spit out the parcel info...

Since you are not adverse to the v1 UI (Singularity, Genesis), give a try at the Cool VL Viewer: it got better VRAM and RAM management algorithms that might help you to keep things in line (for VRAM do have look to the Preferences floater, Graphics tab, GPU/GL features sub-tab, and do read the tool tips for the settings there: they are worth a user manual).

What OS ?... For Linux, the main CEF library is in the lib/ sub-directory of the installation folder as libcef.so. For Windows it is in llplugin/ as libcef.dll. There are also other CEF files (IIRC, for FS, they keep them in bin/ for Linux, which is not very ”clean” a layout: my viewer got everything in lib/, but this involves telling Dullahan/CEF where those files reside), a couple *.bin files, *.pak files with most of them in a locales/ sub-directory, some other lib*.so (Linux), *.dll (Windows) libraries for GL/EGL/GLES/VK/v8/chrome...

The libremetaverse project is a library, not a full client: it is used to connect to SL or OpenSim servers, and got a simplified renderer too, as well as simple GUI building blocks (inventory, chat, etc), but you need to implement your own UI and logic around it. RLV is one such ”logic”, where you restrict things the user can do or see, at the client level. Radegast, which is using libremetaverse, does have RLV support implemented...

The Linux SLVoice client is deprecated and won't connect properly any more with the Vivox servers in SL. You need to install Wine and let the viewer use it and the SLVoice.exe Windows client to connect.

Please see this message of mine about the parcel ”no fly” flag... Yes, you would be flying, even in a no-fly parcel (since the latter only disables the UI to start flying, and only when not in ”Admin” mode).

The Cool VL Viewer v1.32.0.17 got a workaround for this and will actually log you in the same flying/non-flying state as when you logged out (also, this is a per-account setting in this viewer, unlike others which use a global setting: I fixed that silliness a little while ago).

Dullahan/CEF is using the OS' installed CODECs: Win11's ones are likely more up to date...

In fact, those spurious ObjectUpdate's messages have mainly been an issue with agent attachments, for C++ viewers. Gory details here (in paragraph 1). So yes, most TPVs do have code to ignore those bogus ”kill attachment” messages, in one form or another... However, the agent stays rooted to the region it arrived in, even if the departure sim says otherwise via a bogus ObjectUpdate: the agent only changes region on ”AgentMovementComplete” (which callback is process_agent_movement_complete() in llviewermessage.cpp), and therefore any position received from another region is ignored. You could do the same thing with Sharpview...

The ”no fly” parcel restriction is only ”enforced” viewer-side, and can actually be bypassed by enabling the ”Admin” mode (CTRL ALT V with most viewers). So, if you are flying before a TP, you will keep flying on arrival: the server won't have any say in ”flying” matters and follows what the viewer tells it via the ”agent flags”. Thus why this ”flying on login” issue is a bug, and why the viewer does not ”reflect” the flying status with its UI in this particular case.

Well, you can convert a prim-based builds to the LI system, and it is usually very worth it in term of parcel prims usage: once converted to a ”convex hull”, a non-tortured prim land impact is reduced to 0.5; convert it to ”none” (child prims only, not the root prim), and you might even reduce the total LI of the object further (though, it usually only affects the Physics cost, which is still a good thing for the sim health, reducing the Physics engine lag). The only caveat is that you must do the conversion in a place where you have plenty of unused LI (a sandbox is the ideal place for this), or you risk to see your object returned to your inventory should the LI algorithm go wild (it does happen, especially if the converted prim is a tortured prim) and suddenly causes the object LI to skyrocket (I have seen 30 prims objects exploding to a 200+ LI); for best results, ensure you start the conversion with the root object (changing its type from ”Prim” to ”Convex hull”), then continue with children, and as a rule of thumb (but there are exceptions too, depending on the prim actual usage/function/torture level) do not attempt to turn tortured prims to ”Convex hull” (but you may convert them to ”None” with many benefits, as long as you do not need them to collide with avatars). Sculpty prims, however, should not be converted (even as a child with ”None” type, they will always account for 1 LI and most of the time 2 LI or more). Once the conversion done, you can see very nice benefits in term of LI (sometimes 50%). Also, the LI is rounded in a 5/5 way (i.e. a an object with a 1.49 LI will account of 1 LI/prim in the parcel allotment, while an object with a 1.50 LI accounts for 2 LI/prims): by cleverly linking objects together (or on the contrary splitting some), you can lower your land prim usage, using this rounding to your advantage (i.e. maximizing the number of objects with a xx.49 LI)... 😜

The feature in question already existed ! Before this bug, when you were flying at logout, the viewer remembered it in its settings, and made you fly on next login... LOL, yes, good point !... Well, fixed (worked around) already in the Cool VL Viewer v1.32.0.17 I just released... 😜

Wild guess: a playful Linden's April fool ? 🥳

Workaround already implemented in the Cool VL Viewer for next Saturday's release. 😜

I have one novelty I noticed, but that I don't think will be listed in the release notes: On login (with any viewer), the avatars now always fly (*) Annoying... 🤪 (*) Until you click with the mouse in-world, at which point the viewer will update the flying state; normally, the avatars should never be flying on login, and it is the viewer which sets the flying flag (if needed) and informs the server of this, based on a saved setting (the flying state is saved on logout in ”FlyingAtExit”)...

Most likely a race condition. I did not investigate, since I would expect from LL that they fix their own mess... Sadly, they currently seem busier pushing new features (which will of course introduce even more bugs), rather that fixing all the outstanding PBR bugs (moires on water with SSR and non-working water reflections, blue hue on shiny objects unless you hack EE settings beyond repair, broken shadows, broken alpha with shadows on, broken semi-transparent faces on legacy contents, etc, etc, etc...). 🫣

Precisely no... This is a new bug that only happens in PBR rendering mode (the fact I can switch between all three forward, ALM and PBR modes in the Cool VL Viewer allows me to be 100% affirmative on this): the old bug does have a workaround (that has been implemented for years too, in my viewer, including with an ”auto” mode, on login, TP and sim border crossing), but this new one does not have any other work around I could find, beside the OP's one (i.e. zoom out beyond draw distance, wait a few seconds, then restore camera to normal view). This is not to say that you got that bug in Sharpview: on the contrary, I do believe this bug is specific to LL's PBR renderer code (C++, shaders, or a combination of both, and most likely a race condition too).

The PBR renderer is especially sensitive to this... Probably a race condition in the occlusion code. Even with the Cool VL Viewer (which got a workaround for such cases, workaround which always work for its ALM and forward rendering modes), when in PBR rendering, I sometimes observe this phenomenon (and the ”Refresh visibility of objects” workaround is helpless in this case: only the zooming out of draw distance can fix it)... 😢

I don't have the sources, to start with...

It would likely compile just fine on a Linux aarch64 SBC (Orange Pi5B, Rock Pi5B, Raspberry Pi5, etc), and might run fine on them too, though at low FPS rates. With the sources (apparently not yet available), I could give it a try on my Orange Pi5B...

It will work fine (CPU and GPU are plenty powerful enough), but you might want to verify if you can expand the RAM (are there free slots left, or are all the motherboard slots already populated, because then it would mean buying 32GB (2x16) of DDR4 instead of an additional pair of 16GB (2x8) DIMMs if/when you want to update). 16GB is really a minimum for SL, nowadays, and you would be much more at ease with 32GB of RAM (the viewer alone can easily consume up to 24GB of memory in heavy environments such as scenic sims with a gazillion of meshes and textures, or very populated places with dozens of avatars wearing complex attachments).

Well, given my account will be 18 years old in 7 months, I'd say I should not need any ”age verification” any more, not even today (unless you think I could roam SL while still a RL baby)... 👴🤣