Jenna Huntsman

*coughs* https://www.materialmaker.org/ Among many other things it's capable of, it can generate the PBR maps (Normal, ORM, Emissive) from an input base colour map (Similar, though not the same as SL's current diffuse map)

He does, as the BVH file format does use a fixed framerate. But the BVH format is only the interchange format, and it's not what SL uses internally. It's also worth noting that BVH is on the chopping block, as it's planned for SL to transition to using glTF for it's animation format (This doesn't mean that you won't be able to upload BVH files, but it will no longer be the primary interchange format). glTF animation, like SL's internal format, doesn't use a fixed framerate for animation.

That page is full of misinformation and was written by a user over 10 years ago. I'm going to add a warning to that page saying that the information contained is incorrect, as while some of the content of the page is correct, broadly speaking it gives people the wrong idea on how things actually work - so ignore the content of that page.

SL animations don't have a framerate - They will run at the viewer's framerate. SL animations are a keyframe based system, and the viewer will interpolate between keyframes (This is why there isn't a framerate for animations, as it literally doesn't matter) - also, it allows LL to 'simplify' animations by removing a bunch of unnecessary data when joints are being moved around, as for the most part this happens at a constant speed, so the only thing that matters is the start and end points, and the time between them.

Simulator framerate is a bit of a misnomer - it doesn't have any bearing on your client framerate. If you're using a monitor which has a refresh rate of 60hz (What most monitors use, some are higher, but if you're not sure you're likely using a 60hz monitor), then you'll see smoother animations when SL is running at or more than 60fps. You'll also have less input lag, and camera movements will be smoother. Having a framerate above your monitor's refresh rate is a bit pointless in SL, which is actually why I find myself running with Vsync on most of the time, especially on mobile computers (Laptop, Steam Deck, etc.) where batteries are a concern. Yup, although it's a bit more complex than that as outside of North America 25 fps is the standard for film, 50 fps for TV (60 in the NA) and for *some* films you'll see 48 fps used. (I work in the industry, this is pointless in an SL context but hey, you just learned something!)

If you're trying to animate the butt's collision volume, yes, this will break avatar physics - this is a known quirk of SL's animation, wherein deforming a collision volume that is affected by physics will stop physics being applied to it. In these situations, using a rigged mesh deformer is the better way to go (See here: https://wiki.secondlife.com/wiki/Avatar_deformation )

The simple answer is that it's a bug that was introduced by Project Bento which has been around long enough to have become a "feature", so there's content that relies on bones not being reset when an animation stops. See many items marked as deformers, for one example. To fix it would likely break other content, so it's not an uncontroversial change to fix this bug, although as of late LL are being more strict about content that is leveraging these "undocumented features".

InMotion is now my go to - I actually found them via Flickr, but they make some very nice animations! http://maps.secondlife.com/secondlife/INMOTION/128/128/2

Depends what needs fixing. Sure, I'll take a look.

If you're manipulating the joint position, then expect all sorts of weirdness. This is because joint positions are changed by the shape sliders on some bones, meaning that if an animation changes them, you can end up with a persistent malformation which remains until logout (on the user's client - for others, once the animation has stopped and the affected user changes region they will appear normally). See some documentation (and the list of bone positions affected by shape sliders) on this page: https://wiki.secondlife.com/wiki/Avatar_deformation

No - this is specifically blocked, and besides, isn't needed. This will work; as your clothing will use the nearest probe volume for reflections (Usually, that means a probe in the same room)

Local != global There's no planned changes around max texture sizes.

Yup, this is (or should be) supported when PBR goes live. There was a discussion in the testers chat and it was stated that this approach should work when PBR goes live.

I'll give this a try

InMotion has a selection of good stuff. I switched to them from Vista, their earlier animations had some odd quirks (As a regular user you wouldn't notice, but for myself as a developer they were annoying to work around) but the newer ones have mostly had solved the issues I was having. http://maps.secondlife.com/secondlife/INMOTION/56/128/93

Have you tried using HTTPS instead of HTTP? Most modern browsers enforce HTTPS, so HTTPS may be working properly, but HTTP may not be.

This would point that Yoast (the site's SEO plugin) is interfering with your script - you probably need to ensure that your script is excluded from any SEO optimizations.

I too got a gift! Very happy with what I got too! Merry moosemas one and all!

This I've found doesn't work - either the viewer is nuking sounds from cache as they're unused, or the region has a silent cap on preloading sounds. The best way to do things is to set up the script to add a sound to the queue, then call llPreloadSound for the next sound to be added to the queue. With that, you should have ~20 seconds for the viewer to download the sound. It's also good practice to call llStopSound after all segments complete, as llSetSoundQueueing can cause the region to (erroneously) continue playing sounds, as if they were looped instead of a single playback.

Figured I wanted to take a new profile picture

One software which isn't listed there, that I've been using to make PBR content is Material Maker - https://www.materialmaker.org/ It's fairly simple to use, it looks intimidating at first but with about 20 mins of watching tutorials you can pretty much do whatever you want. Cool stuff.

Yes - PBR materials use a spec-compliant workflow which means that the transition between Substance (or other texturing program) should be WYSIWYG. Yes. Metallic should render in the same manner as other PBR renderers, including proper reflections of the scene around the object.

I believe a couple of the Alchemy devs have the Steam Deck, may be worth keeping track of Alchemy for updates on Deck specific stuff

There shouldn't be any quality difference purely from which codec was used, the main difference is that HEVC uses more complex (this, more efficient) compression to allow for smaller filesizes at the same quality. I'd say for realtime recording, use h.264, the hardware encoders for it are well tuned, as are the software encoders, whereas HEVC is still being refined in that regard.

We're missing some information here: Are you using software or hardware encoding? (x264/5 or NVENC / AMF (AMD) ) I would avoid plugins for codec support if you're having issues. This is almost guaranteed to be software encoding as OBS does support native HEVC (h265) encoding, although only if it can be hardware accelerated (I could be wrong on that, but I've only ever used it hardware accelerated)