Gaia Clary

Medhue Simoni wrote: I think you mistakenly added brow to your eye bones, but this is the actual eyebrow bones that I suggest... you are right. that was not so good. I edited my post and changed the names.

Medhue Simoni wrote: Kwakkelde Kwak wrote: Both smiles look a bit creepy though I'm sure better weights would help this. The first version of the Bento character had automatic generated weights which have not been touched manually. This could not give good results. We now have improved better weight maps (which have been made with our Face Weighting tool). However the 3 new bones in the center that we added for our demo video actually make the automatic weight generation much better. But don't ask me why that is, maybe it has to do with symmetry and better separation between left side and right side.

Hi; We have been working on the Skeleton for the past 2 weeks. And we have been reading this thread from the begin to the end to understand better what problems are to be solved. So finally here is a summary of the ideas that we have discussed since Project Bento was introduced to the public. The following is the result of what we have discussed in the team. I just have taken all our chats, paper scribbles and noteits and whatnot, added a bit here and there and polished all of this a bit: About the Face One of the youtube videos mentioned in this thread made us think of some possible improvements: Left side: We Added 3 mBones on the symmetry axis (in light blue) Right Side: We created a Face Rig on top of the mBones where every square controls a subset of mBones. The Face rig is only for creating animations in the Animation tool (Blender here). And it is not even half finished:  Please note that possibly we can reduce the number of bones on the lips from 8 to 4 (see further down) The unfinished Face rig as shown above already allows to create animations with very low effort. The video below uses the Bento character with improved facial weight maps (the face uses exactly the same mesh as the SL default Avatar). This is really just a very quick example, we will create a new one when the face rig is fully finished. Also this is rendered in Blender because the modified skeleton can not be used in Aditi (We added new bones): We also allowed the mBones on the face to animate rotation and translation. We believe that allowing translation (location changes) is helpful: It seems to be easier to create decent animations, It allows to use bones in much more flexible ways (especially for non human characters where the bones possibly are used for completely different purposes) It looks like using translation on the face bones is very common practice. Also motion capture data for face animations might be easier to transform into SL animations (because motion capture actually captures location changes) About the Scaling problem Obviously there must be something that makes using translations really a bad option for Second Life. However we have been working on a similar issue last year, see here: http://blog.machinimatrix.org/sparkles/animation-scale-tool/ Maybe this is basically the same issue? Then it might be possible to fix this for SL animations as well (within the SL Viewer). About Lips and Eyes We also have been discussing if some other general changes on the skeleton could improve the Avatar further: So, do we loose something (for humans) when we only have 4 lip bones? And do we gain something (for creatures) when we use 4 Eye brow bones? Here is an alternative bone setup proposal for eyes and mouth(same number of bones as on Aditi, but with a slightly different layout): mFaceLipUpper (centered) mFaceLipLower (centered) mFaceLipRight (corner) mFaceLipLeft (corner) mFaceEyeBrowUpperRight (centered) mFaceEyeBrowInnerRight (corner) mFaceEyeBrowOuterRight (corner) mFaceEyeBrowUpperLeft (centered) mFaceEyeBrowInnerLeft (corner) mFaceEyeBrowOuterLeft (corner) mFaceEyeLowerRight (centered) mFaceEyeLowerLeft (centered)  Only 1 wing root but 2 tails To allow a second pair of legs without need to create odd animations: mWingsRoot mTail1Left mTail2Left mTail3Left mTail4Left mTail5Left mTail1Right mTail2Right mTail3Right mTail4Right mTail5Right This change allows to add a second pair of legs which are attached to mPelvis instead of mChest. This leads to 11 bones compared to the 9 bones we have now.  Also Creatures with tail and 2 pairs of legs could reuse the wings as tail and possibly get a wiggling tail "for free" (because of the automatic breath animation for the chest) Alternative to the 2 tails solution: "constraints" This idea came to our minds when we where working on the bone constraints for the Avastar IK Rig. The idea is: Parent the Wings root to the Spine, but also add for example a (configurable) constraint to the local rotation of mChest to mWingRoot. If possible make the constraint target configurable, so that users can "clamp" the wings to mChest, or mTorso or mSpine, or mhead, ... To explain this a little better: This idea does not change the topology of the Skeleton. It only adds bone movement constraints which make one bone (the driven bone) follow another bone (the controlling bone). Bone constraints are very common in animation programs, so maybe it is also doable in the Second Life Viewer. We use this technique in Avastar to separate the deform bone animations from the Rig (so we could add IK based animations) Generalize constraints If constraints can be implemented in general, then this concept could be generalized to work for all limbs, then users can for example constrain the root bones of the legs, arms, wings and tail to mSpine and create a 7 legged creature that can be animated without adding odd rules to the animation. Thinking even further, if location constraints where allowed, then this idea allows to constrain any limb to any bone. Wings could then be constrained to eye brows for antennas, tail(s) could be constrained to chest for 4 winged creatures, etc.

