Quarrel Kukulcan

Banning new ones. A person who can't afford a new car and has their existing car die will be in the same situation they would be today: needing to buy an affordable used one.

Well, initially I didn't think it was possible to export a SL-usable .dae file from an Avastar-specific save file using vanilla Blender, but I tried it again just to make sure I don't mislead you, and I actually succeeded. The only steps you mention that I had to follow were reorienting toward +X (and applying) and exporting with bind info. Color me surprised. What's the nature of the distortion? Can you post a screenshot? Deflated limbs and chest indicate bad or missing Fitted Mesh bind info. Limbs zig-zagging or swung forward and back are an orientation problem. Regarding and You don't want to do either of these. If you're making clothes to fit a dev kit body, your first step once your clothes are modeled is to transfer weights from the body to your clothes, then maybe do some fine-tune painting. The only bones SL cares about either start with "m" or are in ALL_CAPS. (Well, plus attachment point bones, but those aren't intended to be weighted to.) Anything else in your armature is added by Avastar for its own internal use and excluded from the export. If your mesh is actually weighted to these non-SL bones, I suspect Avastar does internally during every export what you manually did yourself. If the dev kit rig lacks SL's m-bones, I'm not sure you can reconstruct the basic SL skeleton simply by renaming Avastar's internal-use bones. There could be all kinds of subtle internal transforms it puts those through behind the scenes.

An animation's priority is a property of the animation itself, and once the animation is in SL it can't be changed. Scripts can't play animations at different priorities or make them override each other on demand. (When people talk about "a priority 3 AO" what they really mean is an AO full of priority 3 animations. It's not the AO making them pri 3.) A chair object could, in theory, stop your AO's sitting animation -- but it has no way of knowing its name or UUID, so this can't work in practice. (And if your AO cycles through different sits, the chair would have to kill each one within a fraction of a second. That's even less feasible.) So the solutions you're looking at are: don't define any chair-sits in your AO (ground-sits are fine) only use chair-sit animations with lower priorities than the ones in the chairs you want to sit in turn your AO's sit-override option off (if it has one) turn your AO off

That's basically just how it works. You need to import your texture images separately. 😕

There is a slim possibility that you had the armature selected instead of the shirt when you exported.

Blender Guru's donut tutorial is excellent at learning the basics of 3D modeling (and the techniques aren't even program-specific, though all the hotkeys and menus will be). https://www.youtube.com/watch?v=TPrnSACiTJ4 Most of his later lessons -- and he has a lot -- aren't applicable to SL, so don't be intimidated. Anything dealing with Blender's shading & material nodes or general lighting techniques is skippable for SL purposes. One thing to be aware of, though: there's "making a good 3D object", and then there's "making a good 3D object that works well in Second Life". Long story short, you're not just making a single object that looks great in a carefully-prepared single shot. You're making an asset for a realtime 3D game engine. Learning how to model will only be half the journey. Unfortunately, I don't know of a good single source to point you to that summarizes all of SL's construction limits, technical quirks and expected optimizations. I may have to throw something together if the pros don't.

There's no way around needing 3D modeling knowledge if you're working with mesh objects in this form. Other programs might have simpler interfaces or be more directly designed to handle clothes in particular, but you need to be familiar with the fundamentals no matter what. EDIT: Avastar will correct the sucked-thin deforms but it won't make anything easier. That said, you don't need to work with the model if all you're trying to do is change the surface appearance. That's retexturing, and you "only" need something like Photoshop or GIMP (and clothes with Modify privileges). You'll still need artistic talent but the tools are a lot less complicated.

