Jump to content

Gael Streeter

Resident
  • Content Count

    84
  • Joined

  • Last visited

Posts posted by Gael Streeter


  1. On 8/28/2019 at 12:07 PM, Gael Streeter said:

    Thank you Vir for the answer.
    So this means an Universal should NOT BE USED FOR SKINS (or other plain textures) or it will overwrite all the worn Tattoos (and Skin) below...

    "for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets."
    This order is very important to know (for creators and customers), I think. Is it possible to have it fully write down in the knowledge base ?

     

    On 8/29/2019 at 11:09 AM, Gael Streeter said:

    Perhaps, a better solution would be to display the Universal between the Skin and the Tattoos. No ? So the Universal could be used both as Skin and Tattoos. Of course in this case the wearing order between the Universals is crucial...

     

    I come back on the subject...
    Indeed, if the Universal would be displayed between the Skin and the Tattoos, it would allow to have HEAD SKINS separated from BODY SKINS.
    For me this is an important feature to have!
    Quite all the skinners today offer the head skins separated from the body skins. Customers can mix them as they want and for example change the skin of their head without changing the skin of their body.
    With the Skin item this is not possible. But it would be possible with the Universal !

    If skinners are reading, what do you think about this current limitation ?


  2. On 8/27/2019 at 11:15 PM, Vir Linden said:

    That is normal. Between the various wearable types, there is a standard order - for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets. The ordering tool lets you change the ordering of wearables of the same type - say, put one universal over another - but does not let you override the ordering of wearables of different types - say, to put universals above jackets or below tattoos. 

    Perhaps, a better solution would be to display the Universal between the Skin and the Tattoos. No ? So the Universal could be used both as Skin and Tattoos. Of course in this case the wearing order between the Universals is crucial...

     


  3. 12 hours ago, Vir Linden said:

    That is normal. Between the various wearable types, there is a standard order - for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets. The ordering tool lets you change the ordering of wearables of the same type - say, put one universal over another - but does not let you override the ordering of wearables of different types - say, to put universals above jackets or below tattoos. 

    Thank you Vir for the answer.
    So this means an Universal should NOT BE USED FOR SKINS (or other plain textures) or it will overwrite all the worn Tattoos (and Skin) below...

    "for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets."
    This order is very important to know (for creators and customers), I think. Is it possible to have it fully write down in the knowledge base ?


  4. I just made some tests with the new Universal, notably on the HEAD TATTOO slot and it seems the UNIVERSAL is always ABOVE the other SKIN or TATTOO clothes without taking into account the wearing order.
    Is it normal ? Why is it so ? Is it a bug ?


  5. 8 hours ago, CoffeeDujour said:

    You will need a updated body that sets the baked flag, then all your legacy linden clothing can be worn and be applied to one layer of that body.

    No, mesh bodies and mesh heads do not need to be updated to allow the Bakes on Mesh on them.

    As Bakes on Mesh is in fact "only" special textures, just an applier applying these textures on your mesh body or mesh head (on the skin layer) will show the Bakes on Mesh on them.

    Once these Bakes on Mesh applied, they display in real time the system skin, clothes, tattoos... you are wearing.

    • Like 1

  6. The results are unfortunately the same with the llScaleByFactor ... :(

    I am wondering if this is not a new display problem of SL because I just also noticed some weird display problems on one of my existing HUD (with tiny buttons) I never saw before : the buttons and the background texture do no appear exactly at the right place when I minimize and then maximize the HUD (buttons are moved and resized by script) :

      image.png.3bf16a6eb89b30a40c0f7831d21f1770.png

    And the display is also refreshed when I change the focus to another window or when I right click my avatar :

    image.png.211140f969bdf4314dd85044af1b0dbb.png

    (I tested on my laptop also and have the same results with this HUD.)

     


  7. Thank you for your answer Rolig.

    I made a loooooot of tests to try to workaround the problem : Change the color, the transparency,  the texture, the hover text, the position, the rotation...
    I also tested with the official SL viewer.
    Unfortunately nothing work! :(
    The refresh is only made when I right click the object or if my avatar moves or if I give the focus to another program!

    If I get the size of the object by script after the resize, it gives me the right size (and not the displayed one).
    I suspect perhaps a rounding error of display...
    I have 3 sizes :
    vector MIN_SIZE = <0.01, 0.01, 0.01>;
    vector RESET_SIZE = <0.04, 0.04, 0.04>;
    vector MAX_SIZE = <0.075,0.075,0.075>;
    If I go from MIN_SIZE to RESET_SIZE the object (a white eye ball) appears smaller than the real size:
    image.png.0eb83691505996fc2cf36a7ab2224177.png
    If I go from MAX_SIZE to RESET_SIZE the object (a white ball) appears bigger than the real size:
    image.png.2ca05c7a2d9e09ebcaf21584bfa77b3f.png
    Real size displayed after right clicked :
    image.png.6a066b9afd67f44ab9bb46ad3e840300.png

    Does someone know more about this ?
     

     


  8. Hi all,

    I repetitively change the size of an attached prim by script using the llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SIZE, mysize]); function and I have a problem of refreshing : the prim is not always displayed at the right current size and I need to right click on the prim to have it refreshed and displayed correctly.

    Do you know this issue yet or is it a new one (I am using Firestorm 5.0.11 (53634).) ?

    Is there a workaround I can use to oblige the viewer to refresh ?

    Thank you in advance

     


  9. Hi Whirly,
    this is not directly related to Bento.
    Even before if the ears of the Mesh heads were attached to the head with no possibilty to hide them you had problems to put other ears...
    With all the different ears available on the market, I think most of the head creators are already aware of that (or they will be rapidly facing all the customers requests).
    For example, we, at GA.EG, offer from the start ears separated from our Mesh Heads and Bento Mesh Heads, in rigged and not rigged versions so our customers can do all what they want...

     


  10. I made some addiotional tests and here are what I noticed : some fitted bones (like NECK or CHEST) seem to be different between Avastar 1.5.9 and Avastar 2.0.23.

    Use Case :
    - I import a custom male shape in both Avastar 1.5.9 and Avastar 2.0.23.- When I edit the bones like NECK or CHEST I notice that there Tail coordinates are not the same between the two skelettons

    

    

    I really do not know if it is normal or not. I just raise here this difference in case it can helps to find if there is a problem...


  11. I do not know if this problem has been raised before but it seems there is an issue with the export of Fitted meshes with Avastar 2.0.23.

    Use case :
    - Export a Fitted mesh (like a fitted mesh body) with an "old non Bento" Avastar and import it in SL : It is ok.
    - Migrate this Fitted mesh in Avastar 2.0.23 (either by updating the rig or by unbinding/bind the mesh on the new aramature), export it and import it in SL : The mesh seems modified !

    You can see the difference on the picture below : In RED the correct and old export, in WHITE the wrong and new export.

    

    Does someone else raised this issue ? Do I do something wrong ?

     

     


  12. As human mesh heads creator, I fully understand the concerns of Mel Vanbeeck who tries to find the best compromise in order to combine both the animations and the sliders.

    Because it is obvious that customers will want both and don't care about the technical constraints behind !

    Of course, animations using translations (and rotations) are much more powerfull and beautiful.
    I think we are all aware of that...

    But translations animations means no sliders...

    So, if we find a way which allows to have nice rotations animations AND sliders for human mesh heads. I am 200% in favor of it !

    But I must admit I stay a bit septic...
    At the end, with all the rig improvements, will we be able to create proper rotations only animations for our mesh heads in prarallel of the use of the sliders ?

    We need to try to answer this question...

    • Like 2

  13. Thank you for your answer Gaia.

    Regarding the Jaw position, that is exactly what I did.
    I have adapted the bone position with the shape sliders in order to have it at the place I want before binding my mesh.
    That is why, I am not sure we can say that the bone is not at the right place as it moves a lot according to the shape used...

    Regarding the Avastar features you described, I think I do not have the same version of Avastar as you because I have none of them.
    I use the last public version : 2.0.10.

    Here is what I have in the Collada and Rigging panels :

    


  14. If the animations to stop use translations, a "background low priority animation" can not solve the problem because this low priority animation will also lock the bones positions (even if it is in the default positions) and that is not what we want here : we want something that release completely the bones used...

    From my point of view, this problem will be extremely annoying for the end users : they will wear mesh parts including Bento translations animations that will lock their bones at a position and the effect will continue, deforming their shape, even after detaching the mesh parts...

    If they use the Reset Skeleton, will this not compromise the operation of the other mesh parts (using Bento translatons too) they may still wear ?

    • Like 1

  15. I do not understand why the mFaceTeethLower is not parented to the mFaceJaw but to the mFaceRoot.

    Is there is a reason for this ? Because in a "normal" skeleton the lower teeth move with the jaw and are not independent...

    This is very problematic because as the mFaceTeethLower has not the same position/rotation/size as the mFaceRoot by default, it can not rotate in absolute correspondence with the mFaceRoot without any translation.

    To sum up : Because the mFaceTeethLower is not parented to the mFaceJaw, it is not possible today to use rotations only to move these two bones together (as a normal jaw do) !

    Request : Could you please parent the mFaceTeethLower to the mFaceJaw in the avatar skeleton ?


  16. Regarding the anatomical wrong location of the jaw pivot point, I am not sure something should/can be changed because in fact this bone moves a lot according to the shape...

    Here is for example the position of the JawFace with the shape I made :

    "

    

     

    Regarding the the joint position issue, where is the "Joint position editor" ? I use Avastar 2.0.10 and do not see these features....

     

×
×
  • Create New...