Henri Beauchamp

There has been an ”all attachments in the butt” age (back in 2007, almost at each sim crossing), that's for sure ! 🤣

Yes, this is what you get whenever the viewer cannot render every frame at the set limit (it can prevent faster frames, but obviously cannot speed up slow ones). This said, you will notice that the limiter does work by preventing the frames to be rendered too fast (no red dot seen above 63fps or so, the +3fps inaccuracy being due to the sleep() accuracy itself, which is precise at -0/+1ms or so); this does limit the jitter in the frame rate despite the fact the scene is ”too heavy” to render at a stable 60fps rate. This other number is averaged over a second or two (depending on the viewer), so it is less accurate than the one found in the Statistics floater.

No one planned for it and this is therefore not an accomplishment... 😛 No, it is not, and will never be unless some day, the rendering is entirely done in a secondary thread (or set of threads) dedicated to it. The problem is that the main viewer thread is used both for rendering and for all ancillary tasks the viewer needs and that cannot be pushed to threads, because the various steps need to be done in order until a coherent and non-varying (i.e. not modified by other threads) set of data is available for doing the rendering. These tasks range from updating the objects data (based on what is sent by the server), launching the fetching of the various assets data (meshes, textures, etc) by sending requests to other threads responsible for their fetching, recovering from other threads the tasks that have been completed since the last frame, etc, to doing non-rendering related things such as updating your inventory, playing sounds, exchanging events with the OS, etc... The result is a totally random repartition of the tasks and their duration at any given frame. LL and TPVs developers have been working to reduce the frame rates ”hiccups”, by pushing more tasks to threads (I recently pushed LLVOCache file writes to a thread, for example, in the Cool VL Viewer, meaning many 10-500ms ”hiccups” suppressed, when you cross sim borders or TP). Alas, not everything can be smoothed out. Another thing you may use to reduce the hiccups occurrences, is to limit your frame rate with the frame limiter (provided your viewer got one that is not just the lame VSync trick): if you got a 60 Hz VSync monitor, limit your frame rate to 60fps with the software limiter of the viewer, and your should experience a much smoother SLing... Here is what I get with 60fps-limiting on in the Cool VL Viewer in my parcel: Its fps-limiter is fine-grained and measures the time each frame needs to render, then performs supplementary iterations of any unfinished ”ancillary task” (texture prioritizing, fetching, decoding, caching, for example) in 1ms time slices (sleeping the CPU by this amount of time when no work is available/completed by other threads) until the required minium frame duration is reached. But if, in the same place, I let it free-running, then I get the classical fps ”random” distribution:

If the ALT SHIFT R workaround (or ”Advanced” -> ”Rendering” -> ”Refresh visibility of objects”) does not work, then it is most likely an issue with missing data in the interest list sent by the server... You (normally) do not need to relog to work around it: provided you disabled the zoom restrictions (”Preferences” floater -> ”Input & Camera” tab, ”Camera” sub-tab, ”Disable camera zooming constraints” checked), simply ALT-left-mouse-button-click on a nearby object and zoom far beyond draw distance (i.e. until nothing shows on your screen) by moving your mouse backward (with the left button still pressed), then stay like that for 20-30 seconds or so and press SHIFT ESC to bring back your camera. The server should then send again the object data as the viewer reports its new FOV to it, and the missing objects should appear...

They could do it once, but not twice with the same merchant (not with me, at least)... You could also limit the refund period to 24 hours.

Things would be way simpler if SL was to offer a way for copy-ok no-tfr items you bought to be transferred back to their creator, with the insurance for the latter that no copy is left in your inventory... In this case, I would personally, as a SL merchant, gladly offer full refund service for my products (which are all copy-ok, mod-ok and no-tfr). Note that this would be a totally feasible (server-side) feature...

Liar ! 🤣

