Jenna Huntsman

In theory, the colors should be the same unless you changed something in your GPU driver settings / changed viewer / changed monitor. YMMV though. Color depth would only change if you have a 10-bit monitor, *and* a viewer which supports the 10-bit pipeline, *and* have that enabled (not entirely sure if any viewer supports Nvidia's 10-bit, but haven't got any Nvidia HW to test), and even then it would only be a change in materials rendering.

Just gonna plus 1 myself to this, as I too have been having failures in the past couple days. It's good that progress is being made towards fixing group chats, but this didn't solve the mass failures going on right now.

Out of interest, do you have an LM to aforementioned 'populated area'? Would like to see what kind of FPS I get as I have a similar hardware setup to yourself.

In my experience, on AMD hardware this drops the framerate by 2-3 fps on average. Nothing major, but enough that I usually keep it off. True, but if I'm not mistaken LOD 4 loads objects at full resolution up to and beyond 128m away (depending on overall scene complexity), which is completely pointless, even on a 4k screen.

Agree with most of this, but the stuff about LOD 4 is bunk - LOD 4 means that the viewer is always loading and rendering the highest complexity mesh possible. Think about that in terms of a a mesh body (I think I read somewhere about Belleza being somewhere around 800,000 tris for the entire body, hands and feet at max LOD), that's going to choke the (albeit very old and unoptimized) renderer and tank your frames. A normal game often places 50,000 tris for character models, and almost every asset has LODs which are used when an object will not be 'in focus', in order to free up time to render more frames overall. If you're playing around with enabling shadows, this only makes the problem worse as the renderer has to process a higher complexity mesh and calculate it's shadow, instead of using a lower LOD for an object, say 50m away from the avatar and calculating the shadows on the LOD. Switching to an Nvidia card *would* help if you're on Windows as the AMD OpenGL driver isn't great. But also, good luck to anyone trying to find a 3080 in stock, at a non-stupid price. (I'd recommend not trying it unless SL is a major use for your machine, and you'd benefit in other areas from making the switch) Disable shadows and your framerate will jump by a considerable amount. Shadows are bound by the CPU, but coupled with the slower OpenGL on AMD they become pretty unusable pretty quickly as the framerate drops through the floor. In my experience, the only viewer that I can use with shadows enabled and have playable frame rates is Alchemy.

I'm not sure about animations 'drifting' into sync, but animations can be synced (either deliberately or by accident) by controlling when an animation starts or stops. Note that calling an animation may require the viewer to download the relevant asset from the server, so a script calling the same animation on 2 different avatars in a 3 second interval would likely result in the animations starting at the same time (as the asset hasn't been downloaded to the viewer yet, so the animation will start to play when it is available, irrespective of the time passed between the animation calls)

SL on M1 isn't going to run all that well anyway, as OpenGL was depreciated on MacOS years ago. This also rules out the concept of a 'universal binary viewer', as the main bottleneck is likely not the CPU, but the lack of real OpenGL support (Intel Macs still have it, mainly as a leftover from before it was depreciated, but it's likely that not much thought was paid to OGL support on M1)

I'll +1 that. I don't even care about the video, but the music blasting down my headset every time I fire up the viewer *is* annoying, so at least an option to have it muted on start would be good.

Without digging too far into the Alchemy sources, here's some of the stuff implemented in CoolVL as of late: Backported from Alchemy (Rye Mutt's code) "use RGBA16 as screen format when GL version is 4.0 or above" for AMD GPUs. (This bring 10-bit colour support to the SL renderer, AMD specific, does not impact framerate) Removed ancient/dubious (and now clearly detrimental) fixes for Intel and AMD GPUs OpenGL drivers. Some speed benefits are expected on these platforms as a result. The Alchemy closed beta (Shrewdshepard) may include more optimizations, but without access to the sources it's hard to tell.

I should probably rephrase that, but the point stands: On my system (Ryzen 3800X, stock clocks, water cooled, RX6900XT reference, 32GB RAM, 3200Mhz), running Firestorm with the exact same settings as CoolVL nets me (on average) 10FPS less, and the same with Alchemy. Both CV and Alch have some AMD-specific optimizations which help in this regard, which is why I recommend people don't use FS if they are on AMD. Don't get me wrong, I still have FS installed, as there are a couple of features which I find useful when developing products, but I don't use it as a daily driver because of the performance difference.

