Jenna Huntsman

Yes, but the new PBR pipeline should make it considerably easier to do so. (I'm not an expert in Blender's texturing workflow, so I couldn't tell you how to do it with the current viewer, I use a different program (which I don't think anyone else uses, but I love it))

This post is from 3 years ago! Anyway, you should post a snippet of your script for us to review. More often than not, it's a mistake, not a bug.

As Quistess said, the best hack right now is to move the location of the joint to correct the deformation. In an ideal world, SL would support shape keys, which are pretty much designed for this exact issue (joints will always deform weirdly at high rotations due to how mesh skinning works). Maybe in a couple years.

All it needs is to detect what state of motion the avatar is in - so, it needs to detect if the avatar is walking, jumping, flying, falling etc. Nothing too major, scripted AOs do this all the time, then activate the appropriate animation on the animesh attachment.

I'm pretty sure the eyebrow layers of LeLutka heads are in blending mode by default - the heads are no-mod, even on the purchased versions (ugh.). *Some* of the "HD" layers allow you to manually select the alpha mode (e.g. the lips layer, which was a feature I requested from LeLutka to fix poor lighting issues with "HD" lips); but the brows are not one of these. FWIW, I think LL made a patch for onion-layering in the perf viewer, although I can't remember if that was before or after the perf viewer launched. Either way, LeLutka was one of the given examples of being borked prior to that patch. (I can't remember the JIRA number)

llGetNotecardLine counts from 0, not 1. So you're actually requesting the blank lines of your notecard, assuming your example is correct (it looks as though there's a blank line between every data line?).

In that case, I'm confused by this line: That sounds to me like you didn't get as far as attempting to apply the settings, but instead the UI was different and didn't get far enough in to apply the settings - so clarification is needed.

Might be a silly question... Have you tried in the Linden viewer? Might be that you've found a bug with the FS version you're running, so firing up another viewer as a sanity check isn't a bad idea.

