Gaia Clary

Are you aware that Avastar-1.7 is working best with Blender 2.76 or newer while Avastar-2 needs blender 2.77 at least? Did you read the Avastar installation document? I tried to make this document as informative as possible: http://avastar.online/reference/install/ If the written text in the document above still does not help you, then you should open a ticket in our ticket system http://support.machinimatrix.org/tickets/ and describe exactly what you did and how it failed. However if you are not able to install the Addon into Blender then i suspect that Blender itself has an issue, probably a broken Application data folder, something like this possibly: http://avastar.online/help/troubleshooting/installation-issues/

Leviathan Flux wrote: ...in Maya, I noticed this version of the skeleton has "Segment Scale Compensate" turned off on all the joints. For Maya, this means that when you scale a joint, it affects all the parented joints, so if you adjust the scale to widen the shoulder, the lower arm and hand will also go wider. Can you post one dae file where "Segment Scale Compensate" is turned on and one where it is turned off ? Has something fundamental changed in our demo collada files between recent versions? This was surely not intended. About the Fitted Mesh bones: You are right they should have been added too. I see that we now have too many export options which makes it easy to forget parts I will add an export option to our exporter that allows to export "the essential Rig" (or whatever we will name it at the end) that includes all mBones and all volume bones.

Mel Vanbeeck wrote: The left and right center eyebrow bone is clearly positioned higher than it should be. I went and verified that the avatar_skeleton.xml values match the values we have in Maya. I don't know what's causing that one bone to be out of place, or whether it's just that one bone that's out of place (other bones may be less noticeable in their position error). It is indeed a bit unexpected but it is on purpose. Now before you complain please first read ahead :matte-motes-confused: What happens is that Bento now has added 5 new sliders for editing the eyebrows. These sliders are located in the Hair style editor. And the values for the default Hair style do not match to the SL rest pose skeleton. The bad guy here is the "Eyebrow Points" slider which moves the center eye brows up and the inner eyebrows down as you have shown in your example. The good news is: You can fix that by editing the Hair object that you wear (in the Eyebrows section):  The orange lines in the image indicate the slider range for the inner and center eyebrows. You get what you expect when you set the Eyebrow Points slider to a value of "0". The bad news is: You must edit the worn hair wig (nowadays the bald cap in most cases) and set the slider value to 0. This might be a bit shady and confusing because we have 2 places where to customize the face appearance: Shape and Hair. However this was so since the beginning of Second Life, so it should be a well known customization feature. Now you may complain or not :matte-motes-sunglasses-1: Note For Avastar users: Avastar currently does not support the new Eyebrow sliders. However i believe that we add this feature after all other issues have been solved.

Interregnums wrote: I exported the wall using Firestorm, which exports the file as a DAE file. This DAE file wouldn't open in Blender and so I opened it in a third party program to see if it had in fact exported properly. It had. Are Dae files exported by firestorm not importable to Blender in general or is it just this one file? However if you have a dae file that does not import to Blender but works with other 3D programs, then i propose you open a report on the blender developer site. When you add Collada to the title then it will be checked faster. If you do not want to expose your .dae file to the public then you always can arrange something with sending your file directly to whoever takes care of the issue. (just ask in the report)

Mel Vanbeeck wrote: The layer ending in 03228 (with no _ncl1_x extension) corresponds to the mGroin bone, keeping with the pattern. I mentioned already that data exchange between tools is a nightmare :matte-motes-sour: So the main problem is that Maya can assign a bone only to one bone layer while in blender a bone can be assigned to multiple layers. I wonder about the layer name of the mGroin. I would expect to see something like this for example: mgroin has bone layer "2328" mHindLimb1Left has bone layer "2330" Mel Vanbeeck wrote: I suspect that in the long run, the .dae file in the wiki will not be used for anything other than importing the skeleton to various programs to bind custom meshes to, and possibly copy weights from. Other than just a basic test, I don't see why anyone would be importing this .dae directly to SL without doing some sort of editing on it first. From that angle, perhaps a .fbx rig would be the more useful file to have in the wiki for the purpose of getting started in whatever 3d program. I see what you mean, the dae files are probably more useful as a reference and less useful for testing the Import to SL. So i can add another target "3dtool" to the Avastar Collada exporter. Exporting to this target would then: export all mBones, all attachment bones and all Volume bones add all bones to all bind shapes in the Collada file does not provide any layer information does not use the Blender profile This export option may be useful for creators who need to exchange their modified skeletons with other creators who use different tools. However, you mentioned that FBX would be more useful. I am curious what makes FBX superior to Collada in this case? And which version of FBX do you recommend?

