Jump to content

Gaia Clary

  • Posts

  • Joined

  • Last visited

Everything posted by Gaia Clary

  1. [EDIT] I am very sorry for the bad layout here. I will move this text to our own documentation site this afternoon. About the anatomical wrong location of the jaw pivot point: I am impressed that it took 6 months before it got detected. But i like that request for change. However... in theory you could "fix" this by using bone translation in your mouth animation with all its downsides :matte-motes-dont-cry: About the joint position issue: Indeed there is an issue with the Jaw Bone in Avastar. For some reason this bone's location gets calculated in the wrong way. This also could be the reason for Medhue's issues with the lower lips. I believe that the problem started with Avastar-2.0-10 where we added initial support for partial joint positions (the joint positions editor). I hope this can be solved soon :matte-motes-dont-cry: In the meantime maybe you can check in the Joint position editor if there are any joints listed. If it is an Avastar issue, then i expect that you see list entries for the Jaw and the eyes there: Ensure your Rig is in Edit mode In the Avastar Rigging panel ensure that the Config Subsection is displayed (see top of the image) Check if there are entries in the list of modified joints (bottom of image) If this is so, then you have 2 options: Export without joint offsets Note: This option is just for testing. You should not use it "in general": Open the Advanced section of the Avastar Collada exporter In the Bone Filters subsection disable "Export with joints"  Now import your mesh and see if the jaw and eyes move correctly again. Delete the entries in the joint position editor Note: This is the more recommended way to fix this issue. However we are working on it so that Avastar does not precalculate joint offsets where there should be none of them. Ensure your Rig is in Edit mode In the Avastar Rigging panel ensure that the Config Subsection is displayed (see top of the image) Enable the "All" option then "Remove Joint Edits".  Now export as always and see if the imported mesh behaves as expected.
  2. ChinRey wrote: Well, strictly speaking all the bones in the skeleton are called "collision bones" but that may be hairsplitting. Strictly spoken the Collision Volumes are bones like all others. Their name comes from their original purpose which was to define a super simple mesh replacement of the Avatar: The purpose of this simplified Avatar is to detect whenever the user's mouse is clicked somewhere on the surface of the Avatar. This little piece of information came to me from the Bento team and i believe they know exactly about what they talk, really :matte-motes-sunglasses-3: Red Poly (an SL Resident) detected some years ago that the Collision Volumes can be used for rigging meshes like every other Bone. The only difference between the Collision Volumes and regular bones is that collision volumes are attached to volume sliders. This is why they can be used to "adjust" meshes to the Avatar shape and that is all about it. Rigged mesh and liquid mesh were "hacks" invented by two different groups of clothes designers allowing different points on the mesh to be attached to different bones on the avatar skeleton. The mesh between those attachment points flexes and distorts to follow the movements of the avatar body. Rigged Mesh is a standard method to animate Meshes by use of a Skeleton, also known as Skeletal animation. This is not a hack, this is a standard way to animate characters. Fitted Mesh is more an unintended usage of the Collision Bones for rigging purposes than a hack. But well, unintended usage may be named "hack" if you like to say so. But since LL has accepted this as official method the "hack" has become a feature. However fitted mesh simply uses skeletal animation in a regular way.
  3. Elinah Iredell wrote: What is fitted mesh is it like rigged mesh or unrigged mesh? Fitted Mesh, Liquid Mesh, Rigged Mesh is all the same: It can be animated by the Avatar skeleton. That's basically all about it. BTW the term "fitted mesh" is totally misleading. It should be renamed to "approximate mesh" or "shapeable mesh". But Fitted mesh sounds better :matte-motes-evil: Why don't they have a mesh that does everything? There is a fundamental difference between Prims, Static Mesh and Rigged Mesh: Prims are based on a set of primitive shapes and only can be modified by a set of parameters. Pro: Very simple to define and use. Con: Unflexible Static Mesh defines the Mesh model (vertices, edges, polygons) and its UV Map (The UV Map is needed for texturing the mesh surface) Pro: Arbitrary shapes can be created Con: the amount of effort to create a good Mesh is much higher than with Prims Rigged Mesh is based on static Mesh but it comes with an enormous extra amount of data (weight maps) which is necessary to control the movement (bending) of the mesh relative to the Skeleton movement. Pro: Can be used for more realistic animations when worn on Avatars Con: You need a lot of experience to create a good rigged mesh Why can't the capabilities of each be combined into one? Because providing all the data for every object is not feasible. Remember that there is an upper limit of avatars per Region (~100 if i recall correctly). This is mostly because avatars are moving objects and the more of them are in one location the more data has to be computed before the scene can be displayed. Now imagine what would happen if every object in the scene where animatable. Then your computer would probably take a looong time to create an image of the scene. But you want to see at least something like 25 images per second to get a somewhat dynamic picture of the scene (moving objects without stuttering) Because of this the environment is entirely made of static mesh and prims.
  4. It is possible that the joint offset for the Jaw bone or its child bones is not exported correctly. Have you tried with an earlier version of Avastar ?
  5. Some answers are here: http://blog.machinimatrix.org/what-is-mesh/ Its a bit outdated but it should be a good starting point. I guess its a good idea to update this document :matte-motes-sour:
  6. Yes, indeed there is something odd happening with the eyes. You could try to rig to the mFaceEyeAlt bones instead of the mEye bones. This could possibly help. However we need to look at what happens to the mEye bones in more detail, thanks for checkiong this :smileyhappy: oh.. Does the same issue also happen with older versions of the tool ? Version 2.0-9 of the tool has no joint position editor. I know the joint editor has a few bugs in 2.0-11 but that should not result in issues as you see.
  7. I suspect there is something wrong with the mapping of the armature scale to the exported joint positions. Try the "apply armature scale" option from the advanced export options before you export. If that does not help try Blender's Object -> Apply -> Scale BTW: when we are silent this is more likely an indication of heavy activities in the backyard rather than leisure time on the terrace
  8. There might be cases where the physics trick does not work while adding something (a small cube as in your case) would do the trick. However i never have found an example of such a case. But maybe you or someone else can provide such an example? Then we can examine this in detail, find out why the physics trick fails in that case and add this trick as another solution for another case.
  9. possibly this can help: http://avastar.online/help/troubleshooting/mav_block/
  10. This is an issue with the Blender Collada importer. The default Collada format has no way to define the length of a bone. But we need this to make the skeleton look right. This problem has been partially solved in recent blender versions: When you open the import panel, then you find a control panel in the tool shelf in the lower left corner of the Blender screen:  In the Armature options enable the options Fix Leaf Bones Find Bone Chains. This setting tries to rebuild the bones as good as it can. But this is based on some assumptions so it can never create a perfect result. So you probably still need to manually fix the skeleton after importing. However we have started to improve the Blender skeleton importer to also support bone end points. In fact the Secondlife reference dae files already are prepared for this and Blender version 2.78 will be able to import the dae files lossless. Here is a peek preview of how it will look alike after reimport:  If you like you can get this feature with the daily Blender build within about the next 2 weeks.
  11. you can use any subset of the bones. So for example when you create a pair of shoes, you only need to upload with the foot and ankle bones. Special note for Avastar-2 users: By default the tool automatically detects which bones it has to export.
  12. Here is a work in progress document about the Secondlife Skeleton. Maybe that can be of some help: http://blog.machinimatrix.org/avastar/the-sl-skeleton/ Please feel free to use the comment section and add your suggestions for improvements.
  13. Medhue Simoni wrote: In the case of my nunchakus, it would be handy to be able to quickly attach/parent bones together at will, as in 1 frame they are parented and the next frame they aren't parented, and the next frame they are parented to another bone. I am not sure if you can change the bone hierarchy or the parenting from within an animation. However you can use constraints and animate the influence values over time. Maybe we can add some function to help setting up the needed constraints. Medhue Simoni wrote: You also talked about baking animation, and how the the exporter works... As far as i know the Exporter analyses the animation and exports the data on a frame by frame basis. I think this was done to avoid precision issues but i do not know for sure. Anyways this does not change the animation in Blender, it only affects the exported data. Maybe we could rename the function from "Export Animation" to something like "Export as Baked animation" to make it clear that the exported data is a baked version of the animation in blender. We also can check if we can add an option "bake" to make the exporter a bit more flexible...
  14. Hi, Medhue; One of the reasons why Avastar has duplicated the blue SL Skeleton into the green Control Skeleton was for reusing the control rig to animate the SL Bones in which way ever we want. This includes the restructuring of the control bone hierarchy. However at the moment a reorganisation of the control rig has become a bit tedious because of the IK constraints all over the place. Do you think it is beneficial to simplify the customizing of the control rig so that hierarchie changes become easier? Would this avoid the need for an external animation rig?
  15. Hi; I would like to point you to a new general question&answer forum titled "3D Graphics" which is currently proposed at stackexchange: http://area51.stackexchange.com/proposals/86368/3d-graphics?referrer=SumoV3aZE1OKQcyqcR7pKw2 The site is described as: Proposed Q&A site for the artists and designers behind 3D modeling, layout, animation, and 3D rendering. The cool thing (in my opinion): The site is not associated to a specific tool. So they welcome questions related to any tool as well as tool independent questions about all aspects of 3D Graphics. If you like the idea, then please feel free to join the proposal by "committing to use the forum when it goes alive" and tell others about this if you like it. As a sidenote: I have also used the http://blender.stackexchange.com/ forum for a while and i found it very helpful for getting answers about Blender which i could not get anywhere else :matte-motes-sunglasses-3: Of course nobody knows if this 3D Grpahics q&a becomes realy helpful. But at least one could try it out and see if it is capable to get live :matte-motes-bashful-cute-2:
  16. Medhue Simoni wrote: Why can't the uploader just choose which joints to offset by whether those bones have weights? If I'm not weighting anything to a bone, then I obviously don't really care if it's offset. Right? Hi, Medhue; The Bento Importer allows to import partial Rigs and so it only affects the bones that it finds in the collada file and keeps all other bones untouched. So you can get what you propose above as follows: Blender-2.64 or newer: Disable the deform option for all bones which you do not want to export Then export with "only deform bones" Avastar-2.0-10: Always exports only the bones which are weighted to at least one of the exported meshesAvastar-2.0-11 (coming soon): You can decide if all bones get exported or only the weighted bones (via exporter option)
  17. I tested with blender 2.77 and i found the Collada exporter exports the geometries in alphabetical order of the object name if the export option "sort by object name" is enabled. If you can not get the alphabetical ordering of the geometries to work for you, then please prepare a demo blend file and open a report at https://developer.blender.org/maniphest/task/create/?project=2&type=Bug Then someone will take care of your issue :matte-motes-asleep-2: Hint: Please add the keyword COLLADA : Secondlife to the report title.
  18. Gael Streeter wrote: Indeed, the Bento project had two main aims concerning the mesh heads : To allow to deeply animate the mesh heads To allow to deeply adjust the shape of the mesh heads And these technical issues completely counteract these aims ! I believe the support for Appearance Sliders was never planned. It was added only a couple of weeks ago as an additional goody. And i believe everybody knew right from the begin that appearance sliders and Animations do not work nicely together in all cases. However we have shown a few areas where shape sliders and animations indeed work nicely together provided you only use rotation animation. So maybe it is frustrating that we can not have everything. But at least we got a lot more than nothing by now :matte-motes-sunglasses-3:
  19. Hiu, Gael; I got inspired by your post to add a new chapter to the Bento article on our Website. Please feel free to check it out: http://blog.machinimatrix.org/2015/12/17/avastar-2/#transrot Feedback and ideas for improvement are welcome (either here or on our website)
  20. Kitsune Shan wrote: I had mention this before and even proposed some solutions that could help to solve this. Can you please add some links to your proposals ? Although i recall you had mentioned a few ideas over the past months, i am not able to find your posts related to animation issues and possible fixes. I admit that i am not good with using the forum search :matte-motes-frown:
  21. I made a small change in the "Fully Fitted" Preset that may help a bit (the preset disabled the deform flag for the Base bones. this was not wrong but depending on when you call the preset, you may get very unexpected results. The change lets Avastar behave better (can handle more situations). The change will be released soon with avastar-1.7-3) . However i guess the true reason for what you see is related to how you have set up the Slider system. Below you find a sketch of a workflow which i just tested and found it working as expected: http://avastar.online/reference/fitted-mesh/fit-to-shape/ This should preserve the shape.
  22. Maybe this is a bug or a missing information in the Documentation. Please can you open a ticket for this? Here is the link: http://blog.machinimatrix.org/tickets thanks
  23. I made a few experiments with partial Skeleton exports. And i found a partial export imports fine together with joint positions when the mPelvis bone is included in the exported Rig like in this example: http://blog.machinimatrix.org/wp-content/uploads/2016/04/bento_testboots_1_rootbone.dae  Here is another file which does not include the mPelvis bone and which does not import correct to Aditi when joint positions are enabled: http://blog.machinimatrix.org/wp-content/uploads/2016/04/bento_testboots_2_rootbones.dae  When you look into the skeleton hierarchy (in the Collada file) you see this skeleton has 2 roots mKneeRight and mKneeLeft which might be the cause of the problem. In fact when you look at the image you see that the right leg is correct, while the left leg gets totally wrong. Does this mean that the SL Importer expects to get only one Root bone? So is this an error in the Collada file or is this an Error in the SL Importer? If this is an issue with the SL Importer, then here are 2 ideas how this could be fixed: Import joint positions only for weighted bones In this case the SL Importer needs to examine each imported mesh to find out which weight maps are populated with weights. Then the user can simply export the entire skeleton while the importer only uploads joint positions for the weighted bones. In this case my first example above also works perfect because although it contains the mPelvis bone, no joint position will be imported for mPelvis because the mesh is not weighted to the mPelvis. Add an artificial "Root" bone In this case the Exporter needs to define a "Root" bone identical to the mPelvis bone except for the bone name. The SL Importer knows that no joint position shall be imported for the artificial "Root" and all is well. I personally prefer the first fix, because this automatically optimises the imported meshes (does only import necessary information) and allows us to use the normal Collada exporter and always get a clean Rig.
  24. MoonHowler Snowpaw wrote: Hello, i'm trying to animate with Avastar2.0.9 bones translations of hind legs, but can only rotate them. The unlock locations button does nothing in them, though works on all other bones.Is it a bug or is there a reason for preventing hind legs from bones translations? This will be fixed with Avastar-2.0-10 (also for the new Spine1-4 bones)
  25. Avastar should not complain about missing eye bones... But the tools are still in development so maybe it is a temporary bug, who knows.
  • Create New...