Jump to content

Gaia Clary

Advisor
  • Posts

    2,002
  • Joined

  • Last visited

Posts posted by Gaia Clary

  1. "They made it look like in a few short clicks all skin hair etc etc are imported."

    This must be a total misunderstanding. Blender is of course capable to import virtually any mesh model. And Avastar can of course use any mesh model for rigging purposes. Also Blender can of course handle any texture, also skin textures, and Avastar just can make use of that data. So in principle yes, you can import your full avatar into blender with a few clicks...

    But you have to get the data first, you need the textures as image files, you need the models as mesh data files (collada, fbx, ... whatever blender can import).

    So the misunderstanding seems that we provide a feature to export your avatar fully from SL with all  clothes and all textures and import all of this with a few clicks into Blender. But this is not what Avastar does. This is what possibly an SL viewer (firestorm?) could provide. Letting aside that all assets (skin, clothes, body) must fully belong to you so that an export of all of this becomes legal.

    One word about the "ugly metal looking silicone avatar":

    Yes, this is the raw system character as it is defined in SL. It IS ugly but it is a precise reproduction of the SL system character. In default view it has no textures and so it looks "unfinished". However Avastar comes along with a demo skin (see image)

    And one final word about "avatar that not even close to the real you":

    A mesh model looks vastly different once it is textured. And also you have to take care about the head as many avatars come with a mesh head nowadays. Of course Avastar does not use a mesh head, but it uses the SL system character head here. So...

    Please let us know from where the misunderstanding comes and we make sure we correct the wording to make it more precise and more clear :)

    cheers,
    Gaia

    avastar_models.png

    • Like 2
  2. Hi;

    Its a bit complicated to explain. But let me try:

    The short answer for the Howto people

    When you export with Blender 2.79 then also enable the new option "keep bind info". Then you will see the SL Importer treats the meshes again as expected. But note: This only works when the Armature has been prepared (contains the bind information of the collision volume bones). If you want to know more details, then here is ...

    The long answer for the Why people

    In older releases before Blender-2.79 we have added a quick fix for exporting fitted Mesh. With this quick fix it became possible to export the Bone scaling for fitted Mesh bones into Collada. The Exporter handled this automatically.  The bad thing here was that the necessary extra data (the collision volume scaling) had to be added manually to each Collision Volume Bone (see the last chapter in the Fitted Mesh Kit page ) and that was extremely error prone and not very user friendly.

    However, the demo meshes that we provide for Blender already contain this data and so users normally would just open the demo blend files, create their mesh attachments, export to Collada and all is well.

    In Blender 2.79 we have generalized the fitted mesh support into "Basic support for importing meshes with Bind information" (bind pose support). This means now you do no longer need to have special made blend files but you can import Meshes with Bind poses from Maya, 3DS Max, etc. and get the necessary bind data into place as long as you import "with bind info".

    So the generalized situation in Blender 2.79 is like this:

    • For importing meshes we now store the Bind information when the new import option "keep bind info" is enabled.
    • Consequently for exporting meshes the bind information is now only exported when the new option "keep bind info" is enabled.

    However the new export option "keep bind info" is not part of the exporter presets and needs to be enabled manually. But you can create your own export presets (that is what i did for myself)

    i know i tend to talk too much. But i hope it was at least helpful ?

    • Like 1
    • Thanks 4
  3. @OptimoMaximo ok, i can see a bit better now how the BVH animations behave. This is my find as far as i understand it from some tests:

    1. The first frame is not played (only used as control frame, see Rule 1)
    2. The second frame is played 3 times
    3. Then each consecutive frame is played once.
    4. To get the in% and out% for a loop correct the triplation of the f1 frame needs to be considered in the calculation (see below)

    So for a 3 frame animation (f1, f2, f3) with one prepended reference frame (rf), the animation plays like this:

    (f1), (f1), (f1), (f2), (f3)

    If you want to make a perfect loop over the animation (f1,f2,f3), then:

    1. set in to 50%
    2. set out to 100%

    This setting would then play (f1), (f1), (f1), (f2), (f3), (f1), (f2), (f3), ...

    ok, sooo we actually can do something in our software to help the BVH adicted :)

    • Thanks 1
  4. hi;

    From the images i suspect you are using Avastar-1 together with the Alter to Restpose feature. However from your rig it does not look like you actually need to use alter to restpose as the rig looks like it is already in restpose ?

    Your best option here would probably be to do this:

    • Take care the Rig is really in Restpose (ALT-R ALT-G ALT-S)
    • Now bind the mesh either with weights from Meshes or with Weights from Bones (whatever matches best for your purpose)

    Then no distortions should appear.

  5. Hi;

    I recently was testing to see if our long standing rules for exporting BVH really create valid animation files. However i found some oddities where the various "believes" on the web did not match with my finds. So i have collected a new rule set for BVH animations that seems to apply nowadays as far as i can tell. However i am not sure if this is totally correct or just works sometimes by chance. The new rules are here:

    Rule 1: First frame of an animation defines the startlocation of the animation
    Rule 2: First frame of an animation is not played (unless the animation has only one frame)
    Rule 3: One-frame animations work (despite of rule 2)
    Rule 4: A bone is only animated if animation values differ at least on 2 frames

    Some more details are here:

    https://blog.machinimatrix.org/2018/06/20/rules-for-exporting-bvh-animations/

    Can someone acknowledge or dismiss this ruleset?

    For Avastar users: the most recent daily build avastar-2.4-24 contains the new rule set so you could actually check if it works for your purposes.

    thanks,

    cheers,
    Gaia

  6. Today we (at blender.org) have added a new feature to Blender’s Collada Module, that is a very limited support for bind poses. This feature has been added to support foreign developer kits which have been created using poses different from the SL T Pose.

    Of course our Avastar Blender Add-on does make use of this new feature. But also all Blender users who do not use Avastar for whichever reason can benefit from this feature. A more detailed information can be found here:

    http://blog.machinimatrix.org/2017/03/23/limited-bind-pose-support-for-blender-279/

    The feature can be found in the daily blender builds starting from tomorrow (24-march-2017):

    https://builder.blender.org/download/

    The feature is briefly documented in the blender documentation:

    https://wiki.blender.org/index.php?title=Doc:2.6/Manual/Data_System/Files/Import/COLLADA

    We are aware this feature will be important only for a few people, especially those who have created or actually do custom work with A posed human developer kits.If the term bindpose does not say much to you, you better ignore this topic until we have created better documentation for it :)

    Any feedback is welcome as always.

    • Like 2
  7. To which version of Avastar do you refer?

    For Avastar- before 1.7-4:

    Please update the Avastar version to 1.7-4 and see if this helps.

    For Avastar-1.7-4:

    If you can succesfully export a collada file from an older version but not from 1.7-4 then please send us a report into our Avastar ticket system. We will take care of this.

    For Avastar-2.0-23 and older:

    Please file a request for testing Avastar-2 into our Avastar ticket system. You then receive a download link for the newest update that we have. Please see below

    For Avastar-2.0-28 - 2.0-36:

    Please update to Avastar-2.0-37 and see if you still have issues

    For Avastar-2.0-37:

    Please send us a report into our Avastar ticket system. We will take care of this.

    But note: We will update to Avastar-2.0-38 soon (hopefully tonight) which has one more improvement for the update tool.

    please note: The Update tool was a major part of our work for the past months to fix all sorts of situations which we had not foreseen in the past. Of course it is still not perfect, but i believe it has become much better than any version before. Although we still can not handle every situation. For the most part it should do now.

    • Like 1

  8. DreamCrawler Martin wrote:

    Gaia, After reading your last message I just tested with your lastest avastar version with the intention of reproducing the same issue when parsing a BVH with translations made in blender

    Yet again, for me, blender avastar BVH export does not seem to include translations. Or if it does, it gets, somehow, ignored by SL.

    It depends what version of Avastar you use. For example Avastar-2.0-23 was never tested for BVH exporting... Also as far as i recall the option to allow "with translation" was unintentionally not showing for the BVH Exporter for a couple of Avastar-2 versions. We did not see that because we tend to use .anim all the time :matte-motes-sour: I believe this has been fixed at least in avastar-2.0-37 but i will take look into this before Avastar-2.0-38 gets uploaded to make sure it works there.

    What i know for sure is that the BVH Importer seems to neglect subtle animations especially regarding lips movements.


  9. DreamCrawler Martin wrote:

    I am not a big fan of blender. But made that same animation test with avastar template. Found out you cannot export translations on BVH format on avastar (makes me wonder why).

    The bvh-exporter in Avastar-2 is capable to export also with translations. I admit there was a bug in the user interface that has hidden the option in some of the beta versions.

    However we found that the .anim format always seems to provide better results regarding precision of the imported animations. Maybe because the .anim format does not get optimized during import?

  10. We know that there are many people who first want to try then buy, Therefor we offer full money back to everybody who is not satisfied or finds the program is not capable to serve your expectations. So you safely can purchase, test and decide if you want to keep it or give it back if you think it is not good for you.

    At the moment we are even going so far that we offer the full money back guarantee for everybody who ever purchased this program at any time and has become upset with us for any reason. So far we had one person over the past 5 years who has taken advantage of this offer.

    Here is the still valid offer for reference:

        http://blog.machinimatrix.org/2015/12/15/avastar-christmas-2015-present/

    And in case you are looking at using this program for Bento then please also check out this page first:

        http://blog.machinimatrix.org/avastar/fcs-2

    I hope this helps

    • Like 2
  11. Briefly: You can use Collision Volumes and mbones both at the same time for weighting purposes. However it may be important to know what that actually means. Below you find an excerpt from the Avastar documentation about Fitted Mesh support

    Citation from the Avastar.online website:

    mBone - CollisionVolume pairs

    We have pairs of (mBone, CollisionVolume) like for example (mPelvis,Pelvis), (mTorso,Torso) etc.
    For those bones the sum of the weights in both weightmaps define how the bone pair influences the mesh during rotation and translation. While the weight on the Collision volume alone define the influence of the appearance sliders (scaling).

    So you can distribute your weighting between the mBone and its paired collision volume without changing how the mesh behaves during animation. While the more weight you put on the Collision Volume the more influence you give to the appearance sliders.

    Note: By distribute your weighting i mean that for each vertex the sum of the weights on the mbone and its paired Collision Volume does not change.

    Physics Bones

    We have a special set of Collision Volumes added for physics purposes (PEC, HANDLE, BACK, BUTT) Those Collision volumes are also parented to mBones but here the relationship between animation and appearance sliders is a bit more complicated. I believe the pairing for mPelvis, mTorso and mChest is like this:

    • (mPelvis, Pelvis + BUTT)
    • (mTorso, Torso + LEFT_HANDLE + RIGHT_HANDLE + LOWER_BACK)
    • (mChest, Chest + LEFT_PEC + RIGHT_PEC + UPPER_BACK)

    So you can distribute your weighting between those mBones and any or all of their related Collision Volume Bones without changing how the mesh behaves during animation. While again the more weight you put on the Collision Volume the more influence you give to the appearance sliders.

    In practice

    You just take your weight paint brushes and paint until your mesh behaves about right. This works for the simp[le bone/volume bone pairs (see above) without issues for large portions of your meshes. You only get trouble near the bone joints where you need to take special care about how to distribute the weights among the related bones.

    The 4 weights per vert limitation

    However when you add weights to the physics bones, then you can very easily get above the limits of Second life which say :

    no more than 4 weights per vertex

    This limitation gives you headache when you use all fitted mesh bones on your mesh

  12. Hi;

    While looking in more depth into the various development kits for mesh avatars i stumbled over an issue. I have the impression that the fbx files which are distributed as "specifications" are actually not matching to what is used in the SL Viewer (the avatar_skeleton.xml).

    I may be entirely wrong or misunderstand something. So i made a small writeup and posted this on our website. If anyone has an opinion on this (Linden Lab, please look too ...) please feel free to comment either here or on our website. Any useful hint on this is really very welcome

    http://support.machinimatrix.org/36703-2/

    Thanks

  13. Hi

    Today i detected that the male/female .dae files in the SL wiki are broken. I wanted to upload new ones but i have no permission to do that. So i just added them to our workbench website:

    http://blog.machinimatrix.org/avatar-workbench/

    To Lindens: Please feel free to grab the files from our website and put them into the SL Wiki :matte-motes-sunglasses-2:

    oh, if you do not want to visit our website then here are the files as well:

    Bento meshes: (without any warranty)

    Note: I did not add the male versions because it is not clear to me in which way the male versions shall be prepared to make any sense. Like: do you want the male meshes with the female restpose? Or shall i modify the skeleton ? or do you want the meshes with bind pose? Any hint is very appreciated. thanks

    • Like 1
  14. I am not ignoring notecards on purpose, its just so that our main communication is done with our ticket system, which has many advantages, like for example that no ticket is ever forgotten. Notecards can easily be burried in the Inventory and overlooked quickly.

    For the availability of the next update:

    We have decided that people who have reported tickets to us in the past should get access to the next version first. Simply because they have contributed to the development by giving us insight into what does not work for them. This sort of information helps us to decide how to proceed and what to fix or add or remove or change...

    Well, we do not control in detail who just adds a new ticket to become a first tester. So feel free to add a ticket now. Nevertheless we would appreciate to get back test reports from those to whom we give early access to the tools, just a few words like "works", "works not" are sufficient.

    oh and important: the testversion is not yet available to everybody and we have no date yet when it becomes available. This depends fully on what sort of bugs we receive from the very first testers.


  15. Zak Kozlov wrote:

    I've already tried Blender Avastar group and Gaia but got no answers. I'm hoping someone can save me here!

    I can not find a ticket from you in our ticket system. Did you try to contact me by IM or notecard?

  16. About the Scale:

    I do not know exactly what is going on in Maya, but i have the impression something is wrong with the "assets" header in the Dae file.  here is a typical assets header:

     <asset>
        <contributor>
          <author>Blender User</author>
          <authoring_tool>Blender 2.78.4 commit date:2016-11-28, ...</authoring_tool>
        </contributor>
        <created>2016-12-18T01:58:11</created>
        <modified>2016-12-18T01:58:11</modified>
        <unit name="meter" meter="1"/>
        <up_axis>Z_UP</up_axis>
      </asset>

    Within the Assets header you find one entry named "unit". This entry has an attribute name and an attribute meter. 

    From the Collada 1.4.1 specifications it says:

     

      • name: The name (xs:NMTOKEN) of the distance
        unit. For example, “meter”, “centimeter”, “inches”,
        or “parsec”.

        This can be the real name of a
        measurement,
        or an imaginary name.

     

      • meter: How many real-world meters in one
        distance unit as a floating-point number.

        For example, 1.0 for the name "meter"; 1000 for the
        name "kilometer"; 0.3048 for the name "foot". For
        more information, see “About Physical Units” in
        Chapter 6: COLLADA Physics Reference.

    So if the numbers exported are meant to be in the centimeter scale, then the meter attribute must be set to 0.01 (one number unit maps to 0.01 meters) If the numbers are meant to be in meter scale the meter attribute must be set to 1.0 (one number unit maps to 1.0 meters)

    I suspect that the Maya exporter either sets the scaling wrong in the asset header or it scales the exported numbers wrong. So what you can do as a test is:

     

    • open the collada file with a text editor
    • find the unit entry
    • - if your imported object is a tiny: replace the meter value by its value devided by 100
    • - if your imported object is a giant: replace the meter value by its value multiplied by 100
    • Import again and see if it works for you

    Also i believe that you can specify the export units in the maya exporter. Maybe you can figure out if changing the export settings creates the correct number values on export.

  17. As far as i know the muscle slider was broken for many years, such that slider values above 50 (half way) had no effect on the female body. I understood that during the Bento project this issue was resolved, so this change seems to not be directly connected to the Bento project itself (but i may be wrong here).

    As a side note: in our own tool we always have supported muscle changes above 50 for female bodies. There even was a remark in the program code stating something like "waiting for LL to fix this annoyance" :) And we never got a complaint about that our tool sliders do not match to what you see in the appearance editor in SL.

  18. When we tested the Sliders back in january, we used a mesh copy of the system character. The goal was to make the sliders behave on the mesh clone as close as possible to the sliders behavior on the original mesh. Here is a video that i made during the testing phase (Please ignore the annotations, they are obsolete. What you see in the video should now also work on the Main grid as well) :

    You see that while the behavior on the mesh clone is not exactly identical, it still is very close to the system character. In principle the sliders should be capable to work on mesh heads in a similar way.

    I know there are issues with mouth and eyes because of some dependencies between the slider system and face animations. But apart from this i am eager to learn what other issues stop creators from getting the sliders to work properly with their mesh heads.

×
×
  • Create New...