Any animated clothing article or body part needs an armature. That's what the mesh's flexibility definitions are tied to. I don't know what kind of edits you're making to these clothes, but if you're adding or significantly moving parts you're going to have to learn a lot more about weight painting and 3D animation. Whoever made that DAE file available could have just assumed you knew what extra software you needed and/or already had it. This is a workaround for exporting BVH animations correctly with vanilla Blender but I haven't seen it recommended to orient models correctly. In object mode, rotate your armature about the origin so it's lying on its back with the head pointing toward +Y and the face looking up at +Z. (The mesh should move with it.) Apply all rotations to the armature and the mesh. Re-rotate the armature to the proper orientation (head pointing up toward +Z, face looking toward +X). Don't apply rotations. I don't know if it will fix your problem. Can you post a shot of the distortions you're seeing? If the arms and torso are in the right places but sucked super-thin, that's a Fitted Mesh / devkit issue. If one arm is stretched forward and the other is stretched back, that's an orientation problem. Another way this shows up is if you click on the Joints option ("Joint Positions" in Firestorm) in the import preview panel. You'll see blue ovals for your collision bones. If the model is oriented right, they'll run along your limbs. If it's wrong, they'll go crosswise.

How are you getting the clothing model file you're importing, and what armature are you rigging it to? A lot of clothing creators use third-party add-ons. You'll need the same add-ons (or deep, technical Blender knowledge) since vanilla Blender won't export those models properly. Clothing needs to be rigged to LL's Fitted Mesh bones in order to change shape the same way today's popular mesh bodies do, and those bones have hidden complexities that some programmers have created paid tools to handle correctly. The forward orientation warning can be ignored if the model imports with the correct direction.

Are you sure? 39.37 (not 39.7, which looks like a typo) is the meters-to-inches conversion factor. That's what I'd expect to need if the skeleton in Blender is about 2 units tall.

(and alpha can be used for three different things: a partial, blended opacity, a hard cut-off between clear and opaque, or an emission value (i.e. a per-pixel fractional Full Bright)) Normal maps in SL look like green light is coming from the top of the screen and red light comes from the right. In technical terms, this is a "swizzle" of +X/+Y. It's the same setting Blender, Maya and Unity use. Some other software uses a +X/-Y swizzle, though, like Unreal, 3ds Max and Valve's Source engine. You'll have to reverse one of the components if you use a normal map made for one of those. Normal map alpha is the per-pixel specular glossiness (or "anti-roughness", if that's more intuitive to you). It combines with the face-wide Glossiness value to determine how in-focus the reflections of the sun, moon and nearby local lights are. Many people misinterpret this as specular strength, but that's not the case. It's just that when this value is low, specular reflections get really spread-out and fuzzy, which makes them appear weaker. Specular map is the per-pixel specular tint. It combines with the face-wide (Specular) Color to tint and dim the reflections of the sun, moon and nearby local lights. Specular map alpha is the per-pixel environment reflection strength. It combines with the face-wide Environment value to determine how strong the reflection of a fake, generic skybox is at that point. It gives a metallic/glass look.