Post a photo of your graphics settings, there's likely tweaks that can be done there (to reiterate - I've got a similar HW setup to you, so you should definitely get more than 30 fps on avg. - I've attached screenshots of my current settings in CoolVL) It is, to a point. Getting 30 fps with that setup though is not normal! The reason is that AMD's OpenGL plain isn't as good as Nvidia's is on Windows. Nor is that likely to change, as there's no demand for it (in the big picture sense, as the only things using OpenGL these days are emulators). Another reason is that the viewer is single-threaded (so it's always choked, no matter what hardware you've got), a mess of pre-OpenGL 4 code which has to be kept in order to make MacOS work. In reality, the only way to solve it is to rebuild the viewer from the ground up with a new renderer, which LL *are* putting work towards, but (as far as I know) it's just research right now.

160cm (5ft 3in). I'm short RL, don't care, I'll be short in SL too.

AMD GPU -- same as mine actually -- DO NOT USE FIRESTORM!!!! Firestorm (and the LL viewer for that matter) don't like AMD gpus - fortunately other TPVs have better optimization for AMD. Check out CoolVL (my current daily viewer, avg. FPS is around 45 with EEP enabled), or Alchemy (my previous daily, current *release* version does not support EEP) Edit: R.e. Antivirus whitelisting, it *may* help, but if your primary drive is an SSD it'll make next to no difference with your specs. R.e. LOD settings, *never* turn this up above 2. Really, it shouldn't even be at 2, as the LL default & recommended is 1.2, and any content which breaks as a result was not made correctly in the first place. Seriously, look at the technical talk from some of the other threads, but there's a lot of free FPS on the table if people turn down their LOD distance. If you want to continue using Firestorm with the best possible performance, you may wish to consider switching to Linux as the OpenGL support on AMD is vastly superior than it is on Windows.

Well, there's your problem! Your processor is a bit on the slow side, and for good SL performance at higher settings, you pretty much need to have the latest processor you can get (SL is almost entirely single threaded, so it is almost always bottlenecked by your CPU) Regardless, Firestorm is not the best viewer if you want more FPS. Give Alchemy or CoolVL a try.

I think any and all efforts to make the viewer more multithreaded is a good thing, even if the net framerate gain is only a small amount. Anyway, r.e. AMD OGL on Windows, i'm pretty sure it's never going to be fixed - I think it would have been fixed years ago if it was. Then again, LL should have probably given us a Vulkan viewer some time ago too.

Eh, that post isn't all that relevant here in terms of performance difference as the difference is the same now as it was before, albeit with a higher average framerate for both. I still don't have any idea what exactly went on there, but Henri's guess of Alchemy playing with driver flags seems like a good bet. I'm inclined to say Windows *probably* wouldn't do anything, as OGL on AMD (on Windows) sucks. I tried Linux early last year, but I couldn't get my sound drivers to work properly - I've since been told that they've been fixed, but I'm yet to find the time / motivation to try again.

You're assuming that everyone has the same results as yourself. For me, Firestorm is hands-down the worst performing viewer in active development (LL viewer is around 10 FPS faster, other TPVs often 15+). Fastest is a tossup between Alchemy and CoolVL, Alchemy is able to run faster at slightly higher settings due to some AMD-specific optimizations (AMD CPU / AMD GPU here), but loads assets considerably slower and has more bugs than CoolVL. R.e. the bug you found, I haven't tested - I always have EEP enabled, on parcel settings, and the moon casts shadows as expected. But you're better off posting a bug report on the CoolVL forum than here.

You may want to check your CPU thermals, as 'locking' a CPU to it's max frequency (usually) won't stop it from thermal throttling - CoolVL uses more threads than FS (especially in the latest update!) and thus more cores are being used, meaning a weak cooling setup will end up in this kind of behaviour

Have a look at this wiki page: http://wiki.secondlife.com/wiki/LlRegionSayTo llRegionSayTo is an LSL function which allows 2 objects to communicate with eachother.

For all but this, you can use tools built into the AVSitter framework -- I'm guessing from the way you've phrased this line, you want a *smooth* movement NOT a jump cut. Unfortunately the scripts provided in the AVSitter framework can't do this... BUT I recently released a plugin which I've been working on for a couple of months, which is designed to take care of this exact problem. What this plugin does, is (depending on configuration) take control of the user's camera the moment they sit down, and automatically & smoothly transition between camera positions depending on the playing pose, orbiting around the avatar during transition. I've also included a HUD for easy setup. See the video here: YouTube If you're interested in what you see, Marketplace Link I will say though it's *not* a machinima tool, so in order to get it to perform in the manner described (I'm assuming you're wanting the camera to orbit around the avatar throughout 1 single continuous animation) you'd have to split up the animation used to parts in a sequence, which AVSitter can feed into the plugin. The video shows how this works, as the plugin is designed to smoothly transition between pose A (the original pose & camera position) into pose B (the new camera position & pose), so running 1 continuous animation with the camera orbiting would be better suited to a machinima tool (See Black Dragon viewer's machinima tools!)