This, and other issues (jerky mouse, bad window position saving, and several others) are the reasons why I kept the pre-performance-viewer code for LLWindowWin32, that is, I did not push the Windows events processing to a thread (which does not even bring any visible speed benefit at the frame rates level)... You might also want to have a look at the modifications to the thread pool code I made for the Cool VL Viewer, because there are also many shutdown issues there... and also issues with multiple-threads pool startup.

SLPlugin.exe is crashing (APPCRASH in your first screen shot, and BEX64, which is an executable stack prevention issue, usually caused by an ”attempt” to execute code on stack, which may randomly happen during crashes). CEF is the Chromium Embedded Framework browser that is used by the viewer as a plugin (also launched via SLPlugin.exe) to display web pages (web search, web avatar profiles, Marketplace, various web-based pages such as Wiki, help, account settings, etc), or web pages on a prim (including most SL TVs). CEF is itself crash-prone, so it is not all that surprising you see it crashing SLPlugin.exe (which loads CEF as a library to execute it) from time to time. Other suspects are corrupted streaming media that may crash the media plugin (VLC for all viewers but mine, which uses gstreamer instead), which is also ran via SLPlugin.exe...

Wow, LL did update these, at (long) last !... Sadly, the Linux requirements are all wrong: Hey, LL, wake up !!! It's been years that 64 bits Linux viewers have been available, and many months no more TPV bothers providing 32 bits Linux builds. You do not need any 32-bit compatibility environment installed (not even for SLVoice, which most TPVs now run in its Windows 64 bits incarnation under Wine, by lack of an up to date Linux SLVoice version). Nope !... Linux viewers need SSE3 minimum because of a newer CEF version (currently at 108 and soon 109 in the Cool VL Viewer Linux builds) than in current Windows/macOS LL official builds, but the latter will soon need SSE3 too, when their old, bugs and security holes riddled CEF 91 version will finally get updated. Also: The Linux TPVs are compatible with all Second Life features, with one exception: the path-finding capsule displaying, that requires the Havok proprietary library. Could we please have a Linden fixing these misleading Linux ”requirements” ?

