KjartanEno

You might want to read Lyssa's helpful post earlier in the thread. In reality, it's not as important what the maximum framerate can be, but how well heavy loads are handled. The M1 is indeed very impressive for general use computing. I'd consider simply being able to use SL as a side bonus for this generation of new Macs. In a couple of generations (M3+GPU?), they may actually compete with high end PCs in performance in SL.

A trip to Wizard's Winter, using Firestorm (EEP) viewer. Back home, where it's much warmer, using Cool VL Viewer (Windlight renderer).

Believe it or not, but it's actually much better than it used to be. There was a time when the Sun and Moon caused no shine at all, and point/projection lighting caused even a low shine object to look like shiny plastic, yes, even more so than what you are observing in the current viewers. Things improved when the Love Me Render RC was incorporated into the main viewer code late last Summer. There are things I like about EEP, having played with it for many months now. However, I keep hoping that maybe Singularity will get another round of updates while keeping WL alive. Singularity 8193 beta is still my go-to viewer for clubs, with excellent framerates on my AMD/Radeon system that no other viewer matches.

Citing a framerate is irrelevant without specifics like viewer resolution, shadows on or off, ambient occlusion, LOD factor, water reflection level, time of day (midday is preferred for repeatable benchmarks), draw distance, EEP or Windlight, a landmark in a public sim for others to use as a reference, the number of avatars (if any) in the view (preferably none), and an image of what you're seeing with that framerate. Using a graphics preset isn't good enough since settings can be tweaked beyond setting a preset such as "high." It's extremely easy to get over 120 fps with my cheap home built computer, a quad core Ryzen 3 1300x, 16 GB DDR4 RAM, and RX 580 8GB GPU running Linux, with shadows off in a skybox, for example. Give us a location, settings, and an image to use as a guide. Don't get me wrong, I'm quite interested in the M1 chip (or more accurately succeeding generations of ARM chips that run desktop operating systems) for the energy efficiency and computing power. I am not interested in meaningless framerate citations.

Which seems odd considering how easy it is to just extract the official .tar.xz and move the folder to the desired location, or just run the install.sh script in the extracted folder. That said, I also have the Flatpak version of Firestorm installed out of curiosity even though my .desktop points to the official folder which i've placed in /opt. As of this post, the Flatpak version isn't updated to 6.4.12 yet. I'm already used to the new Firestorm, having kept up with custom compiled beta versions. I've got the official version installed now. I wish LL had fixed the EEP moon by the time of this release. I wonder how long it will take for the regular users to file bug reports that the moon is practically invisible near the horizon? HINT: The bug report exists and was accepted months ago....

I use a Linux based operating system. I also play games on Steam. While many of those games run on Linux natively, quite a few I've bought over the years only came with Windows versions. Valve, the owner of the Steam platform, has been a huge supporter of open source software. In the last few years, they've packaged WINE with the Linux Steam Client in the form of SteamPlay/Proton. It makes a large percentage of Windows-only games run on Linux with no additional effort. If a game needs a few extra tweaks, the community often shares information on what is required to get that game running. Most Windows game use Microsoft's Direct X, so in recent years a translation layer called DXVK was developed to convert D3D calls to Vulkan, the replacement for OpenGL. DXVK works so well for my AMD Radeon RX 580, that I've installed Windows versions of some games instead of their native Linux versions that use OpenGL. How much better is the Direct X to Vulkan translation than OpenGL? I often have twice the framerate with DXVK over OpenGL. Yeah, part of that is simply because AMD doesn't optimize their consumer level GPUs for OpenGL, but it would not surprise me to find Nvidia users doing the same thing for the same reasons. So how would this apply to Second Life? Would there be any benefit to running a translation layer for OpenGL to Vulkan? I was curious about this, and it just so happens that current open source Mesa drivers on Linux (for AMD and Intel graphics only) can use a relatively new feature called Zink to do just this. Zink is still experimental and in active development. I was able to run a Second Life viewer using Zink, but it's very sluggish and has artifacts. Perhaps this will change, but I'm hoping for a native Vulkan renderer in the viewer some day. Vulkan works on Windows the same way it does on Linux. As for Mac, the MoltenVK API should work with hardly any loss of performance. Image: Second Life viewer running OpenGL to Vulkan at the driver level. Notice the odd looking eyes. Also, the mesh on the avatar will go to lower LODs very quickly for some reason, disintegrating at a much shorter distance than expected.

