Bones GUI discussion

Development Feature discussions
#1

Our main developer (dooglus) and me (only by a little) are int he process of implement a bone system in synfig. For the moment there is only the core of the bones structure but we have started to develop the gui. This is the initial post and I’ll add more details to it as we are in the process of grow in the developing.

For initial bones gui concept please read this first:

synfig.org/Bone_Layer
synfig.org/Talk:Bone_Layer

and this initial text describing the proposed bones gui:
repo.or.cz/w/synfig.git?a=blob;f … 1926d15e18

All the code is kept under git: repo.or.cz/w/synfig.git

All comments/suggestion/requests are welcome :smiley:

-G

Animata
#2

Idea. What if every bone will be represented by a single layer?

Consequences:

  • Bones organized in child-parent hierarchy using the Encapsulate command.
  • If user wants particular vertices to be influenced by the bone, he uses Converts.
  • If user wants automatic influence (object sticked to the bone or influenced by it’s region), then he just places object directly under the bone.
  • So Bone layer acts just like any other transformation layer (Translate, Rotate, Scale) - this perfectly fits in the whole synfig conception.
  • Bone layer have parameters and ducks - origin, angle, size, tip, weight.
  • It’s much easier to access and manipulate particular bone - they are in the Layers list, not in drop-down Parameters list. And this is much more intuitive IMHO.
  • EDIT: Possibly exception should be added for behavior of PasteCanvas layer to allow Bones IK

EDIT: Illustration:

Screenshot-bones.jpg
Screenshot-bones.jpg810×616 66.1 KB

#3

Hi Zelgadis,
first of all thanks for take the time on reply.

That’s the first thing I though when I started to consider to have bones on synfig.
This structure is good from the point of view of synfig layer concept but lacks on some of the needed
functionality that the bones should have:

  1. Change a bone in the hierarchy structure means move the layer bone in the layer list. It is more easy to do that in a graphical way by visual interface.
  2. With a layer ordered hierarchy is not possible that one bone has more than one children. How would you create a secondary child bone of a bone that already have one child bone?
  3. How would you solve the problem of have more than one bone affecting a bline layer? What happen if the bline layer needs to be in a higher level than the bone layer? Then you rely on convert type, but if the bline is under the bone, you don’t need the convert type of the bline? so, if at the end the bline needs the convert type, why to restrict to have the bones in a particular hierarchy?
  4. How would you allow parent animation?

The main problem with the layer concept is that layers aren’t linkable valuenodes so they cannot be part of a parameter (unless they are canvases). Look this hierarchy:

synfig.org/api/synfig/classsynfig_1_1Node.html

You can see that layers are directly inherited from the Node class that is the root class of all the synfig classes. If you want a Vertex to be any kind of convert type form a bone (list) then the bone needs to be a Valuenode class inherited from a Linkable Valuenode (where all the convert types needs to come from). That was the main reason to do in that way: a bone as a Valuenode and not as a layer.

In the concept that is currently developed, a bone is a valuenode that is visible in the canvas it belongs to. The skeleton layer is just a help to the user to allow group some bones (some roots or not and some children or not) for a particular reason. But selecting more than one skeleton at the same time the user can manage all the bones of the canvas at the same time.
There is not restriction of Zdepth for bones and they can act at any place where a vertex exits! I think that is much more flexible.

What we are planning to do is to allow the user to automatically bind the selected vertices according to the selected bones (in any layer). It would allow to redo the automatic binding not restricted to the top bones in the hierarchy.

Please don’t consider this a strict “no” and let me know if you need further information on how the current core bone is constructed to allow you to understand why I stand that this way is more flexible and really (due to valuenode problems) is the only possible way.

Cheers and thank you agian
-G

#4

Make sure that the bones can turn Things around and give them a 3D effect.

#5

Good idea! :slight_smile: I hope Genete implements it… :wink:

Cheers! :mrgreen:

-C

#6

What do you mean with “turn Things around”?

G.

#7

I not understood what do you meant by “allowing parent animation” in (4), but most importantly I can’t find a reasonable answer on (3). :slight_smile: So I think your current approach is makes more sense than suggested by me. Thanks for such detailed explanation!

#8

16:34 Zelgadiss: with your aproeaching, parent animation means bone movement in the layer hierarchy, and it could be not practical. :slight_smile:
16:35 but I would like to hear some thoughts about the gui. It is in a preliminary stage and any suggestion is easier to implement now than later.

You’re welcome!
-G

PS: I like that bone icon!

#9

I mean by rotating them.

#10

Hey, Genete! Here’s my thoughts about the concept of handling animated parent. It is related to our yesterday’s discussion.
animated-parent-proposal.pdf.zip (20 KB)

#11

Scratch my previous post and see the synfig.org/files/irclogs/2008/12-18.log @ 07:58

[size=150]Thoughts on behavior of Bone tool - Defining bone parent during construction.[/size]

I suppose what during creation every bone will have context-menu which allows to delete bone, remove item smart, etc. I suggest to add a “Parent” menu item to context menu, which will act like checkbox and will indicate if that bone will be parent to next created bone or not. The “Parent” option in context menu will be available only when Bone tool is active (not for normal tool),

Only one bone could have “Parent” parameter set to “on” at the moment. When new bone created, that bone will have “Parent” option set to “on”, all other bones will have “Parent” set to “off”. When the user right clicks on any bone and setting its “Parent” option to “on”, then the bone, what had that option set to “on” before that, will receive the “off” value. Each next bone is a child of bone which have “Parent” checkbox turned to “on” in context menu. If no bone have “Parent” checkbox turned on, then new bone will be the root bone.

How it works.
When the user creates the first bone, the “Parent” checkbox in its context menu is set to “on”. So it will be parent for next created bone.
a) At this point the user have two choices:
a.1) right click on created bone and set “Parent” to “off”. Then he creates a new bone. That bone have no parent and will be root bone. Because this bone was last created it’s “Parent” option is set to “on”, so it will be parent for next created bone. GOTO b)
a.2) user creates a new bone. It will be the child of previously created bone. After the bone will be created, the first bone will have “Parent” checkbox set to “off” and newly created bone will have “Parent” checkbox set to “on”. So it will be parent for next created bone.
b) At this point the user have three choices:
b.1) right click on just created bone and set “Parent” to “off”. Create bone. This newly created bone will be the root bone. GOTO c)
b.2) right click on any other bone and select the “Parent” checkbox to on for it. Create bone. This newly created bone will be the child on which user clicked and turned “Parent” to “on”,
b.3) Create bone. This newly created bone will be the child of previously created bone.
c) …and so on…

#12

I see it much more simple:

If you look to the bline tool, you can select (high light) a duck of a vertex or a tangent during the construction of the bline. I think it can do the same exactly.

When the user select the Bone Tool there are two options:

  1. The user has a Skeleton layer selected.
  2. The user hasn’t a Skeleton layer selected.

If 1) then the bones added during the usage of the tool are added to the Skeleton layer.
If 2) then the bones are to a new Skeleton layer.

In any of both cases:

If the user has a bone selected (the user has the origin of the bone selected) then that bone will be the parent of the next bone created.
Only one bone can be selected during the usage of the Bone Tool so only one bone can be the candidate bone. Even if more than one bone is selected, then the first one in the selection is used.
When the user adds a bone it becomes selected and its parent is unselected.
If the user want to do a different bone chain just need to select other candidate parent bone.
If the user wants a root bone just select no bone.

I think it is simpler and more intuitive.

I would like to hear your opinion.
Sorry for the late response.
Thanks for your feedback.
-G

#13

hi, I was wondering if Bones will be in the latest release of Synfig - 0.61.10?

#14

No. Not included. And it will be 0.62.0 :wink:
-G

#15

oh well. but yay at the same time!

#16

well, seems like it didn’t make it to 0.62.0 … any idea on when it will be added?
cheers, OHo.

#17

No idea. Nobody is working on the code at the moment.
-G

#18

apart from this post coincident :
viewtopic.php?f=14&t=1258
I would say that if the possibility of distorting not only in enlarging in 'stretch but maybe it can simulate a 'prospective approach! the important thing and that affects only some vertices of the silhouette image and object features and internal, perhaps … maybe turn onto filling stretch and somehow extend these bones affecting the rest

#19

When will the relay with the bones?

#20

The bones project is stopped at the moment. Current developers (2) are focusing on other things that needs to be done first.
-G