Teager wrote: Confusing is right! I never would have guessed that I'd need to disable "export with joints" in order to successfully export my joints. Please be patient with us. This stuff is totally fresh made and there was close to no time to make things work nice for the everyday usage. It is just a lucky coincidence that disabling this option makes the exporter work! Name it Contrabug it you like :matte-motes-nerdy:

We have trouble with getting the sliders to work together with modified skeletons and joint offsets. Here is a work around until we fixed the joint offset issues: First of all: Do NOT use the joint offset editor in the Rig Config Panel. More precisely do not use the "Store joint edits" button in the rig control panel. Also take care that the list of "modified Joints" in that panel is empty when you open your skeleton in Edit mode. You can "remove joint edits". Also do NOT use the sliders in Avastar after you edited the skeleton. At the moment any use of the sliders will reset your edited skeleton to the default setting (this is what we need to fix). And Second: When you export your models then take care to use the following settings in the Collada exporter: Enable(necessary to get your models into SL!): Only Deform Bones Export SL Rotation Disable: Export with Joints (Yes, disable it, see below!)All other options can be set as you like. Why disabling the "Export with joints" is necessary: The joint offsets are the differences from the original location of the bones to their current location after you edited your skeleton. We need this information only to get the Sliders to work correctly. But as long as you do not touch the sliders, you can edit the skeleton as you like. But then Avastar should also not take any joint offsets into account when exporting: So when you do not use the sliders and when you do not define joint offsets, then you can safely disable the usage of joint offsets during export. In that case the Rig is exported "as is" and that is actually exactly what you want. Sounds complicated? yes, but i have already plugged in my irons to make this part going smoother :matte-motes-sour:

Can you tell me which bones are assigned to which bone layers for a couple of bones? I also presume Maya can assign a bone to more than one bone layer... correct? For the Bind Pose warnings: I can add an option to Avastar for exporting "with full bind pose" . This would create a complete and fully valid Collada file. However this Collada file will not be usable for importing to SL because of the bone count limit of 110 in the bind pose. But i believe the warning about not all bones in Bind pose is paranoid. Everything should be consistent as long as the mesh is only weighted to the listed bind pose bones.

LeafIllusion wrote: ...Generally if you look quick when saving the Collada file with Blender you will see a error message flash in the upper right corner of the screen that says the “Export file is empty". This is not an Error its a fact. And we added this popup to inform the user that most probably something was going wrong. I changed the message to: No objects selected -- Created empty export file I hope this makes it clear what the user should do next without the need to read documents :matte-motes-evil-invert:

Hi; Yesterday i added 3 new Collada files which are meant to be useful for import to SL and for import to Maya. Could someone who has access to Maya please check if everything is good for you and report back any issues? The files contain the full skeleton, no bone layer data and no Blender profile data. The files should work for import to SL and for import to Maya: Bento Angel with eyes (2016-07-18) Female Default with eyes (2016-07-18) Male with Eyes (2016-07-18) If i know what to fix, then i can try to improve the files for tool exchanging purposes :matte-motes-smile: And if all is well or acceptable at least, then we can ask LL to replace the dae files in the wiki by the new ones.

If you mean "preserving texture faces" during merging objects then you can do this in blender: Before you merge the parts create a new Material in the object's material editor. Best is to name the material in a reasonable way so you later can find it easier in the material stack of the merged object. Once you have defined all materials you can merge the objects into one combined object. The material associations will be preserved and all should be well.

Drongle McMahon wrote: In Blender, edited normals are also exported correctly, but if you use the "triangulate" option on (or apply some modifiers after the normal-editing ones) make any changes to the geometry after editing them, they get badly distorted (unless the mesh is already only triangles). I thought we had fixed custom normals issues in the Blender Default Collada exporter. It should export meshes "as is" (with all modifiers applied except the Armature modifier) and take care of custom normals as well. Is there any situation where the Exporter itself exports normals in the wrong way? Maybe there is something missing in Blender or something has changed recently. When you triangulate a Mesh that already has custom normals, then i believe the result does not preserve the normals. This could be also true when you use the triangulate modifier in the modifier stack. But this is related to blender and not to the exporter. If you have a demo blend file that shows that a visibly (in the Viewport) intact mesh gets exported with wrong normals, can you create a report on the blender site for this? Please add the keyword "Collada" to the report title. that helps to get those things fixed much faster :matte-motes-nerdy: thanks

