Henri Beauchamp

LL does not need to ”release the code to TPVs”: the code is open for every TPV developer to grab and integrate into their own viewer whenever they feel like it (and can find the necessary time to work on it, adapt it to their own viewer code, and debug it). The Cool VL Viewer got all the ”performance viewer” code integrated for months already (the backport process started in April in an experimental branch and got finished a few weeks later, in May with the new v1.30.0 stable branch release), with bug fixes (making them usable with iGPUs, for example, while bugs in LL's viewer code prevents it) and even more aggressive optimizations (such as multi-threaded GL image creation instead of a mono-threaded one in LL's viewer)...

Maintenance viewers got bug fixes over the current ”default” viewer. There are several ”maintenance” branches in the works, and the QA process decides which one will be merged in the next ”default” viewer version and when, maybe together with one of the RC viewer branches (such as the Profiles one), that contain additional features (legacy avatar profiles floater for the Profiles viewer, to replace the silly Web profile floater that no serious TPV wanted to adopt since it was so lame and slow). To see if a given ”maintenance” branch is interesting for your particular use of SL, see its release notes: the ”Resolved issues” list tells you what bugs have been solved and still exist in the current default viewer. It is true, however, that the release scheme of LL's viewers is rather opaque and hard to follow (even for TPV developers). For example, while there is a Repositories page that, in theory, gives you the list of the active branches together with a link to their code repository, all links actually point to the root of the git repository (instead of pointing to the corresponding git branch), meaning no one (but LL) can tell what ”Maintenance”, ”Maintenance2”, and ”Maintenance3” do correspond with in the git (”DRTVWR-544-maint”, ”DRTVWR-548-maint-N”, ”DRTVWR-565-maint-P”, in that order or not, or even some of the many ”SL-*” branches ?... Who knows ?!)... In the past, the various viewer branches (maintenance and project viewers alike) were given nicknames that were easy to remember and follow, instead of those meaningless and confusing branch numbers... I wish LL would again give such nicknames to, at least, important branches (i.e. maintenance and project/RC viewer branches).

If any moles read this, I'd prefer that they would add rez zones in Zindra to match what we have in all other continents, that is at each sim border on Linden roads (zero such rez zone in Zindra), and of course add rez zones too on the coast line... Oh, and also fix the Linden roads parcel flags so that automated transportation systems (such as Yavanah's excellent pods) may roam them... Also, you cannot sail around Zindra because of missing protected waters or water sims on the South West and North East coasts... This, too, should be addressed ! Zindra has been hastily and poorly thought out and built (what I call the adult segregation debacle): it would be about time that LL grants ”Adult” folks the same care as they show for ”Moderate” and ”General” folks !... Then, perhaps, they would be less ”disputable” activities in ”Moderate” seas and lands... See also this post of mine

In most TPVs, you may choose wether playing the avatar appearance editing/customizing animation of not (it is useful, for example, whenever your avatar is sitting on an object and you do not want it to get auto-unseated while editing its outfit). Verify this setting (and let the viewer play that anim).

I have a lot of RAM because I run VMs on my Linux system (e.g. the Cool VL Viewer Windows builds are built using a VM). You do not need a big cache for SL... 2 GB is more than enough. The cache won't speed up your frame rates, but merely improve the rezzing speed (on condition you already visited the same place recently), especially when your network bandwidth is poor (but with today's 1Gbps FTTH, the cache is hardly faster, especially when held on HD or even SSD).

My third alt (born in 2008) started as ”Boy Next Door” and has not changed aspect/clothing ever since... A good thing that smell is not transmitted via the viewers, or else, its outfit would be stinking a lot nowadays ! 🤣

Like many developers/contents creators, I only use alts to test stuff (viewer code, LSL scripts, etc)... I do not use alts to role-play different story-lines; instead I use the same avatar, but in different forms/aspects, the reason being that I won't be able to share inventories between different alts (even if each one is dedicated to a story line, they most often need a range of identical equipments). Perhaps would this (inventory sharing) be a future feature LL could bring to SL ?... However, had I known I would become a viewer developer and contents creator/scripter in SL when I joined, I would have created a specific alt for that purpose (i.e. an alt I can use only to do ”business” and development in SL), instead of using the same avatar to develop/do business and role-play... The reason is that all the kinky adult stuff I role-play is strictly private while the rest is public. So my advice to newbies is: if you come to SL to do various things (and especially things that must be kept private when others are public), then do create two alts and dedicate one to each task.