Sorry to bump, but this is still going on and is now worse than ever. A mere 90% of my group chats flat out don't work - no one can post in them, the 1 or 2 that do work are banning people en-masse because they're talking about topics irrelevant to the group (as, guess what - their group chats don't work either!) This needs fixing NOW. It's gotten stupid with how poorly it's working.

Swapping would only make the camera jump to the target, then travel back to the origin point I did actually implement a function for that this morning, I can call isAntiClockwise(camPos_origin, camPos_target) which will return TRUE if the direction of travel is anticlockwise, and FALSE if clockwise. (Unhelpfully llAngleBetween only returns a positive value, even though it'd be more useful if it would determine the direction of travel as if you could only use positive values you can just run the result through llFabs) I used this to determine whether to add or subtract to ctrlptthrd - this did help a little bit, but it's not as reliable as I would like

You may wish to get in touch with Linden Lab over this as they're a lot stricter on 3rd party exchanges (this may be against ToS) before hiring someone

Or not - my rotation interpolation made this look like a curve, but it was actually linear movement. I've written this code, which mathematically SHOULD be working, the only problem is, that it only works correctly if the movement is anticlockwise (again, concave, convex problem) vector offset = camPos_target - camPos_origin; //offset between origin and dest, in x y z vector ctrlpt = camPos_origin + (offset / 2); //find halfway point between origin and dest //vector locoffset = ctrlpt - llGetPos(); vector ctrlptthrd = camPos_origin + (offset / 3); //find 1/3 point between origin and dest vector ctrlpt2thrd = camPos_origin + (2*(offset/3)); //find 2/3 point between origin and dest vector ctrlptoff = ctrlpt - llGetPos(); vector ctrlptthrdoff = ctrlptthrd - llGetPos(); vector ctrlpt2thrdoff = ctrlpt2thrd - llGetPos(); float radx = ctrlptoff.x * TWO_PI; float rady = ctrlptoff.y * TWO_PI; //vector ctrlpt1 = <ctrlptthrd.x + ctrlptoff.x,ctrlptthrd.y + ctrlptoff.y,ctrlptthrd.z>; //vector ctrlpt2 = <camPos_target.x + ctrlptoff.x,camPos_target.y + ctrlptoff.y,ctrlpt2thrd.z>; float ang = llAngleBetween(camRot_origin, camRot_target) * RAD_TO_DEG; float angthrd = ang/3; float vecdist = llVecDist(camPos_origin,camPos_target); float xoffthrd = radx*llCos(ang); float yoffthrd = rady*llSin(ang); vector ctrlpt1 = <ctrlptthrd.x + (xoffthrd),ctrlptthrd.y + (yoffthrd),ctrlptthrd.z>; float xoff2thrd = radx*llCos(ang); float yoff2thrd = rady*llSin(ang); vector ctrlpt2 = <ctrlptthrd.x + (xoff2thrd),ctrlptthrd.y + (yoff2thrd),ctrlpt2thrd.z>; llSay(0,"radx: " + (string)radx + "cos(" + (string)ang + ") = " + (string)(radx*llCos(ang)) + "\nrady: " + (string)rady + "sin(" + (string)(ang) + ") = " + (string)(rady*llSin(ang)) + "\nctrlptoff: " + (string)ctrlptoff); Heelp!

Please do, I've spent hours on it again today and I haven't progressed anywhere. The idea is that the most direct route between A and B is taken, but never intersecting with the center point (hence why I don't want to use linear interpolation), although in terms of Z over would be preferable I have some code which reliably determines the linear midpoint, and hacks in a method to determine A and B origin = A target = B vector offset = target - origin; //offset between origin and dest, in x y z vector ctrlpt = origin + (offset / 2); //find linear halfway point between origin and dest vector ctrlpt1 = <((PI_BY_TWO * offset.x) + origin.x),ctrlpt.y,ctrlpt.z>; vector ctrlpt2 = <ctrlpt.x,((PI_BY_TWO * offset.y) + origin.y),ctrlpt.z>; The problem is that this only generates a convex curve in one direction (clockwise), but otherwise generates a concave curve in the other direction (which I don't want - it should always be a convex curve) and the curve does not account for the Z axis EDIT: Managed to brute force a solution - Instead of generating a linear halfway point, I generated 2 linear points with 1/3rd spacing, and then recycling the known X Y Z values from A and B, which now generates the curve correctly in both directions Now I need to drink the night away! 😅