As for the first point, I get what Stray Dog does. The bodies and heads all have matching tones so that they can sell a face "skin" (with a blank body) consisting of a few different colors, and it goes with the corresponding body colors sold separately. Since there are some minor variations between mesh body UV layouts, one purchases the body skin based on the brand one owns. By doing it this way they avoid the need to package multiple body types in every single color with each and every face. I use materials on my mesh body and head, so I prefer to use Omega appliers without shine for hairbases and eyebrows. Depending on the hair I use, I may have need for one hairbase or another. Of course, your method would be preferable if one only ever uses one kind of hairbase. As for "HD" eyebrows, that's just going to be the usual applier method for mesh heads with layers, but not using the SL UV layout for the head.

Looking into that, I was curious about my own preferred resize algorithm in GIMP, which is NoHalo. I noticed that it produces a 'sharper' image without ever understanding why, but now I see it fits in with the reasons explained in Beq's blog post. The second stage of NoHalo is bi-linear interpolation. https://graphicdesign.stackexchange.com/questions/138059/what-algorithm-do-the-nohalo-and-lohalo-resize-methods-use-in-gimp

Some lovely people in this thread. Here's what I look like today...

I have Primstar, which works with Blender 2.70, I think. However, I've hardly used it. You say you checked marketplace. Did you also check https://www.outworldz.com/ ?

What you're describing is called Decentraland. You can do exactly what you just described by using a web browser and entering the world. There is no need to sign up, so anyone can enter as a guest. I've had very little experience with this virtual world. It might be worth looking into, but it's no replacement for SL.

It's pretty common. More often than not, I just go ahead and give someone a head, body, or eye alpha, which only took me a few clicks to make in my inventory. One can only do just so much to help. I have explained how to make alpha masks, but I don't expect most people to do so. I've seen that helplessness myself. I have created around 100 alpha masks for male clothing items, making more as time allows, that I set full perms and give away. I put the name of the clothing maker and item on the alpha mask. Again, one can only do so much, but at least I can say I did something. I have no problem with some alpha cuts. I like having at least one 'onion' layer for appliers that use materials, so alpha cuts have to be there even when using BoM in order to hide 'tattoos' that might poke through. I don't do it often in outfits, but the option is there if I need it. BoM exists, but that doesn't mean all the old bodies and appliers stopped working. With a few exceptions, most body makers still offer scripted alpha cuts and applier support in addition to BoM. Those mesh makers that put ridiculous polygon counts into their pre-BoM creations probably won't improve much anyway. ... A few more years pass, and all the people who bought the 'coolest' body and the 'popular' head wonder why nobody hangs out anymore (because it became a slide show with their 100 million triangle bodies, heads, hair, clothes, and accessories, all texture thrashing even with an 8 GB VRAM GPU...). 😵