If you can get as far as the viewer's login screen, post the contents of the Help > About Second Life (or insert TPV name here) window. There's a bunch of info in there which will help the techies reading this forum point you towards things to investigate. Also, if you can - do as Henri says. Post your viewer's logs, which will contain more info specific to the crashes you're seeing. (Also, word of advice - you're better off spending an hour head-desking than you are spending it on the phone to a "technician" at [insert-computer-manufacturer-here]).

The chances are that the reason sales numbers didn't drop off is that a lot of designers make clothing that follows a specific RL reference item, meaning that releasing a Maitreya fit for the item places their item in competition with an item created by a different designer - so, as a user, unless the product has a specific USP (e.g. item is Modify, item is strippable (in stages), etc.), then chances are I'll go buy whatever is cheaper (assuming quality is competitive between the 2). Messaging clothing creators I've found is a very mixed bag, sometimes you'll get people who couldn't care less about feedback, which puts me off contacting others, because I'd be wasting my breath. (Not to say everyone is like this, but I've had enough bad experiences that I'm hesitant to contact creators these days).

FWIW, you may also want to consider using an avatar's display name, not their legacy name - Not a major thing, but some people like to be known by a different name than their legacy name. ( https://wiki.secondlife.com/wiki/LlGetDisplayName )

Aside from I know for a fact that the internal .anim file has only 2 keyframes, as I use AnimHacker (a tool to manipulate animations in SL's internal format), which has no interpolation functions built into it. Only the ability to set keyframe time, and translations. The viewer is interpolating. Linearly. https://en.wikipedia.org/wiki/Linear_interpolation The new data in my example is the rotation data. With the viewer's interpolation, it knows the start and end point of the translation, and the current time. That's all linear interpolation needs, as, if my start point is 0 degrees, my end point is 90 degrees, and my time is 0.5 (2 seconds), then my elbow should be at 45 degrees. That information is not contained within the .anim file, but was constructed as above. (Also, Quistess knows what she is saying on the matter, as she made a tool to convert .bvh to .anim files.)

SL's animations are interpolated between keyframes, in a linear fashion. That's why joint's don't just "snap" between keyframes if those keyframes are 2 seconds apart. Say for example I have an animation with 2 keyframes controlling my elbow. Keyframe 1 is my elbow straight down, my arm resting at my side. Keyframe 2 is my elbow with a 90degree rotation, for example, holding a phone in my hand. Keyframe 1 and keyframe 2 are separated by 4 seconds. When my animation is played in SL, my elbow will rotate slowly over those 4 seconds, despite there only being 2 keyframes. Thus, interpolation. New data where there was none before, based on known data. If there was no interpolation, my arm would snap immediately to the 90degree position.

That assumes the interpolation is linear, but "realistic" motion is almost never linear as joints also have mass, so you'd actually want to use a cubic (or other) curve with smoothstep for interpolating time to create "inertia". So, yes, you don't need keyframes every frame, but at points where motion is starting or stopping then the extra resolution may help. Although, in those cases, you'd want more than 1 extra frame for butter smooth motion.

Arguably you should go to 25fps as that's easier math-wise. Also it gives you 1 more frame of animation data per second. Also follows the PAL (European) broadcast standard (Not that it matters, but the 24fps value comes from the American NTSC standard, so...). (Also, to be an absolute nerd, the spec actually calls for 23.967 fps, NOT exactly 24. Unless you're going for 30fps, wherein you'd use 29.97. NTSC is weird.) Not that it really matters, but hey, 1 more frame of fidelity so to speak.

I agree that P+ shouldn't have launched as half-baked as it was. The good news is that LL is working to automate this part, but there isn't any ETA for it yet, which likely means not this year at least. I could be wrong, but that was the impression I got from the UG meeting where it was spoken about.

This has been the case for a while. The best example of this is when Maitreya Petite launched, as a mere most of the creators couldn't get a hold of the newer devkit required to make Petite clothing. It required them to reapply for a devkit, to then get rejected despite the fact they already *had* a Maitreya devkit, just not the latest one. To my knowledge, they still don't have an effective way for developers to get an updated devkit if they have an older one. Talk about asinine.

This is also the same on Windows and Linux for iGPUs, so with any luck users on an iGPU won't be screwed over if LL does things right. Time will tell.

Just put it in the forum thread, it's a security nightmare downloading files from unknown sources.

My understanding is that most games treat their VRAM settings as hard limits based on the total available from the hardware, regardless of the amount available (i.e. let the OS manage graphics memory as required) SL, on the other hand, is attempting to be "smart" and limit itself to the free memory pool so it doesn't conflict with other applications. Neat idea in theory, although to my knowledge nothing else does this (maybe with good reason, but hey.). Not really my field of knowledge so I can't really make any insightful comments on the matter.

🤞

Short of going elsewhere (the area you're in is using too many large textures), no. The Linden viewers all have an abitrary cap on VRAM of 512MB, which simply isn't enough. LL is working to fix this, but those patches haven't surfaced yet.

If you want bespoke help, you can pay someone (You'd need to post in the Wanted forum). Alternately, you can post the source (you don't always need to post the entire thing, just the section that doesn't work right) here and we can try to debug. The Lindens also won't comment for items which are closed-source, so if you've genuinely found a bug, it'll take longer to get fixed. (As an aside, I don't see why you're so hesitant to post the source in the first place. The kind of thing you're describing is simple, and anyone who knows LSL could create something similar in about half an hour).

Generally exporting joint positions along with rotations is a recipe for trouble. The most reliable way to use joint positions without causing unintended breakage is to export to the .anim format, one without joint positions, one with joint positions. Then, using a tool called AnimHacker, merge the joint positions for the joint-of-interest into the rotations-only version of the .anim. That way, you should not see any (unintended) breakage.

Building off what Lucia said, Blender has a built-in function for simplifying animation curves. Take a look at this tutorial: