Gael Streeter

June 13, 2016

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 ?

June 13, 2016

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....

June 13, 2016

I made an animation using Bento bones translations and I am very surprised to see that when I stop the animation, the bones stay at the last place given by the animation and do not come back to where they were before the animation was played...

Why is it so ? Did I miss something ? So how do we reset these bones positions ?

I tried the Reset Skeleton feature. It works well. But this resets ALL the bones and not only those I would like.

This can not be used when wearing several objects moving different Bento bones and want to reset only a part.

So how to reset just a part of the skeleton ?

May 20, 2016

Thank you Matrice Laville !
I am happy to see that you took into account my remarks and suggestions.:matte-motes-smile:

I do not think that the sliders should do exactly the same as for the System character by all means. But I think they should rather offer interesting and useful deformation possibilities in agreement with the sliders name and purpose...

Regarding the weights, I use Avastar 2.0.10 for my tests as I know that the sliders settings have been made in accordance with the Avastar weights.

Following your message, I made some additional tests and tries and here are my last remarks and suggestions.

Outer Eye Corner
Indeed, the right solution would have been to add dedicated FaceEyecornerOuter bones as there are for the Inner Eye Corner...
Personally, I do not know what is the best decision without those dedicated bones :
- To leave it as it is ?
- To remove this Outer Eye Corner slider (from Bento) ?
I just raise the problem and let Linden Lab take the decision...

Head Shape
I made some tries and here my suggestion for this slider (I used an unused id number as I do not know how is made the numbering) :

Head Length
Indeed, I did not have had a close look to the tongue and teeth. So I made some additional tests taking care of what is happening in the mouth...
And I noticed that this slider has today a big problem regarding the teeth !
Indeed, when playing with the slider, the upper teeth are going before and behind the lower teeth, which is absolutely unentended.
I think this slider is often used in SL (notably to adapt the head shape for some hair) so it is important that it is well set also for Bento...
I improved my last suggestion regarding this slider and fixed all the remarks you made regarding the teeth and tongue.
Here is it :

</param_skeleton>
</param>

May 18, 2016

During my tests with the last version of the viewer and avastar I still noticed some problems in the behaviour and definition of some sliders.

Here are my remarks and suggestions :

* EYES *

Outer Eye Corner
This slider uses today the mFaceEyebrowOuterRight and mFaceEyebrowOuterLeft which is not correct as these bones should normally be used for outer part of the brows not the eyes !
This induces rig problems for the animations.

* HEAD *

Head Shape
It does nothing today.
This slider can certainly be linked to some head bones for an interesting effect.

Egg Head
The effect on the chin seems much too strong!
This can certainly be improved.

Head Length
The jaw/chin should move with this slider too ! Today it is quite useless because of that.
Here is my suggestion of change :

<param
id="772"
group="1"
name="EyeBone_Head_Elongate"
wearable="shape"
edit_group="shape_eyes"
label_min="Eyes Short Head"
label_max="Eyes Long Head"
value_min="-1"
value_max="1">
<param_skeleton>
<bone
name="mEyeLeft"
scale="0 0 0"
offset=".016 0 0" />

<bone
name="mEyeRight"
scale="0 0 0"
offset=".016 0 0" />

<bone
name="mFaceEyeAltLeft"
scale="0 0 0"
offset=".016 0 0" />

<bone
name="mFaceEyeAltRight"
scale="0 0 0"
offset=".016 0 0" />

<bone
name="mFaceRoot"
scale="0.25 0 0"
offset="0 0 0" />

<bone
name="mFaceNoseCenter"
scale="0 0 0"
offset=".01 0 0" />

<bone
name="mFaceNoseRight"
scale="0 0 0"
offset=".005 0 0" />

<bone
name="mFaceNoseLeft"
scale="0 0 0"
offset=".005 0 0" />

<bone
name="mFaceNoseBase"
scale="0 0 0"
offset=".005 0 0" />

<bone
name="mFaceLipUpperCenter"
scale="0 0 0"
offset="0.012 0 0" />

<bone
name="mFaceLipUpperLeft"
scale="0 0 0"
offset="0.012 0 0" />

<bone
name="mFaceLipUpperRight"
scale="0 0 0"
offset="0.012 0 0" />

<bone
name="mFaceLipCornerRight"
scale="0 0 0"
offset="0.012 0 0" />

<bone
name="mFaceLipCornerLeft"
scale="0 0 0"
offset="0.012 0 0" />

<bone
name="mFaceCheekLowerLeft"
scale="0 0 0"
offset="0.012 0 0" />

<bone
name="mFaceCheekLowerRight"
scale="0 0 0"
offset="-0.012 0 0" />

<bone
name="mFaceTeethUpper"
scale="0 0 0"
offset="0.015 0 0" />

<bone
name="mFaceTeethLower"
scale="0 0 0"
offset="0.015 0 0" />

<bone
name="mFaceLipLowerLeft"
scale="0 0 0"
offset="0.015 0 0" />

<bone
name="mFaceLipLowerRight"
scale="0 0 0"
offset="0.015 0 0" />

<bone
name="mFaceLipLowerCenter"
scale="0 0 0"
offset="0.015 0 0" />

<bone
name="mFaceChin"
scale="0 0 0"
offset="0.01 0 0" />

<bone
name="mFaceJaw"
scale="0 0 0"
offset="0.008 0 0" />

</param_skeleton>
</param>

* CHIN *

Jaw Shape
This slider moves too much the lips and not enough the jaw.
I think this slider should only work on the mFaceChin bone. This has the big advantage to not move the lips at all, only the jaw/chin.
So I would recommend this change :

<param
id="30017"
group="1"
name="Square_Jaw"
value_min="-0.5"
value_max="1">
<param_skeleton>

<bone
name="mFaceChin"
scale="0.0 0.7 0.0"
offset="0.0 0.0 0.0" />

</param_skeleton>
</param>

May 12, 2016

I tend to agree with Kitsune.

Since I clearly mesured the incompatibilities between the animations and the sliders, I look at all aspects of the problem and can not find the right way to use the Bento bones for my Mesh Heads...

As Kitsune said, even the bones weights should be set differently for the sliders purposes and the animations ones.
As example, let's take the FaceEyebrowOuter bones.
Currently these bones are used by the Outer Eye Corner sliders (in the lad file), this means for sliders purposes the outer corner of the eyes should BE RIGGED to the FaceEyebrowOuter bones in a significant way.
But, for animation purposes, it is absolutely wrong !
The brows are an important part for facial animations and emotions communication. And when you move your brows you do not move the outer corner of your eyes !
So for animations purposes the outer corner of the eyes should NOT BE RIGGED to the FaceEyebrowOuter...

I deals with SL customers since 2007. I can say I begin to know how they react and what they want...
What they will want is clear to me : ALL.
They will want customizable mesh heads with sliders to adapt their face to their tastes AND tons of animations for more life, realistic appearance and fun.
That is very human...

What is sure for me now is that if I go for the facial animations, I should completely forget the ability to customize my mesh heads by sliders...
And that, customers will not understand it and will request for customization by sliders again and again.
So what ?
Should I go for the sliders and continue and broaden my animations by mesh parts at the risk of more and more lag ?
Because customers request more and more animations for their heads too and this is today the only solution allowing both : sliders AND animations !

My expectations were very high concerning the Bento project : I expected the ability to make numerous and great facial animations for my mesh heads, avoiding the lag that the "animation by mesh elements" could generate.
Because of the sliders, I am now in a such dilemma that I will certainly be obliged to forget this "dream" in favour of a technical solution I do not like at all but which is the only one which could answer my customers requests...

April 27, 2016

This seems a good solution indeed.

Perhaps this check could be done at the import time instead of the loading time to avoid any "existing content break" ?

One point of concern may be the accuracy of this check... What will be the precision of it ? Will all the tools like Avastar be able to follow these new rules precisely ?

April 19, 2016

I have made more tests with the facial sliders and the animations with the last viewer version (5_0_0_313150) and these tests have unfortunately confirmed what I feared : The facial animations and sliders can not work well together as they are implemented today !

For my tests I took a very basic but fundamental example of animation : a blink animation (an animation closing the eye).

They are today two available ways to design this animation : with rotations or with translations. (It is possible to use also both techniques at the same time but this does not change anything to the problems.)

1. Rotations Animations

For this first test, I design the blink animation with only rotations of the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones. I import it in SL and test it on my Mesh head rigged on the Bento bones.

When I first use the animation with the same shape as the one used to design the animation and to rig the head, with an Eye Opening set to 37, the animations works well : The eye is correctly closed as wanted.

Then, I set the Eye Opening slider to 70. When I play the blink animation again, it works no more well : the eye is no more closed completely but only partially.

Indeed, the Eye Opening slider moved the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones along the Z axis, the rotations of the animation stayed the same and are applied above the moved bones : when the bones are upper and lower the rotations angles are no more sufficient to close the eye.

So it is not possible to design a blink animation with rotations which works correctly with any eyes shape adjustment !
And this is also true for a large variety of other animations using rotations...

2. Translations Animations

For this second test, I design the blink animation with only translations of the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones along the Z axis. I import it in SL and test it on my Mesh head rigged on the Bento bones.

When I first use the animation with the same shape as the one used to design the animation and to rig the head, with an Eye Spacing set to 50, the animations works well : The eye is correctly closed as wanted and at the right place.

Then, I set the Eye Spacing slider to 100. When I play the blink animation again, it works no more well : the eye is correctly closed but is not placed at the right place (it is moved closer to the nose).

Indeed, the Eye Spacing slider moved the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones on the side of the head, the translations animation also moved the same bones and overwrote totally the moves made by the slider : when the animation is played the bones are moved on the side as they are with an Eye Spacing of 50 and no more as they should be with an Eye Spacing of 100.

So it is not possible to design a blink animation with translations which keeps the eyes shape adjustments made !
And this is also true for a large variety of other animations using translations...

All this is terribly frustrating !

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 !

Today, I personnaly do not know how I can use at best the new Bento possibilities : How explain to my customers that they can either change the shape of their mesh head or have nice animations for it but not both ?

And I do not see today how the Bento implementation can be improved technically in order to solve these big issues...

I really hope Linden Lab or the community will find a solution !

April 15, 2016

I identified yesterday the cause of the problem : it was the avatar_lad.xml of the viewer version 5_0_0_313150.
Indeed in the id="772" name="EyeBone_Head_Elongate" section, some bones were missing and some existing ones had weird values.I noticed also some missing bones for the Inner Corner Eye and the Eye Spacing sliders...

I have just installed the new version of the viewer, 5_0_0_313876, and all these problems seem to have been fixed in the new avatar_lad.xml. That is great ! :-)

I will now continue my tests and notably try to also animate my mesh heads...

April 12, 2016

Thank you Gaia for your answer I will make more tries when the new versions will be out.

But is your System Avatar pics taken inside SL ?
Because today, as I can see, the Head Length slider does not react the same way inside Blender than inside SL on mesh heads.
Here is an example of the Bento Avastar Head inside SL and inside Blender with the Head Length slider set to 0 and 100.

In fact, I am already surprised by the fact that the Head Length slider does something with the Bento bones... It is not indicated as "Bento" in Avastar and, until today, it was only working when the Mesh head was rigged on the HEAD "Fitted" bone.

I can no more rig my mesh head on the HEAD bone because of the 4 weights limitation. So I would be happy to achieve the same results with the Bento bones...
But which Bento bones are concerned by the Head Length slider ?
Is there somewhere a file indicating the relations between the Bento bones and the sliders ?
Is it in fact possible to adjust the weigths so this slider works well and the other ones still work too ?

April 12, 2016

I am beginning new tests with the last versions of the viewer and Avastar and I have noticed a very strange and annyoing behaviour of the Head Length slider with Bento riggings.

I have my original FITTED MESH HEAD and the same head now rigged on the Bento head bones (and no more fitted) that I will call here BENTO MESH HEAD.
When playing with the Head Length slider, my FITTED MESH HEAD is changing smoothly but my BENTO MESH HEAD is rapidly deformed : the nose and the upper lip seem to be much more impacted by the slider that the rest of the head.

I tried the same tests with the BENTO AVASTAR HEAD and it is also completely deformed by the Head Length slider.

Why is it so ? Is it a bug ? Could it be fixed ?

March 27, 2016

Thank you very much Gaia for all these information.

Indeed, I thought there would be behaviour differences between animations using rotations and animations using translations.

In this forum, we rapidly sense that it would be impossible to design facial animations compatible with all the different mesh heads (because of the differences in the weights and shapes of them).

But I am now worried about the difficulty to design animations playing nicely with all the different face shapes possible for the same mesh head...

For example, what will happen to a blink animation if you change your eye opening with the sliders ?

I definitely need to do some experiments...

March 26, 2016

Thank you for your precisions Gaia.

Sorry, I did not mentioned it, but my questions were only about the future Bento mesh heads (mesh heads rigged on the Bento bones). I understood that the backward compatibility is ensured for the non Bento contents (past and future).

So, for the new Bento mesh heads, the Bento bones will be used by :
- either the facial shape sliders
- or the facial animations

And that is precisely my concern...
How will interact these two deformations together ?
Will the facial animations override the changes made in the shape with the facial sliders ?
Or will the facial animations be added to the changes made in the shape with the facial sliders ?

I will try to give an example...
I have a Bento mesh head with a close little mouth by default (with the default shape delivered with it).
I find this mouth too small, and I use the shape sliders (Lip Width etc.) to make it wider.
Now I play on it a Smile animation (using the Bento mouth bones) made and delivered by the creator of the Bento mesh head.
How will act this animation ?
Will the smile be exactly like the designer made it for the default shape : a smiling little mouth ?
Or will the smile effects be added to the shape changes : a smiling wide mouth (so perhaps over smiling) ?

March 25, 2016

I am wondering if the appearance sliders attachment may not compromise the facial animations compatibility...

1. Will the bones moves requested by the facial animations applied above the appearance sliders changes ?

2. Will the bones moves requested by the facial animations replace completely the appearance sliders changes ?

Example : In SL I modify my mouth shape with the sliders. What is happening now if I play a Smile or a Open Mouth animation (designed on a "default" shape of the mouth, not my current one) ?

In both cases, I see problems...

In case 1, the animations may be deformed by the shape changes and may look very weird.

In case 2, the animations will loose all the shape specifications.

March 19, 2016

As Mesh Heads creator, i find this really amazing !

Thank You Gaia for this wonderful work. I am awaiting for testing all this !

But I am surprised that there is no news from Linden Lab About the sliders integration on this forum.

Will it be integrated ? What is the project agenda ?

January 30, 2016

Well done Gaia! This control bone seems very beneficial.

I see on your video that you have two cheek bones placed lower (near the mouth) as proposed by Medhue and you previously.
Do you know if this is something that Linden Lab will implement by default or will we have to move them "manually" at this place ?

January 29, 2016

Indeed, the problems with weight limit to 4 bones come when you are dealing with Fitted Meshes as very well explained by Kitsune Shan.

And this exactly my case on my head that I want to be Fitted, so also rigged to the HEAD bone.

As very simple example, let's take the Bento Template of Avastar.
Most of the face vertices are already weighted to 4 bones (as the one selected on the picture).

So now, it becomes very difficult to keep all the smoothness of the rig if you need to add the HEAD bone to the weights...

January 29, 2016

Thank you Vir for your answer and your explanations regarding this request and the reasons for this limitation.

I am really disappointed if this limit can not be raised in parallel to the Bento project.

I think this means I will have to make the choice to not make my heads Fitted as before...

January 22, 2016

Hello,

I made more experiments with the new translations posibilities on my "in progress" mesh head and here is the result in video ;-) :

https://gyazo.com/75182df6d763c8c4043b02a32c0056b8

I tend to agree with Medhue about the mFaceCheekUpperOuter bones. They would be much more useful if placed much lower (as suggested).