No, you simply save the ram disk on shut down of the computer, and restore it on boot. With 'tar' (and no compression for speed), this only takes a couple seconds... Here is my (SysV init) ramdisk script: #!/bin/bash # # ramdisk Start/Stop the ramdisk. # # chkconfig: 2345 01 99 # description: starts and stops the RAM-disk, restoring and saving its \ # contents. ### BEGIN INIT INFO # Provides: ramdisk # Required-Start: $local_fs # Required-Stop: $local_fs # Default-Start: 2 3 4 5 # Default-Stop: $named # Short-Description: starts ramdisk # Description: starts and stops the ram-disk, restoring and saving its \ # contents. ### END INIT INFO . /etc/rc.d/init.d/functions BACKUP_FILE=”/var/cache/ramdisk-backup.tar” MOUNT_POINT=”/mnt/ramdisk” LOCK_FILE=”/var/lock/subsys/ramdisk” case ”$1” in start) mkdir -p $MOUNT_POINT action ”Mounting ramdisk” mount $MOUNT_POINT if [ -f $BACKUP_FILE ] ; then cd $MOUNT_POINT action ”Ramdisk contents restoring” tar xf $BACKUP_FILE fi touch $LOCK_FILE ;; stop) if mount | grep $MOUNT_POINT &>/dev/null ; then if [ -d $MOUNT_POINT/tmp ] ; then rm -rf $MOUNT_POINT/tmp/* fi rm -f $BACKUP_FILE &>/dev/null cd $MOUNT_POINT action ”Ramdisk contents saving” tar cf $BACKUP_FILE . cd / action ”Ramdisk unmounting” umount $MOUNT_POINT fi rm -f $LOCK_FILE ;; save) if mount | grep $MOUNT_POINT &>/dev/null ; then rm -f $BACKUP_FILE &>/dev/null cd $MOUNT_POINT action ”Ramdisk contents saving” tar cf $BACKUP_FILE . fi ;; load) if mount | grep $MOUNT_POINT &>/dev/null ; then if [ -f $BACKUP_FILE ] ; then cd $MOUNT_POINT action ”Ramdisk contents loading” tar xf $BACKUP_FILE fi fi ;; *) gprintf ”Usage: %s {start|stop|save|load}\n” ”$0” exit 2 esac exit $? With the following line added to /etc/fstab for the ramdisk (here I use 16GB of my 64GB installed RAM): none /mnt/ramdisk tmpfs noauto,size=16G,nodev 0 0 Note that 16GB is a lot more than I use for the viewer cache, because I also compile the Cool VL Viewer (which can happen many times per day when working on it) in the RAM disk to avoid wasting write cycles on my SSDs.

Well, the reason why I split the avatar height (which is not affected by the shoes) and the shoes height is precisely because the sum is pretty meaningless (and confusing to many people) when you design an avatar... Feel free to borrow my idea and do the same in Firestorm !

For a SSD ”lazytime,noatime” is best since it induces even less writes than ”relatime”. You will also want to add ”discard”, so to improve the drive performances (the driver will then auto-TRIM released memory blocks on the drive). It should also be noted that for cache usage, and on the condition you have enough RAM, it is best to use a ramdisk (the caches are written to very often with small amounts of data, which is probably one of worst loads as far as wearing out a SSD is concerned). This could be a bug in systemd (since the distros you cite are using it), or a race condition with the drive initialization (if it initializes late in the boot process, it might be considered as freshly connected and thus removable). Being the old fart I am, I do not trust ”modern” (and most of the time, flawed) ways of doing things, so I use a distro with a good old SysV init, I write /etc/fstab manually, I install manually the boot loader, I compile my own kernels and drivers, etc... If something fails on my system, I at least know who is responsible for the failure and how to fix it ! 😛

