Quarrel Kukulcan

Avastar's strong points are handling Fitted Mesh and animations in a straightforward fashion. (Fitted Mesh is the feature LL added to allow mesh clothing and bodies to respond to all the body shape customization sliders instead of only to about half of them. Fitted Mesh often gets lumped in with Bento because it also involved adding new bones to the basic skeleton, but it was actually a separate, earlier feature than Bento.) Also, if you want to design clothes based on a body in a dev kit, you'll need Avastar yourself if Avastar was used to make that dev kit. You can create Fitted Mesh clothes and animations without Avastar, but it's fussy and requires Deep Technical Knowledge[TM]. Avastar does nothing for you if you're making unrigged jewelry, so that's not a bad start. There's plenty of stuff involved in mesh creation -- UV unwrapping, Levels of Detail, Second Life's sizing and material constraints -- that has nothing to do with armatures and which you have to learn anyway.

Which armature did you start with, and are you using only rotations (no bone repositioning or scaling)?

This fixes the animation name bug (which was my fault) and follows better permission timing guidelines from the scripting wiki. // Set these to your custom values. string cMySkateAnimName = "my skating animation"; float cCheckTime = 0.5; // time delay between checks, in seconds key gOwner; integer gPlayingMySkates; default { attach(key id) { if (id == NULL_KEY) { llSetTimerEvent(0.0); } else { gOwner = id; gPlayingMySkates = FALSE; llRequestPermissions(gOwner, PERMISSION_TRIGGER_ANIMATION); } } run_time_permissions(integer perm) { if (perm & PERMISSION_TRIGGER_ANIMATION) { llSetTimerEvent(cCheckTime); } } timer() { string systemAnimation = llGetAnimation(gOwner); integer IAmMoving; if (systemAnimation == "Walking" || systemAnimation == "Running") IAmMoving = TRUE; else IAmMoving = FALSE; if (IAmMoving && !gPlayingMySkates) { llStartAnimation(cMySkateAnimName); gPlayingMySkates = TRUE; } else if (!IAmMoving && gPlayingMySkates) { llStopAnimation(cMySkateAnimName); gPlayingMySkates = FALSE; } } }

Heh. That's not a totally robust, 100% unbreakable script. I was just giving the core functionality -- and kind of off the cuff. Things like manual animation resetting and laggy sim crossings might get it out of sync. Also, I don't think I accounted for taking the object off and putting it back on. Replacing the whole state_entry() function with this should hopefully fix that: attach(key id) { if (id == NULL_KEY) { llSetTimerEvent(0.0); } else { gOwner = id; gPlayingMySkates = FALSE; llRequestPermissions(gOwner, PERMISSION_TRIGGER_ANIMATION); llSetTimerEvent(cCheckTime); } } I won't have time to seriously check things until later. P.S. If it's for an object that other people can get and put on it'll need to be even more complicated and I've never looked into that.

I wish I could say "you don't need Avastar", but I've had limited success getting pure Blender animations to import properly all the time. EDIT: I made a dumb mistake and things actually work without Avastar. First, I have to work with a rotated model (the method mentioned in this thread: ) And that was basically it. I was able to export frame 1 and import it to get a whole-body locked-in pose, including at least Bento fingers. (I didn't test face or tail.) If I want my pose to leave some bones untouched, I have to keyframe every bone I want my pose to affect, twice: once in its original position for frame 1 and again in its desired pose in frame 2. (OP: Setting keyframes is a basic animation topic you should be able to find tutorials for.) Then I had to export frames 1-2. Finally, either way, make sure "root translation only" is checked when you export. (This is in Blender 2.9, but I believe the option exists in 2.8 as well.)