As Gaia indicated, the mouth and the eyes are the main focus and the two additional bones proposed for the lips would for sure allow more munances in the mouth animations.

But while experimenting, I rapidly understood that one big difficulty would be the weight limit to 4 bones !
This drastically increases the complexity of the rigging (with some many close bones to deal with)...
So I would suggest to raise or best remove this limit.

January 8, 2016

I can confirm what Medhue said.

This is a very very old known bug :

When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load).
But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long incoherent moves.
A nightmare for animators...

This optimization is fortunately not applied (or without bugs) on the .anim animations... ouffff

January 8, 2016

I am very happy to hear that. It is the solution to really unleash the creativity!

Regarding the 3. Scaling issues, would it be possible to record the bones translations in percentage (in the .anim format) ?
So translations would stay proportionnal and this would solve the scaling issues...

January 5, 2016

I am just starting to make some experiments with the new Bento skeleton and in particular the facial bones as I am a mesh heads creator and an animator.

I was very excited by the possibilities of these new bones This could avoid the meshes hide/show "horrible and expensive" system that mesh heads creators are currently forced to use to give some life to their heads!

But as soon as I started to experiment, I understoodd the big limitations of the "only rotable" bones.

I have a very simple example to understand the problem :

With the mFaceTongueBase and mFaceTongueTip bones, how do you stick the tongue out if you can only rotate these bones but not translate them nor scale them by animation ?

If you can give me the solution to this problem, I would be very grateful!

November 30, 2013

I agree with Qie Niangao and I think that the future Materials features should be implemented into the llSetLinkPrimitiveParamsFast() to keep the consistency of the LSL API.

(BTW, I do not see any big difficulty for the developers here and I really hope that they do know the purpose of what they are developing ! How could it be different ? If not, they have the possibility to ask the Linden Lab people how develop the Advanced Materials in the server and the viewer... LOL)

What is surprising me the most is that it seems that not so many creators are requesting these LSL functions !
Is it because they do not care of the Advanced Materials ?
Is it still too new and they do not see the interest of having these functions ?
I do not know...

To make the things move forward, please vote, vote, vote !
https://jira.secondlife.com/browse/MATBUG-359

November 26, 2013

Hi everybody,

I am very happy to see that more and more viewers are now supporting the new Advanced Materials.
This a really great new feature for creators with many possibilities !
But... but... as there is still no LSL functions to manage the Specular and Normal textures and parameters I do not see how this feature can be really and widely used ! :matte-motes-crying:

Indeed, let's take an example :
You are creator and you have designed a marvelous dress in rigged meshes with different parts and textures (metal, fabric...).
To enable the customer to easily customize the dress, you have also designed a powerfull HUD allowing to change the color/texture of each part (gold, silver... red, blue silk...)
Now that there are the so fantastic new possibilities of the Advanced Materials, you would like to add them to your creation !
But... Arghhhh ! :matte-motes-sour: There is no LSL function to configure the Advanced Materials features !
You even can not change the specular color of the different parts of your dress by HUD to set them in accordance with the diffuse texture chosen by the customer : for example white specularity for silver, yellow one for gold... redish one for red silk, blueish one for blue silk...
As creator, which choice do you have ?
- Put the same white specularity regardless the materials ? The graphic rendering would be far less beautiful and in some case absolutely inadequate ("plastic" effect) !
- Drop down the HUD solution ? Your customers will no more be able to choose and match easily each part of the dress !
- Drop down the Advanced Materials features ? ... No comment...

For my part, I have some creations I do not release... waiting for LSL functions I even do not know whether they will exist one day !
How frustating is it !!! :matte-motes-crying:
How can Advanced Materials be widely adopted and used with such limitations ?

If you agree with me, I really encourage you to vote for the only JIRA I know related to this problem:
https://jira.secondlife.com/browse/MATBUG-359?

Let's make the things move on this subject !!!

July 30, 2013

TY for the info !

So I see that I am not the only one waiting for the LSL functions... but that Linden Lab still not communicate on it... :-(

For HUDs, it is a must have ! I hope they will be released soon.

Forums

Blogs

Knowledge Base

Posts posted by Gael Streeter

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us