Avatars actual size (the one that equals to a primitive with the same size, as Beq showed up) has always been an issue in SL... One of my oldest scripted items is the ”True Height Detector & Comparator” (created in early 2007, as a response to all the bogus height comparators that went in use at that time, due to the new ”no age-play” policy: it always annoyed me to no end when people pointed to my avatar saying he was too small, when he has actually always been 1.77m tall, which also happens to be one of the two characteristics (with the gender) it shares with me, the adult RL person behind ”him”)... The problem is that the LSL function to get the avatar height is not measuring the actual height but instead the distance between the avatar feet and the center (or, to be accurate, the joint position) of its head... To correct the number returned by llGetAgentSize(), you need to add 0.17m (17cm). This is an empiric value I got by averaging the delta I measured between the returned size and the actual (prim-equivalent) size of many shapes (and all the common shapes that existed back in 2007, of course). This is however, not counting shoes height (which you must subtract from llGetAgentSize() if you want to get your shoe-less avatar height), and not counting either the Hover visual parameter that got added when server bakes were implemented (*)... This is why, in the Cool VL Viewer, I implemented three measurements in the ”Appearance” floater: the actual (shoe-less, hover-less) avatar size, the shoes height, and the ”pelvis to foot” (**) distance (which accounts for the shoes height). The Hover parameter is never taken into account in those measurements (like it is not by llGetAgentSize()). As for correcting automatically the animations height to level them with the floor whatever your avatar shape, you can use the @adjustheight RLV command I created for this purpose... Of course, all of the above does not account for prim-based avatars or mesh avatars that deform joints (e.g. tiny and giant avatars)... ---------------------------------------- (*) Because of a misunderstanding from Oz, who did not get that what was needed was a way to correct the avatar Z offset in real time, without changing the shape, in order to properly level with the ground the kneeling, crawling, laying or sitting on ground animations, when your avatar pelvis to feet distance is different from the one used by the animation designer. Later on, an ”AvatarHoverHeightEnabled” simulator feature got added, that allowed to restore what was possible with viewer-side bakes and the AgentSetAppearance message that got removed with server bakes. (**) I will change that name for ”pelvis to soles” for next release, since it will be even clearer and more accurate.

Indeed... Once the GPU issue out of the equation (i.e. for anything equal to or better than an old GTX 660 for ALM without shadows, or a GTX 460 with ALM off), the performances of the viewer increase almost exactly proportionally to the CPU single core performances (because the rendering engine is mono-threaded, even though some drivers such as NVIDIA's proprietary ones may use a few threads by themselves and load half to a full more core). With an old 2600K, I would, even before considering buying a new GPU, attempt to overclock my CPU: the Sandy Bridge is super easy to overclock and can easily reach 4.4GHz locked on all cores (disabling all but C0 and C1 states), and even up to 4.7GHz if you have been lucky at the Silicium lottery. I still have an overclocked 2500K @ 4.5GHz as my second PC (it used to be @ 4.6GHz, but after 7+ years running flawlessly at that frequency I had to reduce slightly the speed to avoid a daily freeze when the CPU is idle). Here, going from 3.4 to 4.4GHz would get you almost +30% on frame rates.

Anything above a GTX 960 can run SL at maxed out graphics settings, even with ALM + shadows. As for the GPU shortage, it might be ”over”, but prices are still too high here, in EU, to consider buying now. With the RTX 4000 arriving (probably this coming Autumn), it is wiser to wait: you will then get big discounts on the RTX 3000s. I am myself hoping to upgrade my main PC with a RTX 3070 to replace its GTX 1070 Ti, even though the latter is plenty powerful enough for SL.

This will not be specific to Firestorm: the viewer cursors are actually sprites, that do not get resized depending on your system (Linux desktop) cursor settings. Looking at the viewer log whenever such an occurrence happens, would likely tell you (and us) what went wrong: failures to find a folder or write to it would be logged as a warning. This would allow to pin-point the cause for the cache folder relocation. Note that is in no way a ”Windows” coding specificity; under any OS, when the viewer cannot find the configured cache folder, it creates a new one, in the default location... Try the Cool VL Viewer: while rezzing (and provided your network can follow, i.e. got a high bandwidth), it will happily load all your CPU cores with its multi-threaded texture decoder, providing a blazing fast rezzing experience... It is also primarily a Linux viewer, so the Linux code is especially well tailored and optimized.

Since Singularity is no more maintained and outdated, I'd rather recommend using the Cool VL Viewer (yep, that's a shameless plug) which also got an improved avatar editor (over what it was in v1 viewers and what it is in Singularity), with also precise avatar size (including pelvis to feet measure, which is important for animations Z offset calculations, and shoes height).