If you want to play an extra animation, in addition to whatever walk/run cycle your character plays, you're going to want to look at some old Animation Override scripts -- ones that don't use the llSetAnimationOverride() function. The fundamentals go something like this: // Set these to your custom values. string cMySkateAnimName = "my skating animation"; float cCheckTime = 0.5; // time delay between checks, in seconds key gOwner; integer gPlayingMySkates; default { state_entry() { gOwner = llGetOwner(); gPlayingMySkates = FALSE; llRequestPermissions(gOwner, PERMISSION_TRIGGER_ANIMATION); llSetTimerEvent(cCheckTime); } timer() { string systemAnimation = llGetAnimation(gOwner); integer IAmMoving; if (systemAnimation == "Walking" || systemAnimation == "Running") IAmMoving = TRUE; else IAmMoving = FALSE; if (IAmMoving && !gPlayingMySkates) { llStartAnimation(cMySkateAnimName); gPlayingMySkates = TRUE; } else if (!IAmMoving && gPlayingMySkates) { llStopAnimation("my skating animation name"); gPlayingMySkates = FALSE; } } } If you want to play your custom animation instead of walking/running, that's a basic AO. There are plenty of free, customizable ones on the Marketplace and in-world. I use a ZHAO, which is really old-school but still works.

Not under L$100. Under 100 LI (Land Impact).

Jeez, I don't have a professional certification metric in mind. At least 25% less? I'm trying to avoid writing laggy scripts. "Don't do something you don't need to" is one very basic element of optimizing performance, but it looks like this is a case where checking whether I need to do something is plausibly as slow as or slower than just doing it.

Option A: Check whether an animation is playing and only restart it if it isn't. Option B: Just fire off llStartAnimation(). If the animation is already running, it'll simply keep going (not jump back to the beginning). Does Option A have significantly less server load?

That is the normal behavior of looping animations with a Loop Out point anywhere except the very end. Wulfie pointed out one fix. Another is to re-import the animation with Loop Out set to 100%. That way, it will only keep playing for the Ease Out time upon getting a stop signal.

Every object will have a physics mesh, but it's ignored on attachments, plus most world-placed objects only need a simple cube (and even then, only if you care about not letting people walk through them). Simpler is better. A cube or single triangle are all you need unless you're doing something like a chair, or a whole building, or something for a combat sim. Model a cube and a triangle, export them to their own simple files, and just use them over and over as the physics meshes for your other projects. (The exact sizes don't matter because the physics mesh gets scaled to auto-fit the object's bounding box.) Blender import default scale is 1 unit = 1 meter in SL. Match that and you can avoid the need to adjust the scaling tab, which means one less step to mess up by accident. One point of information: no object in SL can have a width, height or depth less than 1 cm. If you upload an object with smaller dimensions, SL will upscale the whole thing until the shortest dimension meets the minimum. You can't break this rule with the scaling tab (and can't shrink the object below that size in SL's edit mode, either). This will definitely hit you if you make small jewelry like rings -- you'll need to make them at an angle or put an invisible cube around them or something to get the bounding box size up. Just get them as low as you can (and understand that it takes professional-level skill to get LI -- the one that matters most -- really low). Every object will have four Levels of Detail: the original plus three lower ones. Second Life makes those three for you if you don't make them yourself. It's pretty bad at it, though you can tweak it a little. The best long-term solution is to develop the skill of making your own. Like Chic already mentioned, this gets out of the realm of "making something in Blender" and into "making an efficient asset for one specific 3D game engine", so it won't be covered in Blender tutorials. Don't despair! Forcing SL to re-use higher LODs for lower ones is one way to prevent bad auto-decimation, but you'll have higher upload costs, and people who wear the item will have higher rendering complexities and possibly get rendered on fewer players' screens. Going too far in that direction defeats the entire purpose of SL having an LoD system. (One last thing I learned about Blender the hard way: whether you "Shade Smooth" or "Shade Flat" an object matters.)

Blender Render doesn't use nodes. Those are just for Cycles (and Eevee, in later versions.) You have to set up textures and texture blending entirely differently, and I'm really not familiar with the old way anymore. You shouldn't be trying to put graininess into the AO, in my opinion. You should add it to your diffuse texture, which will require either a separate bake (if you're using Blender to combine them) or an outside image editing tool . Your AO bake is created out of nothing based purely on your model's geometry -- there is no step where you can add graininess to it beforehand (other than modeling thousands of tiny nicks into your mesh, which would be silly). If you are going to modify your AO map at all, you have to do it afterward.

Mix a little bit of generated noisy texture like Musgrave or Stucci into your diffuse. (Don't use Noise for this in 2.79 -- it doesn't scale and is always pixel-size noise in that version.) You'll have to play around with scale, color and mixing modes to get a good look.