Hi, Medhue; What you see in this character's weight maps is just the result of a simple Automatic weight from bones which does not at all work for this sort of rig. In fact the automatic weight from bones only works properly for "limb like bones", you can see that on the character's fingers and tail which have also been auto weighted with no manual tweaks at all but work properly out of the box. We shipped the "Bento Angel" with these not at all satisfying initial face weights to get something out as quickly as possible and we are working on enhancements already Improvements ahead: For the face we are about to test an idea which could possibly generate by far better suited initial weights for the face. We will get into this in the next few days. The lips: I also miss a bone at the center of the lips. Something like mFaceLipCenterUpper mFaceLipCenterLower would be awesome improvement here. Rotation versus Translation: The rig was constructed such that the issues with rotation get minimised: You see the joints are all placed deep inside the head. But of course you are right, the mesh still gets distorted in an odd way when you rotate too far. I am not sure why bone translation is forbidden. Nobody could tell me so far the reasoning behind this decision. maybe it related to some issues with the appearance sliders...

Do you happen to upload "with Joint Positions" enabled? I am not at all sure if this is the problem, but maybe this page can be of help for you: http://avastar.online/workflows/fitted-mesh/joint-positions-with-fitted-mesh/ Although this is a page for Avastar the principles should remain valid for pure blender as well.

i suspect there is one vertex unintentionally weighted to the wrong weight maps. Probably the misbehaving vertex either is assigned to the WeightMap mHipRight or it is not weighted at all.

Hi. I got your blend file. But let me answer here, it may be interesting also for others: I tested to upload your mesh. When i just load the mesh i get the same distorted blob as you see as well:  This is astonishing, because i expect that importing a mesh for the very first time should reset the viewer settings anyways. But it seems to use some random numbers here. However, when i "Clear Settings & Reset Form" then i get this: This looks to me as expected (mostly). Regarding the distortions on the ears: You use attachment point weighting there. I used the SL Default Viewer. Because of this not all attachment weights are imported. Especially the weights on the ears and the nose are not taken into account. You might get better results with Firestorm. Regarding the crossing of the front legs: this is normal and related to the previewer using a human default stand pose which does not work at all for non human meshes. So after all i do not see exactly where the problem is. Are you sure you called "Clear Settings & Reset Form" ? Maybe Firestorm behaves different compared to the default viewer?

Try this: In the SL Importer hit the button "Clear & Reset Forms", then see if the problem disappears. If this does not help, then please file a bug report to us at http://blog.machinimatrix.org/tickets and please include the blend file for inspection.

are you sure you exported with the Avastar collada exporter?

SpookyYuki wrote: I simply open blender and create the model that i want from there i mark the seams and unwrap it i export the UV layout into photoshop and begin adding the textures once i have done that i add the texture layout to the model in blender So lets continue guessing blind folded :matte-motes-sunglasses-3: So i assume now your textures are in Blender and you have assigned them as Face textures to your model. You can see the textures on your model in blender when you have set the viewport to Texture mode. SpookyYuki wrote: then export the model as .dae making sure i have use textures checked Do you use the Preset "SL + Open Sim Static" ? You might want to do that to ensure the other settings are correct as well. SpookyYuki wrote: from there i import the model to second life via "upload mesh" Have you set "include textures" in the options panel?

maybe you can describe your steps (with screen shots), especially which options you set in the SL Importer in detail. For example you have to enable "include textures" in the upload options panel (right most panel) of the SL Importer

The Second Life importer does not allow to import textures for rigged meshes. This problem exists almost since day one of mesh so i suspect this is kind of a "feature not a bug" thing. For static meshes (not rigged) the import of meshes combined with textures works at least for the default SL Viewer. What 3D tool do you use?