The spikes "appear" because some vertices are weighted wrong. So the correctly-weighted vertices around them move properly, but the vertices with errors stay motionless and get left behind. Aquila told you one way to see how the weighs are wrong -- which is kind of useful -- but that way doesn't tell you what the weights should be and it doesn't let you fix them. The fact that moving an elbow made the errors show up does not mean you need to add more elbow weight to the error points. You need to figure out what the weights should have been in the first place, and that's often hard because it's usually a combination of two or three and it will be different for every bad vertex. Fortunately, you can often simply copy all the weights from the nearest correct vertex and that will work fine. If you have done no manual painting or editing, you may also be able to fix it by recalculating automatic weights for single bones (though again I'd warn you to SAVE FIRST in case you accidentally recalculate EVERY bone and erase all your weight fixes).

mFaceRoot seems to be getting used in place of mHead in the LL-supplied sample rig. As odd a practice as that seems, you're going to have to use some bone as the basis for head movement when something isn't 100% an ear or an eyebrow. Anything you take off mFaceRoot will have to go onto mHead (or mSkull, which even LL doesn't weight to AFAIK). FYI: There is no official LL Bento head in-world. The weighting in the LL-supplied Bento-rigged example avatar is just that: an example (and it doesn't take Fitted Mesh bones into account, either!). The system avatar is still the old, pre-Bento mesh.

I sent you a DM with the reason.

Making 3D models and animations for Second Life is harder than making 3D models and animations.

.

Don't just look at which bones the vertex is weighted to. Look at the weight numbers. That vertex has a weight of ZERO to the thumb bone. It needs to be 1.0.

The same way normal maps are used in any other 3D renderer, I imagine, which I think is a vector add. They're not. That's a single 2:1 image.

If you're working from a combined texture asset, maybe. Like this one: I don't imagine it's common, though. It affects all of them and locks them all together.

Check if there's a seam when you use a totally flat normal map (RGB 128/128/255 everywhere). If there isn't, the inherent normals are customized correctly.

Wow. Kudos to you and your bravery. I don't think many artists hand-paint normal maps. The two usual approaches to creating them are to generate them mathematically from a separate, higher-detail mesh, or to create a grayscale bump map (possibly by hand) and then convert it. Normal maps are not intended to be editable or even be usable images; they're rotational data that's been jury-rigged into a form that existing image file formats can store, and it's only coincidence that they're as human-readible as they are. Your first big problem is how LL didn't line up UV borders very well, particularly the bottom edge of the upper body's UVs with the top edge of the lower body. (pic #1). The borders don't just have different total lengths, but individual corresponding edges don't match angles or lengths. You can't get textures to line up perfectly across these borders on a per-pixel basis for anything that uses BoM. The other problem is how your mesh body handles its inherent normals along the outer border. If Legacy's modeler did not configure custom base normals into the vertices along the joints, those body parts will appear to have a sharp seam between them even if the vertices line up perfectly when both parts are worn (pic #2). This is because every vertex has its own personal idea of which way "straight out" is from its spot on the mesh, and by default it's auto-calculated as an average of the face angles around it. But the bottom rim of the torso doesn't know anything about the angles in the legs (and vice versa) -- all that face and angle data is in a different object! So it can't average their facings and ends up using purely its own flatness. If the Legacy mesh has this issue (and it might not -- good mesh bodies don't), you can correct this somewhat with a normal map, at least in theory, but it won't be perfect and it'll probably take a lot of fussy trial and error.

The problem is that you have extra, bad weights mixed in with the good ones. If your left thumb isn't moving correctly, you can't just check that is has the correct weight to the left thumb bone. You also have to make sure it has no other weights. Accidentally getting some weight from your hip or chin or right wing bone mixed in will mess things up. @Aquila Kytorialready mentioned using the vertex Item Info panel. You can also look at your model in Weight Paint mode and click through every single weight group while looking for red areas to show up where they shouldn't be. If you're looking at the right shoulder group and parts of your right fingers turn red, for example...that's a problem.

These aqua lines, from one of your own images: They mark where you want your model to look like it has a distinct, sharp edge between faces instead of the usual smooth transition. Looking at some of the other model pictures, I don't think they're random anymore, so don't worry about them.

It would probably be a good idea to slide everything forward so the origin is between the feet. That's where SL expects the skeleton to be. Then again, I've never worked with Animesh pets.

Weight painting isn't working because you've somehow switched from the Draw brush to the Averaging brush, which means all you're doing is averaging the existing weights together instead of painting new values. (see pic #1) mTail6 is weighted pretty well, but it looks like you also accidentally painted the end of your tail with both mTail6 and mGroin in almost the same way. Take the groin weighting off. mTail5 is almost good but the red area is too large. Weights should be about 0.5 at the joints, not 1.0. mTail4's weighting is jagged and irregular. mTail1 is also irregular, plus it has stray extra weighting in the hip. mTail2 and mTail3 never go higher than 0.5 anywhere. See pic #2 for a rough idea of how weights should go, or watch https://www.youtube.com/watch?v=GEwZTN8LBo0. (EDIT: Oops. I see you've already seen that video since you posted that link yourself upthread. Still, watch how the artist paints weights around the joints. Pay attention to the color there, and how fast it fades off, and what brush mode the artist uses.) Your mesh overall has a lot of random edges that are aqua because they're marked Sharp, for no apparent reason. You should clear those. Finally, and this is a bit of fine tuning: your tailspikes shouldn't bend. You can fix this by giving every vertex in a spike the exact same weights. (see pic #3 for one way to do this)