This must be really disheartening for all other creators that do not get the free advertisement boost by LL and see the promoted competition taking more market shares as a result... This is ”just” totally unfair ! I do not like this, at all !

Lame... Such is my only thought when watching this video (thank you for pointing it out, since I won't have watched it otherwise) ! Why the Hell is LL advertising for a specific body mesh brand ? Especially one that is so heavy on (actual) rendering cost... I mean there are many other (less known/popular) mesh bodies around that look just as good and are not so heavily taxing on performances. I wonder how much LL got paid for this (or perhaps they just considered the indirect revenues they got from that brand deserved ”free” advertisement).

It is likely someone on another parcel terraforming their land plot, or (de)rezzing objects bearing path-finding attributes (possibly via a scripted auto-rezzer).

It does have the fix (see my post here) ! Don't get fooled by version numbers (the Linux and the Windows drivers do not have the same): don't forget that the Windows driver also implement DirectX, which is of course not in Linux drivers, so the versioning scheme differs.

So does v515.57 for Linux that just got released. \o/ Even though the release notes do not list this fix... Also, I find it odd that the Windows driver release notes mention ”third party viewers”, since it actually affected LL's viewer(s) alike.

Not quite... There is a bug in Wine causing issues on file writes (after a write, the file pointer is not properly updated, so when the code tries to read the current position, it gets the one before the write happened); for this reason you will find a ”Flush on asset write (for Wine)” entry in the Advanced -> Caches menu of the Cool VL Viewer Windows builds; of course, I won't recommend *at all* to run a viewer via Wine under Linux (the slow down is tremendous), especially one that got native Linux builds, but I do it sometimes, to quickly test for code changes that risk breaking Windows builds...

Yes, LL's viewer is extremely annoying, with that auto-updater... Proceed as follow: Download the 32 bits viewer installer. Shutdown your network. Install the viewer. It will launch the updater but without the network, it will just abort it. Close the viewer. Delete the updater from the installation directory (SLVersionChecker.exe). Re-enable the network. You can now relaunch the viewer: it will complain that it fails running the version checker (just acknowledge the alert box), but will run just fine nonetheless...

I really hope LL is not relying only on this hamster to run the grid... 🤣

Got a mission for Derrick, then (I sent the question to Patch at the SL19B ”meet the moles”, but it did not get selected): Zindra needs some love from the Moles: this is the only SL continent where there is not a _single_ Linden rez zone on roads, while there is one at _every_ sim border on roads of all other continents... Plus, most of the roads are bearing parcel flags that prevent automated vehicle systems such as the excellent YavaScript pods to roam them and help people getting acquainted with Zindra's landscape and places. You cannot either sail freely around the South West and North East of the continent by lack of protected waters or missing sims to complete the coast line. Finally, I dream of a channel that would link Zindra to other SL continents by sea; I know, it's far, far away on the grid, but why not sprinkling the channel with archipelagos, like one for a museum of Linden homes, or other such themes with historical interest for SL ?... And while I'm at it, another reinvigorating mission: While roaming the various SL continents, I often stumbled upon G-rated sims devoid of any build or privately owned parcel. That's a shame, knowing these still cost money to run from AWS servers. As I infer it, the super-restrictive G-rating is likely the cause of this abandon. What about changing their rating to Moderate to make them more appealing for new settlers ? Also, why not digging lakes and rivers or growing mountains in those empty sims, to make them even more appealing ?

This is a race condition between the servers and the viewer. The Interest list changes affected both (and the object cache was fully rewritten viewer side), meaning it is not surprising at all that you see the problem occurring out of SL (not to mention that OpenSim servers reproduce the same messaging as SL servers, even if with different algorithms). Not all objects, but all objects in the same spatial partition (objects are grouped in the renderer, thus why they get affected by this bug as a group).