Drongle McMahon wrote: I would rather see an explicit option, use <triangles> or <polylist>, instead of a hidden response to triangulation. As well as giving more control, that would make sure the results of uploading existing files doesn't change unless the option is selected. From the user's point of view it should make no difference how the tools talk to each other. The only true benefit for using Triangles where ever possible is that the collada files can become a bit smaller: You do not need to record the number of verts per face because this is 3 for all entries. So i guess it is best to use triangles when the exporter is called with the triangulation option and use polygons otherwise. And then fix the collada importer in the SL viewer. :matte-motes-sunglasses-1:

I could change the Blender Collada exporter to use <triangles> instead of <polygons> when the "triangulate" option is enabled. This seems to make sense. A user could triangulate manually before exporting and then export with triangulation enabled. this should not do any harm when the meshes are already triangulated. I could also do some optimisation and inspect the meshes before deciding whether to use <polygons> or <triangles>. This seems to make sense as well, but maybe its a bit too much? Another thought comes to mind: Doesn't this make people believe that higher poly counts become more tolerable? Not sure...

About: " The following parent and/or ancestor node(s) is/are not part of the BindPose definition. I suspected that something like this will happen. The reason for this warning is most probably that each mesh part has only those bones defined for its bind pose which are actually also used for animating the particular mesh. This means when you have the full skeleton defined in the skeleton node hierarchy, but only some of the defined bones are included in the Bind poses of the meshes then a tool might consider this to be an inconsistency. However for the SL Import we want it exactly like this. The reason is: The SL Importer refuses meshes if they have more than 110 bones in their bind pose. But if you split the character into 2 or more sub meshes (head and body for example as we did for the bento angel) and then only specify the necessary bones for each mesh, then you can still import the character with a full skeleton into SL without hitting the bind pose bone limit :matte-motes-evil-invert: I am not sure if we should change anything here.

Hi, Mel; Transferring data between tools seems to be never any joyful experience. I have taken a look into this and i modified the Avastar exporter a bit in the hope it helps Maya users: For the Blender Profile issue: I added an option to not export with the blender profile. This is supposed to stop the Maya importer from complaining about the blender profile. For the Bone Layers issue: It is possible that Maya's importer does not know how to handle the layer information and then decides to add each bone on its own layer. Can you tell us how the bone layers are named after import? Maybe this can give us a hint what's wrong. However, i added an option to export the data without the Bone Layer information. This should stop Maya from adding bone layers. For the Node Transform issue: I am not sure what to do there. As far as i recall Maya complains about invalid transform nodes also when it is given its own Collada exports for importing back :matte-motes-mad: It could be related to the usage of Matrix elements in the node hierarchy instead of the also valid <location>,<rotation> and <scale> decomposition. Before i try anything based on believe, can anybody tell me about what exactly Maya complains and how we can make it happy? Here are 3 new Collada files which should work for Maya and for SL: The files contain the full skeleton, no bone layer data and no Blender profile data. The files should work for import to SL and for import to Maya: Bento Angel with eyes (2016-07-18) Female Default with eyes (2016-07-18) Male with Eyes (2016-07-18) Please can you report back any issues with these files?

The warning symbol (the blue circle with the "i" in it) in the Mesh Info Panel is meant to show a popup box with a detailed explanation about what's up. However this text was missing. Here is what should be seen when you click on the ( i ) icon and i hope this gives a reasonable explanation for why this is flagged as problematic (This text will be added in the next Avastar update): ---- Begin of text ---- At least one Texture Face with high Triangle count (nnnnnn). DETAIL INFO: In SL any Texture Face has a limit of 21844 Triangles. If a texture face uses more than 21844 Triangles The SL Importer automatically splits the face into subfaces. And each subface is treated by the SL Importer as one extra Material. This can lead to unexpected results: More than 8 materials If a Mesh has more than 8 materials the entire mesh gets split into submeshes. You might want to avoid this. Missing Material in LOD When you let the SL Importer generate LOD, then it may end up in a weird state where it calculates different Material counts in the lower LOD's which results in an Importer Error. YOUR ACTION: Reduce the number of Triangles in your Mesh Take care to create texture faces with less than 21844 triangles ---- end of text ---- If anybody believes this text can be improved, feel free to correct me :matte-motes-sunglasses-1:

Hi, Medhue You may be pleased to see that the mEye bones now scale custom meshes similar to the system eyes. I have collected some more details about the newest changes here: http://blog.machinimatrix.org/2016/06/27/avastar-2-0-alpha/

Medhue Simoni wrote: @Matrice or @Gaia - A video on how these controls work would be much appreciated by many. well, yes... Is a video realy helpful here? Isn't a short text document better suited for this? http://avastar.online/help/rigging/ http://avastar.online/workflows/ But i understand that our documentation still does not support users well when they do not exactly know for what they are looking (which terms to search, which topics to learn, which workflows to follow, ...) We try to improve :matte-motes-bashful-cute-2:

I believe the slider range for the jaw bone was related to how the sliders combine with each other and that we only have up to 4 weights for each vertex. It appears to me that the chin bone could possibly take over most of what the jaw bone does on the jaw. Please remind that we got the chin bone only 2 days before the slider system was finalized. Maybe we can take another look into this and optimize the Jaw bone location and the related sliders a bit. But you also should remind that 4 weights per bone need a lot of experimenting to get 40 sliders working all right on the same region. As a sidenote: a while back we made a demo video that shows how each slider influences the system character face. And of course this is all depending on how the vertices are weighted to the bones: You can see why the teeth bones, have been added, how the mouth moves independent from the jaw, etc... Unfortunately you can not see what the hidden bones do (jaw, tongue, face root)

In Avastar 2.0-10 or newer: From the Bottom Menu in the 3D View call: Add -> Avastar -> Extended  When the Avastar menu does not show up like that or when you get errors while adding a new Avastar Skeleton like this, then you probably need to fully deinstall Avastar (Remove) and install it again. The problem is that installing a newer version sometimes does not delete all files from earlier versions and polute the tool

Mel Vanbeeck wrote: Situation 2 means that you've got to cross your fingers that you can get the sliders to put the bones where you feel they belong, then hope that the head doesn't turn into a prune when you revert the sliders to export. You can tell the Collada exporter to export the mesh using the "current shape" and make this compatible to SL by fixing the Inverted Bind shape matrix. I do not want to go into the details about how this fixing is done, but i can tell you that it works also on the head bones :matte-motes-nerdy: Here is an image of our demo dwarf (note we didn't edit the joint positions for this) :  Middle: Export using default Inverted Bind Shape matrices Right: Export using fixed Inverted Bind Shape matrices So you can do something like this (provided your 3D tool supports it of course) Use the sliders to arrange the skeleton (face bones) as needed Do your animation work Store the sliders values into a shape file Export your Mesh with the fixed inverted Bind Shape Matrix Import your mesh (as usual, you do NOT need to import with joints!) Import your shape (The Firestorm viewer can do that) wear the Mesh and the imported shape And do the happy dance

The newest version is: avastar-2.0-alpha_blender-2-77.zip When you install this you should see the new export options and Avastar's product version number 2.0-11. But beware... We have some trouble at the moment to get the joint position editor to work properly together with the shape slider system. The goal is to let you edit the skeleton completely independent from the Shape that you use. The problem is that the shape sliders move the bones. So when you edit the skeleton while you have loaded an arbitrary Shape, then the tool needs to find out where the edited bones would be located when the skeleton is in the Second Life restpose. Then the tool can calculate the "true" joint position offset. Actually this is already working for almost all mBones. But for some funny reason the jaw bone and its children misbehave here. I bet this is somewhat related to the issues on the lower lips and the chin that have been reported by Medhue.

Gael Streeter wrote: I do not understand why the mFaceTeethLower is not parented to the mFaceJaw but to the mFaceRoot. Is there is a reason for this ? It is related to how the jaw is used together with the Shape Sliders. Please make this experiment either within Avastar or by using your Bento Viewer (there is a show bones option somewhere in the Advanced section or in the Developer section of the viewer): Select the rig in pose mode (show bones in the viewer) Make the face bones visible Open the appearance slider section (Chin) Move the Chin Depth Slider and check how the chin moves in relation to the mouth Open the Mouth slider section Now move the Shift Mouth slider and again check how the mouth moves relative to the Jaw I guess this makes it clear why the lower teeth have not been parented to the Jaw bone. Yes you have to animate the teeth and the jaw in parallel in that case. And yes, its not perfect.

The Joint position section is here: Ensure your Rig is in Edit mode In the Avastar Rigging panel ensure that the Config Subsection is displayed Regarding the Jaw position: There is a trick to avoid moving the joint in edit mode: Note: It is important to do the following Before you Bind your mesh to the Avastar Rig: Select the Avastar Rig Open the Appearance Slider section Open the Chin slider section Move the "Jaw Angle" Slider to a value of 80 (or whatever suits best for your purpose):  You see how the joint position of the Jaw changes dramatically with the slider settings. Now bind your mesh to the Rig. Of course you need to tell your customers to keep the Jaw angle at 80 or at least close to that value "to get optimal results". But also note the jaw bone position depends on a couple of sliders: Jaw Jut Jaw Angle Chin Depth Head Stretch Egg Head So this may work in some case but not in others.