OptimoMaximo

From what i can see, it seems to be an avastar rig, and the bones you're selecting and manipulating are the animation bones, which are green. The deforming bones in avastar rigs are blue in color and are hidden by default. Try and find the visibility switches in the avastar interface, once you make the blue bones appear and select one of them, you'll be able to see the weights and, hopefully, be able to transfer weights

The order for a successful custom joint position is the following: Edit your skeleton to conform to the avatar In Pose Mode, CTRL+A "Apply pose as rest pose" Rig

So, first off: you don't need to export the "skin" (AKA the character mesh) along with the garment. There are two main reasons for games to do so, but neither apply to SL. You just need the sweater. One of the reasons is to define an alpha cut by providing a substitute geometry for the body part (i don't know if that's applicable to IMVU though), while in SL the body is always the same and alpha is achieved by using a dedicated clothing asset. In your inventory, type "worn" in search and see if you have any alpha on you, and in such case take it off.

Look on the bar where there is the selector saying "weight painting" : moving to the right hand side, you will see two little buttons with cubes as icons, one with a face highlighted and the other with a vertex highlighted... Notice howw you got the second one enabled: click it to disable it and you should go back to the same weight painting mode you see in the video

You can select the vertices and assign a weight value to them also in weight paint mode. On the header bar there is a little tiny button with an icon made of a cube with an highlighted point, when in weight paint mode. That lets you select vertices so that all your operations, including painting, would be applied only on that selection, giving as result a sharp boundary

You altered the hierarchy, that's what is wrong with its distortion. The avatar skeleton hierarchy can't be altered and it always has to be the same as in a human. What you're supposed to do, in order for a very different structure to work and animate properly, is to take an avatar model, reposition the bones without changing their parenting order, weight paint it like that, then create an animation rig that uses an arbitrary hierarchy for the thing to animate properly and use that to constrain the SL skeleton's bones.

Resizing an already UV mapped and textured mesh is ALWAYS going to have texture stretching/compression, but usually this feat is achieved by using a tool that most fully fledged 3D softwares supply: it's called Lattice or FFD. It's basically a cage made of interconnected points that smoothly deform the influenced object. The amount of smoothness can also be controlled via the tool's settings, at least in Maya and 3DSMax. You can set the amount of subdivisions it needs to have and then editing the cage shape, the influenced object deforms accordingly.

