Jenna Huntsman

LL have mentioned that in their testing, it was found the existing setups events use (i.e. a single main region with a few satellite (cam) regions) is actually worse for performance vs having all the avatars in a single region on a higher powered machine. Scripts are a weird one that is harder to quantify, as it relies on, among other things: the region's available script time (Event regions have more script time available, due to being allocated more resources) execution time of a given script (the higher this is, the worse the vendor will jam up as it falls behind relative to the demand - this (I believe) is consistent between regular regions and event regions, and can only be tweaked by optimizations from the script's creator). amount of avatars entering the region (as the region will stall for a short moment while an avatar's data is retrieved) (also, during the SLB opening the regions were handling in the area of ~400 avatars!)

FWIW, the upcoming PBR materials are planned to use the following spec (Subject to change!) : Channels Texture Modifiers RGBA Albedo (+ transparency) RGB Tint RGB Normal (MikkT space, Y+) (none) RGB Emissive RGB Tint RGB ORM (Combined greyscale maps for R = Occlusion, G = Roughness, B = Metalness) Float - Metallic factor Float - Roughness factor Conveniently, that channel layout maps to the existing conventions used by UE4 (Except with the normal map, which UE uses Y-, whereas SL expects Y+) and Godot (Uses Y+ normal maps, so no incompatibilities!), so most PBR-friendly programs already support export in that format. Note that in this (proposed) new layout, the only alpha channel in use is contained within the Albedo texture.

EEP presets can be applied at the parcel level; so no - you only need to own the parcel. FWIW, the white water is caused by having the turbidity (fog) level set to be too dense relative to the scene.

I keep an eye on a bunch of SL Discord groups, this issue came up and I remembered when I saw your post!

Assuming this is being applied to a linkset - Have you tried using llGetLocalRot() ? That will return the rotation of a prim within a linkset relative to the root prim, which (if I understand you correctly) should return a value you can use.

Known issue with the latest Nvidia driver, downgrade until it's patched.

Figure I'd make a post on here for once. Refreshed my profile picture. No postprocessing was done on this image! (Taken in the Alchemy project viewer) (More info at https://www.flickr.com/photos/crystalyne/52145921049/in/dateposted-public/ )

Not 100% what you're looking for, but if you want something which will prevent your face from breaking (automatically, requires no user intervention): https://marketplace.secondlife.com/p/Eye-Roll-Stuck-Animation-Fix-for-mesh-heads/21060074

Does your bot also note down any relevant body addons? (e.g. Maitreya Petite, Legacy Petite, Slink Petite, etc.) Would be interested to know the metrics for the addon market as well!

LucyBody is a 'Maitreya Compatible' body, so clothing made for Maitreya will work on LucyBody.

I may be mistaken, but I believe that increasing the CameraFieldOfView value will shift the Depth of Focus forward (or backward, if decreased) of the simulated image plane ('sensor'), thus increasing bokeh. (Source: https://www.opticsforhire.com/blog/understanding-depth-of-field ) Essentially it's a guide value. It's assumed to be ~0.029 mm for full-frame cameras, but in reality CoC is a function of a sensor's pixel spacing (the gap between pixels on a camera sensor - this means that every camera has a slightly different (actual) CoC!) Given that my specs always assume that we are using a full-frame sensor, using the guide value does a good job. You *can* recalculate the entire table based off a different sensor size (thus, different guide CoC value), but for the sake of keeping the length of the table under control I have only given the values for full-frame. The field distance is used to calculate magnification, which we don't need in our case.

The particular hair mentioned above is from No_Match, but to shout out some other designers that ship (most of, be sure to check their listing) their hairs as mod enabled: Monso (they get bonus points as a lot of their hair ships using alpha-masking by default) Yomi (not all stuff from them is mod, so be sure to check their listing)

Mod perms don't do anything to prevent stolen content, this is purely misinformation that gets perpetuated as an excuse to not allow users control of the content they buy. As above, it also prevents users from fixing issues with content as-sold, which is a particularly a bad issue as brands come and go very frequently on SL, so you cannot rely on a creator being around (or, for that matter, caring) to fix an issue with their content. Mod perms also allow users to upgrade content, for example, the hair that I currently wear is sold as a product that uses alpha-blending, and does not use material maps. My modifications have converted it to use alpha-masking, and to make proper use of material maps, so the hair responds to lighting in a faux-real way.

This is likely an issue with forward vs deferred rendering, as alpha blending is done in a forward renderer, however pretty much all other effects happen in the deferred renderer. (This is also why objects that use alpha blending are often lit incorrectly, as the scene lighting happens in the deferred renderer). Alpha blending is a real PITA in many ways, so if the hair is mod-enabled, you can swap it to alpha-masking which will fix the issue (hint: play around with the mask cutoff settings until it looks good, most hairs can look good in alpha-masking but require tweaking). For reference, as well - if you want to learn a bit more about DoF, get some recommended DoF settings, how to calculate your own DoF settings, take a look at my wiki page: https://wiki.secondlife.com/wiki/User:Jenna_Huntsman#Lens_Settings

So, to clear this up, this graph shows you how DoF works from an optical science perspective: (Source: https://www.strollswithmydog.com/equivalence-focal-length-fnumber-diffraction/ ) CameraAngle is the physical angle of the camera's lens - i.e. what you actually see. Changing this is equivalent to swapping a lens, or zooming in or out. It directly affects the camera's Field of View. This actually represents the width of the visible frame. (Thus, the overall size of the image circle). CameraFieldOfView is purely data which is used for the Depth-of-Field calculations, and nothing else. This represents the height of the frame. In an ideal world, we'd actually specify the FoV diagonally, as then it can be decoupled from the aspect ratio of the 'sensor' (the user's monitor), but that's just how it is.

Sandbox area and rentals is one of the more common ways that I see for sims - sandbox drives traffic, in turn will generate interest for the rentals (provided the area is landscaped nice enough).

FWIW, you should also post a copy of the source code here - It's possible that someone here might find something that you missed, or can test and reproduce the problem on their end (thus confirming the idea that there's a bug).

I'd take anything the wiki says regarding execution speeds with a heavy pinch of salt - The vast majority of those values are a decade old, and most definitely don't account for the performance improvements post-uplift.

Looking at the spec for those commands, a tween parameter would definitely be useful for that. (Similar to the parameter seen in the SetSphere command set). (i.e. the ability to issue a single command to smoothly transition between the current and desired FoV values (for that matter, tween would be useful for all camera params, but obvs a lot of work) by issuing a single RLV command, rather than having to use a fast timer to repeatedly send commands to the viewer).

FWIW, about the smoothest LSL-based camera movement can be seen in the demo item at this location: https://maps.secondlife.com/secondlife/Crooked Posse/190/230/2001 It's not perfect but it can work, although again, if you're using it for machinima, viewer-based tools always work best. Regarding use of RLV - Unless this script is purely for personal use, be sure that it works under both RLV implementations (Marine's RLV and RLVa). You don't want to ship a product which is broken to some of your users.

Double check that your animation doesn't have "drift" in it (as, if the animation is moving the pelvis over the course of 30 seconds, you'll notice your avatar slowly floating up). Try turning off your AO, then play the animation from your inventory.

If you were going to go that far, I'd recommend swapping to a viewer with some more comprehensive machinima tools (Black Dragon is the one that comes to my mind, as that allows for full camera control and keyframing) and dump the LSL side altogether. As Quistess said, any LSL implementation won't be the smoothest thing ever (I somewhat disagree with the 'choppy' characterization, as some of the LSL camera control and movement scripts that I've done work pretty damn well but are inherently affected by simulator script load and network conditions) and more than likely not 100% reliable.

I see what you mean, but unfortunately not - Zoom is a function of FOV. The kind of effect you'd get there is called a Snorricam shot, i.e. the camera rigidly attached to the subject moving through a scene. Moving both the subject and the camera simultaneously (but separately) wouldn't work either, as the Dolly Zoom has the subject's scale appear not to change, while any objects in the foreground or background seem to scale independently.

Unfortunately, a Dolly Zoom effect simply isn't possible through LSL as we don't have any control over the camera's FOV value. You can make a script which can smoothly move the camera around, but you cannot manipulate anything more than the camera's position and rotation (and the focal point).

Everyone has their own opinions about security software, so be prepared to receive a lot of suggestions. For the most part, the Microsoft Defender is fine. Comes by default with Windows. I used ESET Internet Security for years on Windows before I made the switch to Linux. Very well regarded.