Applier bodies: Each mesh object can only have 8 faces, so there are only 8 alpha sections possible per mesh section. One can make an educated guess as to how many individual objects each mesh body has by the number of alpha cuts shown in the HUD for that body. That means additional scripting overhead too, since the body may also provide broader alpha settings in addition to individual sections, and there may be an automatic alpha system to help with alpha control. Who wants to set alphas every time one makes an outfit? I used to put bodies in folders based on outfits. That was a lot of extra body copies in my inventory. Body makers can only divide up a mesh in just so many ways in anticipation of possible clothing options. How many extra vertices are needed to account for all those cuts? Multiply that by three, since one needs a tattoo and 'clothing' layer as well. BOM bodies: The system alpha mask reduces the need for alpha cuts. This results in fewer body sections, more optimized vertex placement, and simpler scripts. HUDs can be made simpler, thus taking up less texture memory, important if you don't have a high end graphics card. I am no fan of fancy HUDs cluttering up my view of the world, and with a BOM body there should be less need to even use the body's HUD in outfits. Going back to the system alpha mask, anyone can make them. I use GIMP and the free 1024 x 1024 SL UV textures from Robin Wood to 'connect the dots' while wearing a skin I made based on those same textures. Once I have my alpha mask textures, I upload them and create a system alpha mask, something anyone can create by right-clicking in the "Clothing" folder and creating a new alpha mask. Be kind and share your alpha masks with friends! Alpha masks make outfit creation a breeze. Need to take off shoes? Detach them and the alpha mask that goes with them. No need to open a HUD or save a body copy just to cover going barefoot. A few mesh body copies can cover a lot of outfits, resulting in less inventory clutter. As an aside, adding and removing clothing items using RLV folders is now as easy as it was with the system avatar. Edit: Oh and I just remembered one thing I did recently. I got an awesome system skin from Aeros. However, there were some details about it that didn't quite suit me and my mesh body, so I used some of my own textures to create a whole-body tattoo layer. Thus, I effectively 'modded' a system skin with a semi transparent 'skin' tattoo to give me exactly the look I want.

Ok, since I have compiled Firestorm for Linux using their developer wiki instructions, I'm aware that some libraries such as OpenJPEG are precompiled, and the build system downloads them from a server. If those precompiled libraries come optimized for Intel CPUs, would that have a performance effect even if the main viewer code itself is compiled on a Ryzen system? When it came to Cool VL Viewer, I saw only a couple of frames per second improvement by compiling it optimized on my Ryzen CPU, but again using Henri's precompiled libraries. I must stress, I am not complaining or denigrating any viewer or the person(s) who code them. Programmers do a wonderful job. I'm just an end user who wants to learn more, and I have more time than money, so there simply won't be any new computers in my near future.

That part about the OpenGL rendering is a particular sore point for AMD GPUs. The official AMD drivers for Windows have abysmal performance in OpenGL applications compared to Nvidia. While the open source AMD drivers for Linux are ironically much better than what AMD offers on Windows, my RX 580 8 GB GPU is 10-50% slower, depending on the scene in Second Life, than my GTX 960 2 GB GPU with CPUs of similar capabilities. It wasn't until recently that I managed to cobble together the second computer from parts in an old case so that I could compare performance between an all AMD system and an Intel/Nvidia system. I use Ubuntu 20.04 on both computers. I used Rickslab GPU Utils to verify that the AMD GPU was indeed operating at maximum load levels (and frequencies) in my tests while still underperforming next to the GTX 960. This isn't a CPU thread issue, as far as I can tell. Now, also ironically, the AMD system scores much higher in the Unigine Valley OpenGL benchmark than the Intel/Nvidia system, but lower in some glmark2 tests. I do have to wonder if some of the viewer rendering pipeline has been streamlined to favor Nvidia in Second Life. Case in point, the Cool VL Viewer is faster than all other viewers on my Intel/Nvidia computer but slower than all others on my all AMD system. Henri optimizes his code for his own Nvidia-based computers, which isn't a bad thing since it's his viewer to do with as he pleases. Would it be possible to optimize for AMD? At this point, would it even matter since the Lab is going to change the rendering pipeline anyway? The RX 580 is also far superior to the GTX 960 in most games I play on Steam, but that has more to do with the AMD GPU having better Vulkan (Vulkan & DXVK) rendering capability. If the viewer code is updated, which I imagine is being motivated by Apple deprecating OpenGL soon, then Vulkan is the way to go as a cross platform graphics API. If I had a system like the one that the original poster has, but on Linux, it would be giving me incredible framerates no matter what viewer I use. Most likely the issue isn't the viewer, it's Windows or some setting, driver, or power state related to the operating system.