That's the rigging orientation, but for animation using a BVH file, the world coordinates differ, as well as the scale. The animation configuration in a BVH file for SL wants the Z axis forward, Y axis up and X axis sideways. The avatar scale instead is intended to be in inches, for which in the exporter options on the left side panel, the scale should be changed from 1 (meter scale as in native blender) to 0.0254 (ratio between inches and meters). A long time ago, Blender's built in BVH exporter also provided a checkbox "Export fo SL" which apparently did the axis orientation convertion math when enabled (around 2011). Out of curiosity, i just checked the python file responsible for the bvh export, and it clearly mentions secondlife compatibility when listing bones so to not sort them so the order is respected. I also did a quick test and it defnitely works as intended. Reimporting the animation back to Blender, the character comes back in laying down in reverse in comparison to the bvh standards mentioned above, because of Blender's bone roll and orientation standards (inverted in comparison to the bvh standards by default), so that it works in SL Therefore, looking at your picture, the roation that you were axpecting to be side-to side is, instead, correctly interpreted as back to front bow type of motion. You will need to make an animation scene in which you adjust the orientation back to the blender's default standard, because for rigging (if you're not using avastar) the orientation is the one you correctly mention in your post. Hope this helps

That is part of the issue, yes. You created an item with custom joint positions by editing the skeleton that way. Blender on the other hand doesn't support custom bind poses, so rotating the arms into position is no solution. Avastar has its own tool to integrate this workflow though. However, the thing can be done manually as well, it's a bit convoluted but it should be feasible. What you should do to get a custom bind pose for rigging: 1) In pose mode: rotate all the bones into position. Don't move them, rotate only. 2) Write down the rotations applied for the fitting for ALL involved bones 3) Back in Object mode, CTRL+A and "Apply pose as rest pose". It's been a while from the last time i did this, this step MIGHT be no longer available in object mode, in such case switch to pose mode 4) Do your rigging. When done, go to point 5 5) Select the bones you rotated into position at step 1 and apply the same rotations you wrote down, just inverting them. So, for example, say you have rotated a bone 30 degrees at point 1, now rotate it of -30 degrees, so it goes back to the TPose; inversely, with an initial rotation of -30 degrees, you should rotate it back by typing 30. You should now be back to a TPose 6) Select the mesh and go to the Modifiers tab (in the panel on the right) and find the Armature modifier: hit the Apply button so the new mesh shape gets applied. 7) Select the skeleton and CTRL+A "Apply pose as rest pose". The skeleton is now back to an acceptable pose for SL to match the bones rotations (the TPose) 8 ) Select the mesh, shift select the skeleton and CTRL-P to recreate a binding as you did at point 4, this time though you want to keep the weights you have worked on so you do NOT choose "With automatic weights", there is an option to keep the weights or vertex groups unaltered (although i can't remember the exact text) Now you export. However, from your screenshots it also seems that the mesh gets squeezed against the avatar body, which is the other part of the issue. From your explanation, it wasn't clear where you downloaded the skeleton files from. "Their page", but whose? The Linden's wikipage? in this case i would suggest you go to Machinimatrix web site and look for the avatar workbench, as it includes some data for the collision volume bones that are necessary to get the shape sliders to work. Currently, it seems it is the basic skeleton that comes in with collision volume bones scale set to 1, while the inworld avatar requires a set of specific scale and rotations for the collision volume bones to match inworld. Since Blender lacks support of bind poses in general, this can't be done manually and Machinimatrix's avatar workbench files are constructed to fill this gap providing extra data that the collada export will use to overwrite the actual bones scales to something compatible for SL. Good luck!

You did the reverse of my explanation. Leave the skeleton as it is in Blender, go in the vertex groups tab, select the vertex group you want to remove and, on the right hand side of the list, where you can see the + (plus) , - (minus) and the pointing down triangle buttons, hit the button with the - (minus) sign to remove the selected vetex group from the mesh data. The results you are having are due to the deletion of actual bones from the skeleton, maintaining the reference in the mesh data, therefore it confuses the character about what to do with the object and its associated data. Try again as explained above, I'm pretty sure you will succeed. Good luck!

Using .anim format, just make sure to have keyframes set ONLY on the bones that need animation. If you want to do so with BVH, you're out of luck: there's a bug misbehavior in the uploader that sets all joints positions in an animation on all joints regardless whethere they have animation applied or not.

The names are incorrect to begin with. The joints names begin with a "m" prefix, so for what i can read in your image, "Chest" should be "mChest" and so on. This is the art of rigging. People confuses this word with weight painting, but it's not only weight painting, rigigng is ultimately aimed to find a system to drive the deforming bones regardless of their direct parent-child relationship. It's not something that can be taught in a forum post.

There is no difference as a matter of fact Yes, and that's why skin weights can't be imported: they exceed the limit for a single mesh total joints influences. However, you don't have to actually delete the bones from the skeleton: just remove the vertex groups that don't show any influence on the mesh. I don't know if there's an automated command in Blender to do so; however, doing it manually would be pretty easy. Go to weight paint mode and select the vertex groups in the list one by one. If they're not showing any color other than deep blue, you can remove the vertex group. Once done, export and it should work

That's the issue. A BVH file needs tocontain the skeleton definition in its first section, followed by frame time (AKA the inverse of FPS) and by the rotations of animated joints. If it's just an empty animation (meaning no keyframes rotations provided), the file ends prematurely. You might want to try this method: Make a pose at frame 1 that is different than you award hold pose Make the pose you want at frame 5 (so you have quite a few frames to write rotations) Now your BVH files should show the skeleton definition along with the above mentioned additional data. In such case, proceed with the following: Upload to SL with ease in and ease out set to at least 0.5 seconds Set the loop in and loop out to the last frame of your animation

There is no point in doing your test by uploading the file to SL as just looking at it in a modeling package we know what the outcome would be. The issue is INHERENT to the model itself BEFORE exporting, let alone after upload to SL. If i scale it in Maya i get the same exact results you show you're getting in SL. So the provided solution can be detailed as follows: Learn how to model Learn to freeze transforms/apply rotation and scale Listen to more knowledgeable people Stop ranting Quit the assumption that you've done all correctly. Reason for this solution: the provided model is trash left to rot alternately in the rain and summer-hot sunshine for 3 months and stinks from 100 miles away.

The uv map squashes the texture in my opinion. The UV map was probably made without applying scale prior to unwrap. Try applying scale first and unwrap again, if its proportions change, that's the issue

You should try to untick joint position, as that datum is stored in the body mesh and doesn't need to be reinforced by your gloves, which might be suffering of double repositioning. I use my own custom avatar with joint position and clothing for it comes in distorted if i use joint position on them, while they appear fine if i don't.

I guess you're referring to Jupiter's moon XD Alright, in that thread it's explained above the post the link leads to, but in a nutshell (using Blender nomenclatures along with Maya's): When you're done with rigging and the parts you've split it into work as intended, since Bento was introduced you should remove the unused influences/vertex groups. After you're done the removal, the edge seams are going to appear if you upload the meshes. To avoid this, make sure to add at least one bone/joint from the upper hierarchy back to the list of bones/joints in the vertex groups/skin cluster. Example with the head: the head includes weights from neck down to the face bones/joints but it doesn't include the Chest anymore; add the Chest back as vertex group/skin cluster with no weights. Do the same for each part that shows edge seams, like the hands. This is due to the floating point range error accumulation, which this method "strengthen" by providing a reference to a joint that is in use in an adjacent mesh, therefore taking advantage of position inheritance instead of raw calculations to determine the position of that specific mesh part in relation to the skeleton. The famous avatar bodies were created before Bento launched, and at that time one of the requirements was that, regardless of whether they were used or not, all joints needed to be in the list of vertex groups and therefore those didn't suffer of this issue