You only need to enable "Include joint positions" in the Options tab of the SL Viewer's Collada Importer. You might want to try applying rotation & scale of your objects before you export from Blender. Maybe there is a bug with the automatic apply of the Scale&rotation during export.

The option "Apply Armature Scale" is only good for the situation when you have scaled your Armature in Object mode AND when you have created animaitons for your scaled object. So Instead of first applying the scale to the armature, you can use this option to avoid applying the scale in Blender. Why you might want to avoid applying the scale to the Armature in blender The problem is that when you have created some animations for your model while the armature was scaled in object mode, then applying the scale to the armature would partially destroy your animations (all keyframes that contain location keys will result in odd distortions of the animation in that case. If you want to understand this in more depth, then please take a look at http://blog.machinimatrix.org/sparkles/animation-scale-tool/

You could ask in the chat group "blender avastar" or create a support ticket on our site http://blog.machinimatrix.org/tickets But please note that we want to inspect the blend file, because there are so many possible reasons why things could go wrong. It could be due to the combination of used modifiers, because of shape keys, scaling and rotation issues, child parent relationship, and of course there is always the chance that you have found a bug either in Blender or in Avastar or in the SL Importer. We can not give any answer without knowing what you have done. And our answers take some time. The best you can do is to prepare your question so that we can easily reproduce your issue. i hope this is convincing

You are aware that you can have no more than 4 weights per vertex? From what i can see i suspect that your model uses more than 4 weights per vertex at the jaggy areas of your mesh. The Avastar exporter automatically reduces the number of weights to 4 if necessary. This can result in problems like you see. I am not very good at guessing what else could cause such issues. So i can't be very helpful unless i can take a look at the blend file. As i already mentioned you can simplify the blend file and remove everything that is not related to the problem.

enable "Apply armature scale" in the Avastar exporter

This text refers to Blender. However other tool users may still get some insight from the following: UV Maps in a nutshell a UV Map is a list of relations between plane areas on your mesh in 3D space and plane areas in your textures in 2D space. A UV Map is not an image! Each mesh can have 0 or more different UV Maps. Initially a mesh has no UV Map at all. You create a UV Map by unwrapping the mesh. In Blender you get a UV Map created automatically during an unwrap if the mesh does not yet have one. In that case the UV Map is named "UVMap". You find the list of UV Maps of an object in the Object data properties (the Mesh properties) This list is named "UV Maps". Here you can add or delete UV Maps. Any follow up unwrap will always overwrite the active UV Map (the one marked with the blue background) You can rename your UV Map to anything you like. The name of the UV Map is only used for organizational purposes. Joining objects, joining UV Maps If you join 2 or more objects, then their UV Maps (if they have any) are joined as well. Following rules apply: UV Maps with same name in the objects are merged. UV Maps with different names are added In practice most unwrapped Objects use the UV Map name "UVMap". Hence joining 2 objects also merges their UV Maps. Sometimes an object uses different UV Maps for different purposes (You can do a lot of magic with different UV Mapping in Blender). In that case the joined object will get a melange of merged maps and added maps. How this can be useful i do not know. But i also see no way for blender to do it better in that case. Sometimes the joined objects parts each have only one single UV Map but with different name. In that case the joined Object ends up with a list of UV Maps from its parts. This may be interesting when you want to have clearly separated UV Maps for each part of your mesh. However IMHO this has no practical use in Blender. UV Map merge has changed with newer Blender > 2.73 In earlier versions of Blender the UV Maps have been merged/added according to their list index, hence when 2 objects have each one UV Map only, but with different name, the joined object had the UV Maps merged into one single UV Map (due to the same list index 0) In newer versions of Blender the UV Maps only get joined when they have the same name. This obviously can lead to confusion when you do not know anything about what UV Maps are, how they get created used and maintained. UV Maps, Textures and Materials A UV Map defines a mapping between your object surface and image areas. So you still need to provide textures which match to your UV Map. Thus you always have: The mesh (3D space) The Texture (2D Space) The UV Map (to relate the Mesh to the Texture) But note: In Blender you can have many textures for different parts of your UV Map. Actually you can map each triangle of your mesh to a different texture if you like (in general this does not make sense). In Second Life you can have up to 8 texture faces (areas on your mesh which can be assigned to individual textures). This is also related to the UV Mapping but not as straight forward as you might think in first place: Blender supports 2 ways to assign textures to your mesh. Above we have only talked about direct mapping, that is assign parts of your mesh to parts of your image. But you also can use Materials for this. Here you add one level of indirection to the system: The mesh (3D space) The Material list The Material Textures for each material (2D Space) The UV Map (to relate the Mesh to the Texture) A Material creates a by far more complex relationship between your mesh and your texture(s). However if you want to make use of multiple texture faces in Second Life then you must use Materials (one for each texture face). UV Maps in Second Life In SecondLife mesh objects only support one single UV Map although this map can be assigned to up to 8 texture faces (See above). This needs to be taken into account when you export your objects from Blender. The Blender default exporter has 2 options: only selected UV Map: so you can decide which UV Map is used in cases where your object has multiple UV Maps. include material textures: to get the textures from your Material set (you want that!) Note that recently LindenLab has improved their SL Importer to "support more than 8 texture faces per object" While this is true on user level, technically the SL Importer cuts your object into pieces and creates a link set. Check it its true :matte-motes-sunglasses-3: And Youtube is your friend Here is a short video where i tried to explain how UV Maps actually work: I hope this is useful and not too overwhelming. However i realise that whatever is related to 3D content creation quickly seems to become a complex thing. But... take your time. Things always sort out eventually.

UVMap is the default name that is given by Blender. Maybe you use an addon that does some UV Mapping magic and creates UV Maps for you in the background?

in blender one object can not have 2 UV Maps with the same name. I would expect that blender crashes when it gets this :matte-motes-asleep: I am afraid you do not have kept a copy of the blend file for inspection?

Pamela Galli wrote Could be, but baking the textures was the last thing I did. Why the texture would look one way in Blender and another inworld is one of many many things that will probably always remain a mystery to me. Recently i found that under some circumstances the SL IMporter is cheating on you. I tried this for example: I select one dae file that i wanted to import I prepare everything in the Uploader I realise that i have selected the wrong dae file, so i step back to the first panel And select the correct dae file now I import And get a messy mixture between the first selected file information (skeleton info) and the last selected file information (weight maps and mesh data) It may well be possible that similar issues occur with static mesh imports. Because of this i meanwhile always do a clear&reset forms before anything else. Maybe this is not what happened to you in this case, but it could, maybe, or not :matte-motes-nerdy:

hi; For me the easiest way to understand what is going on here would be by taking a look at the blend file. That should mke the problem discovery much easier :matte-motes-wink:

Since you mentioned you have Avastar, let me give you a list of helpful links here: How to get help: http://blog.machinimatrix.org/avastar/reference/getting-help/ Please start here:http://blog.machinimatrix.org/avastar/start-here/ The avastar product page: http://blog.machinimatrix.org/avastar/ The Avastar Chat group in SL: "blender avastar" Then we have two courses that go deeper into the details, where both courses have one free lesson which already tells you most of the essentials. Here are the links to the free lessons (including videos): Second Life Skeleton: http://blog.machinimatrix.org/lesson/sls-1/ Non human rigging: http://blog.machinimatrix.org/lesson/nhr-1/ And should nothing of the above help, then you always can open a ticket on our ticket page: http://blog.machinimatrix.org/avastar/tickets

Hi; Today i found a project proposal on stackexchange for a new Q&A forum: http://area51.stackexchange.com/proposals/86368/3d-graphics-modeling-animation This project is a tool independent question&answer forum about creation of 3D content in general. I personally make a lot of use of blender.stackexchange which is an already approved stackexchange forum and which has gathered very good and acurate information over the past 2 years. However the new project has the advantage to be cross product and as such it potentially can bring people together who otherwise might never talk to each other. So i want to make you aware of this project. I believe having such a forum is not a bad thing at all and all of us can benefit from this even more. If you like to support this project, then actually you only need to ask a few (no more than 5) example questions on their site and upvote a few (no more than 5) example questions which you think are appropriate for this forum. i hope this is valuable information. cheers, Gaia

AnaisCallipyge wrote: However, since I intend to commercialize this work, you will understand that I am a little reluctant to send my file to anyone who will be, although I do not doubt your good intentions. You always can create a simple test model as long as it shows the same errors. Actually we even recommend that users only send us the minimum that is needed to reproduce the problem. But at the moment we still accept when someone sends us a production file to get quick help.