What's the cleanest, most secure, least lag-inducing method to have a HUD panel with multiple buttons all sending messages to be listened for by a single receiving object? I realize I can't have the listen handler filter by sending object name unless each individual button has identical names.

If the whole dress is one face, then, yes, what arton said: make a texture the exact same way you'd make one with parts of it opaque and parts of it transparent (opaque will be bright in the dark, transparent will not), upload it and assign it to the object's face in the usual way, then set that face's alpha mode to Emission Mask instead of Alpha Blending. That tells SL to treat the alpha layer as pixel-by-pixel illumination amounts instead of opacity ratings. You may have to fight with your image editing program a little. The alpha layer is so commonly used to control opacity that a lot of paint programs don't know how to display it any other way. You also need to make sure your paint program doesn't black out totally clear pixels when it exports PNG or TGA files. (GIMP has a "Save color values from transparent pixels" option; I don't know about other programs.) If it doesn't have that option, you can work around it by using a very-low-but-not-0 alpha value for the pixels you don't want to glow.

They are faces made alpha. But one object can only have 8 faces. For this reason, big-selling brand name mesh bodies are assembled from multiple linked objects (or are multiple separate objects worn together, I guess) so they can have more than 6 or 7 alpha panels across the entire thing. To answer your original question: yes, clothing can have alpha panels. There's no difference between rigged mesh clothing and a rigged mesh body from SL's perspective. (BTW: making a face invisible by setting Transparency to 100% flags the object as "an object that uses alpha blending", which quadruples its rendering complexity rating. If the object does not actually use partial transparency anywhere, you can avoid this quadrupling by setting the face to a transparent texture and using Alpha Masking mode with a 255 cutoff.)

If they can be exported in the correct format and obey all SL's limits on materials, textures and poly count. And you don't mind having lousy LODs or have the skill and time to make good ones yourself.

Here's a dumb question: could it be that you're not seeing the last wiggles because they're eased so much they're not noticeable?

I had outro frames. I didn't notice that detail in Lucia's response, and, yes, when the Loop Out is 100% the animation instead goes into Ease Out immediately and ends after exactly that much time longer (though it does continue playing in the meantime, including holding the last frame if necessary). Just inventory those times, but I haven't seen scripts behave any differently today.

I found an old article that says you can rig to a blend of normal deform bones and Fitted Mesh bones and still have animations work properly; the only real effect is that shape sliders won't affect your object by their full amount. My question is: isn't that a huge freaking issue? If your clothes and your body are rigged to different proportions of Fitted vs. non-fitted bones, their shapes won't match each other except near the defaults. Who cares if your animations won't distort under such a scheme? (I presume I'd want 100% Fitted Mesh use to make clothes for the default avatar. Are there actually mesh bodies out there that use less?)

One thing I've discovered about pure (non-Avastar) Blender BVH exporting is that it ignores all bones that never move during the animation. So even if you remembered to shift the hip bone in pose mode (like others have already pointed out), that change won't be exported if you keep the hip bone at the exact same place and angle the whole time. You need to put a minor change in it somewhere -- small enough not to notice but big enough to be detected as a change.

Okay. I just did some testing. When you stop an UNLOOPED animation, it continues to play from where it is for a period equal to the Ease Out time and will fade out the bone movements in those frames. If you are already within the Ease Out time near its actual end, trying to stop the animation does nothing -- it is already in the process of winding itself down and you can't make it stop faster. When you stop a LOOPED animation, it continues to play from the frame it's on to its actual last frame. If the Ease Out time is shorter than that, SL will only apply easing to that much of the end. If the Ease Out time is longer, SL will extend the animation by holding the last frame and ease out over the entire time.

(deleted)

Well, I have to admit I don't know what's causing your problem. Those rigs worked for me. I made a simple shrink-wrapped cylinder around the chest, copied weights, and exported. SL let me include skin weights on import. (The final result was distorted because I don't have Avastar, but I didn't encounter your issue of SL not recognizing the object as a rigged mesh.)

If the problem is with the bones & skeleton, re-rigging the clothing mesh won't fix it.