Did you read my intervention and what it was meant to answer? that's exactly the thing i wanted to make the OP reason about

You haven't misunderstood, i was just asking as the reason wasn't clear to me

What makes you facepalm?

It is definitelya limitation of the skeleton. It's always been like that in SL due to the number of joints in the area. There is a way to diminish the effect, and that's compensate the rotations of the hand with a rotation of the forearm, and the forearm rotation compensated by the upper arm rotation. Look at your own arm: how much can you rotate the hand without rotating the forearm and how much you can rotate the forearm untill the upper arm needs an adjustment to allow such rotation? I don't think you can rotate your hand alone by 90 degrees keeping the forearm stiffly unrotated, unless you break something. Whole martial arts studied and take advantage of this when doing "joint locks"

there is a solution, i explained some time ago in this thread

Indeed that is one method to lower the polygon number in many cases, but when it comes to models that need to deform, it's not a good option. It's often used for generating LoDs or for static objects, like rocks. The whole point of having a high detail mesh and doing a retopo on top of it is to bake normal, ambient occlusion and (in other types of environments) a displacement map to recover those details from the high poly model. Those maps will then "simulate" the original (high poly) mesh details using shader features, in the case of SL you can bake the lighting derived from the baked normal map and AO, so that the final texture accounts for those details that aren't geometrically there on the retopoed (low poly) mesh. Moreover you can also apply the normal map in SL too, so those details get reinforced inworld, but the mesh would be lighter weight and better/easier to rig too.

oh alright then