This is a common issue, I think. Even I used the camera controls a lot when I was new, and it was a struggle to move the camera around accurately. However, all viewers have the ability to cam using ALT+left-click on any object in a scene and rotate around it horizontally and zoom into it. Using CTRL+ALT+left-click rotates around and vertically over any object. It then comes down to muscle memory with practice, as using the keyboard and mouse in this way is far more responsive than relying on the viewer's camera controls. Pressing ESC key will reset the view to the default view. None of this requires going into settings for more advanced options.

In SL, you get up to four bone weights for every vertex on a rigged mesh. For arms, legs, hands, and feet, four weights is enough to get smooth transitions and allow for a mix of animation and volume bones. Generally speaking, volume bones would be weighted on areas that you want to increase muscle or fat volume with the appropriate sliders. Joints like knees and elbows should not expand as much, and the topology in the joints would be carefully weighted with mostly animation bone weights. It gets a bit more complicated in the torso. Most people want to be able to adjust the size of the butt, love handles, saddle bags, and breasts/pectorals. And then there are shoulders... All of which is to say that weighting is one of the more challenging jobs in creating a mesh body. Some body styles lend themselves to a non-fitted mesh approach. I'm almost certain that Piggu bodies have no fitted sliders. They are simply designed to be fat already, so the vertices are all weighted exclusively to animation bones. That is not to say one couldn't do the same with a thin or muscled body, but customers would need to know that what they see is what they get. Clothing made for this kind of body is much more likely to fit well since the designer knows from the start exactly what it will look like on the body. A fully fitted approach sounds like a good idea for getting smooth weight transitions and giving customers the ability to create more varied shapes. However, it tends to be more difficult for clothing designers. Any time volume-based sliders are taken to extremes, there will be issues involving poke through in places that are hard to predict and deal with using alphas. The Big Brands for human avatars all use a combination of animation and volume bones. With each body, the designer has a certain look in mind but takes into account the expected range of certain sliders. In the end, it's up to YOU to decide how to weight your mesh. It may also be up to you to create all the clothing for that mesh in the beginning since clothing creators want to see a customer base before investing time and effort into clothing for yet another body.

I suppose you should take up the issues with the viewer in the Cool VL Viewer forum. I don't post there anymore, but you're more likely to get answers directly from Henri there.

Cool VL Viewer doesn't use the V3 outfit folder system, so you will not be able to save outfits in the same folder that every other current viewer does. Viewers install in separate locations with separate data. Installing one does not affect another. Cool VL Viewer uses a very old interface style. Why are you using it?

Well, cool viewer skin! I just distro hopped to Pop_OS (Ubuntu 20.04) to see how their tiling extension fits my workflow. So far, it's alright.

@Nick0678, I see you use Arch. But I've noticed something else about that screenshot that I can't quite put my finger on..... KDE Plasma? 🤣 Ok, seriously, I have never seen the Relentless viewer before. Is it going to be available for any Linux distro?

Assuming your video drivers are up to the task, what actually happens when launching the SL viewer? What happens when launching Singularity? FWIW, I use Singularity 1.87.8193 due to issues I have with the official release. You might instead use Alchemy viewer. I cannot help with Windows 10 issues.

The moon doesn't have to be full, and the day cycle can follow a path that isn't overhead (with a lot of sky settings).

I have the same issue when selecting a landmark from the "Places" floater. Open floater, click once, and it jumps to the bottom. Or click on a landmark and it may not let you scroll, only jumping back to where it was after you release the mouse button. Though you see this in one kind of inventory window, and I see it in another kind, it is all related. A fix is coming soon, according to the recent viewer commits from LL.

Done. https://jira.secondlife.com/browse/BUG-229489