Note that the ”creator” of an item/object might not be the person to hold responsible (a mod-ok object could be modified by a griefer, made no-mod, and sent to you, and the creator name won't change, even if the original object was perfectly safe and legit while the modified object sent to you is nefarious): the ”last owner”, on the other hand, is definitely the field to look at since this is the person who sent you that object.

From the dialog screen shot, the listed executable path, and the OS version number, it is pretty obvious it is Windows 10... 😛 There are other questions to ask: Is this crash happening as a result of the usage (or closing) of the CEF browser plugin ? If not, is this crash happening in a specific place in SL and what media are available/playing there ?

This is a money debit/credit permission request for a scripted item: you do not need to ”Open” such a scripted item to be asked for this permission. Vendor items are of course using this permission so that their script can work, and from your screenshot, this is a Capservend vendor, so it is not surprising at all that it asks for this kind of permission. This is the problem, and if it is not a vendor you bought, you should indeed be wary about such objects: a griefer could just as well send you a scripted object disguised as a well known vendor and steal your money as soon as you give it permission. So, your reaction was quite suitable if you don't know where or from whom this object came from. You cannot see the objects properties with the Edit tools floater when this object is no-modify (like this one) and you are not its creator. To see an object's creator for an item in your Inventory, use the ”Properties” entry in the context menu for the inventory item in question. To see it for a rezzed object, use the ”Inspect” entry in the context/pie menu for that object. This is a viewer-side permission dialog (it is orange in v1 viewers to easily distinguish it from blue menus of scripted objects; v2+ viewers menus are much less explicit in this respect). It is safe to ”Deny” it, but closing it works the same.

It uses basic C-library calls (or boost libraries ones, in some viewers such as LL's, which might actually prove to be slower), which are indeed fast enough for such a small amount of file read/writes as seen in the viewer (we are not in the same order of magnitude as what is seen with database servers, for example), especially once you got those file operations pushed to a thread. This said, the use of io_uring/IOCP could (slightly) improve things (but requires that your file operation can indeed be threaded/async, meaning it won't help for synchronous reads/writes still sometimes needed in the viewer main thread)... Being an SSHD, you may encounter two slow-down issues: 1.- When the SSD storage part of the disk is full, the controller will write to the hard disk platters instead, causing a noticeable slow down in file operations. 2.- When the firmware managing the SSD storage part is not using the TRIM command after a sector gets erased, subsequent writes to that sector will be slower. It is easier to do proper TRIMing with genuine SSDs, since this can be configured at the OS driver level. For the viewer cache, and provided you got enough RAM (32GB or more), you could use a RAM-disk instead, which would spare you any slow down and would save your SS(H)D endurance.

”Modern” CPUs (and by ”modern”, I mean all CPUs models released in the past 20 years or so) have an auto-throttling mechanism protecting them from damages due to overheating. A badly cooled CPU will just run slower... Recent CPUs (Anything-Lake for Intel, Zen 3-4 for AMD) are also factory-overclocked and heat up insanely fast (and up to 95 to 105°C, depending on the CPU generation and ”absolute maximum ratings”) and, more often than not, are hitting that throttling limit: this is considered ”normal” operating conditions by their maker... So, no, you do not risk damaging your CPU via overheating. However, any piece of Silicon does age, and its performances degrade over time. This aging is faster as the operating temperature increases, but also depends on other factors (such as maximum local currents for the electromigration effect, or the operating voltage for charge trapping effect, etc). I so far did see the effect of such aging on my good old Sandy Bridge 2500K that I operated during 7 years (and 18H/day in average) at an overclocked frequency of 4.6GHz (i.e. +900MHz over the rated turbo frequency) locked on all cores: after all these years, it started hanging at idle (!) time, roughly once per day, and I had to reduce the frequency to 4.5GHz to prevent this from happening... Today, and yet more years later, it is still working just fine at 4.5GHz in my second PC. In short: it is likely that even an ”overheating” CPU will get replaced by a new model (because it simply became too weak for your needs) before it even starts to show off some wear out signs. But a good cooling is always a good thing (TM) to preserve your CPU... or allow to push it a few dozen MHz higher ! 😜

More than the height of your avatar (mine is also as tall as I am myself in RL, at 1.77m, and that's about the only characteristic my avatar and I do share, beside the gender), you might be encountering issues due to your overall avatar's look: big eyes (baby-like, or anime-like ones), rounded baby-like face, childish body frame, childish clothing, etc, can quickly make people categorize your avatar as an underaged one, regardless of its actual size. Not to mention the role-played behavior (should you role-play your avatar as a childish person, you would of course have it categorized as a child). This said, I did have issues with my own 1.77m tall avatar in the distant past (during the ”age-play” issue in SL), and had to clear things up in my avatar profile (avatar size, portrayed age, actual player age) to help things along. Nowadays, I am no more faced with such issues, but it may also be related to the fact my avatar itself is 16 SL-years old (meaning people won't fear any more about interacting with an underage real person).

The problem is that the UI itself is rendered using OpenGL... You'd end up with two OpenGL rendered windows. It's doable, but wasteful in resources. When I first launched a SL viewer, back in 2006, the first thing that shocked me was the fact the whole UI was drawn in OpenGL... Back in that time, with the weak GPUs we had, it was extremely wasteful and UI rendering could be seen in the ”Fast timers” as using up a significant part of the render time (especially when you consider that each text character in the viewer UI is in fact a ”glyph” that must also be rendered as a some sort of tiny texture under OpenGL). I would have expected the viewer to use the OS or its toolkit(s) (GTK+ or Qt under Linux, for example) to draw its ”floaters”, menus, etc, which also would have allowed to move the said ”floaters” out of the 3D view on you screen: those do not take up any GPU power and very little CPU power to draw, since they are basically ”static” and only updated whenever the user interacts with them (or the application needs them updated to reflect changing info). However, there are benefits for games in using real-time rendered UI elements: You can make-up specialized UI elements that do not exist in the OS or toolkit provided UI (e.g. and for SL, pie menus, multi-sliders, or the XY vector and track ball recently introduced with the EEP viewer). Your UI elements can be updated in real time (at each frame if need be), without needing any threading and cross-thread syncing mechanism (if you look at how the file selector is coded in LL's viewer, which uses the OS/toolkit one, and how it is coded in the Cool VL Viewer, where I implemented an XUI file selector, you will see how much more complex (and glitchy/hacky) the former is compared with the latter). It is easier to create interactions between the UI elements and the 3D world objects (pie/context menu, drag and drop from inventory to objects, etc). The UI can be kept uniform over all OSes your game is running under (no special case needed in the code for each OS, more uniform/easier experience for the users... once they got acquainted with your UI). There has been one attempt, years ago, by a TPV developer to use toolkit (GTK, IIRC) based floaters, but it never really developed into something usable. There also have been a couple attempts by LL to reduce the UI drawing overhead: UI floaters occlusion (so that the objects hidden by the floaters do not need to be rendered at all) and, recently, sparse UI updates (so that the UI can be drawn in a separate buffer and only updated when actually needed, that buffer being overlaid over the 3D view at each frame). Neither of those lead to some adopted code, probably because the benefits in performances are not really worth the added code complexity (today's GPUs can draw the UI elements really fast anyway)... As for the screen estate issue, your best bet is to use a viewer with a dense UI layout... My main grief against LL's v2+ UI is precisely that it wastes an awful lot of 3D view space by using enormous floaters with low density information in them. That's why I find the v1 UI I kept using (and kept improving too) in the Cool VL Viewer to be way more suitable (not to mention the productivity aspect, with less clicks and mouse moves per performed action). But you can find at least one viewer (Black Dragon) with a much denser v3+ UI, that could as well suit your needs, if the v1 UI feels/looks ”too old” for you... 😛 Not sure what you mean here... The GPU brand is not an issue at all for a two-windows 3D view...

You definitely did not try the Cool VL Viewer, which is immune to this issue (or more exactly, it got a workaround for it)...

In the viewers release notes,I can see that a new PBR project viewer release is available, however, clicking on the link to get to it, I get an XML error page instead: You may however get around it, by replacing the build number in the link for the former release (link in Arton's post above), with the new one, listed in the viewers releases notes page, which, for 64 bits Windows gives this, for example. Yet, could someone at LL fix the PBR viewer release notes page, please ?

It's way more responsive, and even speeds up textures rezzing (since it uses the ”free” time to do more tasks at the CPU level while it waits for the minimum delay between two frames to be exhausted); it only actually sleeps the CPU when there is no more work to do. 😛

From the description of the symptoms, I think it is likely due to the RenderMaxNodeSize limit: this limit was implemented to prevent huge memory consumption seen with some griefing objects, but it also affects places where a lot of highly detailed meshes (meshes with a lot of vertices) are placed close together. In this case, the ”spatial group” in which they are placed by the render pipeline (this is a group of objects that get rendered together, regardless of their type, so you can also find non-mesh objects grouped with mesh ones) can exceed the RenderMaxNodeSize limit, causing the entire group to get skipped by the render pipeline. Workarounds range from reducing the RenderVolumeLODFactor (so that less vertices get rendered, with the hope that it will suffice to stay below the limit) to increasing RenderMaxNodeSize (which works better, but will cause a higher memory consumption both at the GPU and GPU levels). You may also try the Cool VL Viewer: it got a work-around for this that gets enabled whenever you push the ”Mesh objects boost factor” multiplier above 1.0 (the corresponding slider is in the Graphics Preferences); this multiplier is used both to multiply RenderVolumeLODFactor for meshes only (*), and causes mesh objects vertices to get a ”discount” when computing the total amount of vertices in the spatial group before comparing it to RenderMaxNodeSize... (*) Meaning you can keep a normal value for RenderVolumeLODFactor instead of having to push it to unreasonable values just to render some badly designed meshes, and affecting as well non-mesh objects as a result (which is bad, and adds to the max render group size issue).

Once you got powerful enough a GPU, the bottleneck in the SL viewer renderer is at the CPU level and, more exactly, at the single CPU core performances level (because the renderer is mono-threaded, even though recent graphics drivers will help a bit about it by using one thread or two at their own level, loading one more core at 50-100%). So the highest the mono-core performances of your CPU, the higher your frame rates, and it is almost exactly proportional. As for the GPU load, it does not make the slightest doubt that in the simplest scenes, even the most powerful GPU will be loaded at 100%, because then the CPU (which got almost nothing to do for such simple scenes) can throw frames as much as the GPU can absorb them, and your FPS rates will skyrocket (with the Cool VL Viewer, I am seeing frame rates in excess of 800fps in my skybox, with my brand new RTX 3070 and my middle-aged 9700K, causing 200+ W power draw from the GPU). The solution is to use a (smart, if available in your viewer) frame rate limiter to avoid ludicrous fps rates and the resulting excessive power consumption/heating/noise. Limiting the fps rate to your monitor vertical refresh rate is the way to go, but do avoid VSync, which is by far the worst way to limit the frame rate.

It happens for the sim where you log in: if you log in in a sim that did not get restarted in the past 2 days and 21 hours, there will be missing ”online” friends in your friends list, wherever those actually online friends are in SL (including in the same sim !)...

That won't work... The Cool VL Viewer build system is a standalone one, while other viewers are all relying on LL's fancy ”autobuild” (not the GNU autobuild) Python module... I made my viewer build system so that it is easy to use, without the need of exotic dependencies, and once you got the basic required tools (compiler, cmake, Python) all you have to do (either under Linux, Windows or macOS) is to type a single command in a terminal to build it. 8Gb of RAM should be enough to build it... But you can also use the published builds for all OSes... It will also run much faster than any other viewer on your potato computer. 😄

Pour Windows, le greffon Dullahan de Firestorm 6.6.3 (67470) est exactement le même que celui de LL, comme d'ailleurs pour la plupart des autres TPV; c'est une version basée sur un vieux binaire CEF 91 qui n'a pas changé depuis maintenant plus d'une année. Je viens de tester Firestorm 6.6.3 sur une partition Windows 7 Ultimate 64 bits ESU, et n'ai pas rencontré de problème, à part un bogue dans la fenêtre flottante (floater) du navigateur qui parfois ne charge pas pas la page (comme pour le Firestorm Wiki du menu d'aide) et nécessite de changer l'adresse manuellement dans la ligne de l'URL ou via son menu déroulant pour déclencher le chargement, après quoi tout fonctionne correctement dans le navigateur. Mais la page de l'écran de connexion, la recherche Web, etc, se chargent correctement dés l'ouverture. Pas de souci non plus pour la redirection vers le navigateur système (Pale Moon dans mon cas). Donc, le problème que vous rencontrez est probablement dû à votre installation de Windows 7. Il pourrait s'agir d'un cache corrompu de CEF; pour remettre le cache à blanc, supprimez le dossier: C:/Users/<votre login>/AppData/Local/Firestorm_x64/cef_cache/ Si cela ne fonctionne toujours pas et pour de plus amples investigations, il vous faudra demander de l'aide à l'équipe de Firestorm, en leur fournissant les données nécessaires (et en particulier le journal: C:/Users/<votre login>/AppData/Roaming/Firestorm_x64/logs/Firestorm.log). Vous pourriez aussi jeter un oeil dans les ”Journaux Windows” de l' ”Observateur d'évènements” des ”Outils d'administration” du panneau de configuration de Windows: il se peut que l'erreur empêchant le bon fonctionnement de CEF y soit listée...