Interesting conversation with darco

[Genete]

This is a conversation I had with darco (synfig creator) the other day. We talked about new bones feature and other very interesting stuff.
Regards.
-G

(00:02:43) Darco: Hello
(00:02:57) Carlos: hi darco, how’s the cold
(00:02:59) Carlos: ?
(00:03:11) Darco: Gone, now
(00:03:47) Carlos: there are some progresses on bones that I want you to watch them
(00:04:14) Darco: ok
(00:04:18) Carlos: mediafire.com/?wmi3i2eejmk
(00:04:30) Carlos: it is a screencast
(00:04:40) Carlos: of a sample manipulation
(00:06:10) Darco: That looks really cool
(00:06:33) Darco: Any support for locking the length of a bone?
(00:06:37) Darco: how well do they animate?
(00:07:48) Carlos: there are four manipulation ducks: position, angle, scale along bone and scale perpendicular to bone
(00:08:02) Carlos: only three are shown in the screencast
(00:08:55) Darco: so, angle is animated independently of scale… The scale and the angle aren’t combined into a vector, then
(00:09:18) Darco: Is this implemented as a value-node? Or as a new layer?
(00:10:12) Carlos: the basis is a class called bone that has a aid class called matrix (affine transformations matrix) all the transformations are performed as matrix multiplications.
(00:10:52) Carlos: then there is a valuenode_bone class, a bone weight pair list class, a valuenode bone influence class, etc, etc
(00:11:08) Carlos: the bones are grouped into a skeleton layer
(00:11:21) Carlos: but its position is independent of its effect
(00:11:34) Darco: So it does require a new layer
(00:12:07) Carlos: yes, for group the bones and its parameters
(00:12:24) Darco: so the new layer doesn’t render anything?
(00:12:29) Carlos: anything
(00:12:37) Carlos: it just move the vertices
(00:12:50) Carlos: the vertices are convert types to bone influenced
(00:13:12) Carlos: the main problem was the tangents but we have solved it recently
(00:13:17) Carlos: es.youtube.com/watch?v=qNOPR_1UAz0
(00:13:18) Darco: Then that layer is just a UI hack then.
(00:13:24) Carlos: yup
(00:14:31) Darco: I would recommend trying to look into a way around using a layer as a UI crutch. It may require adding some new types, or other changes… But conceptually, layers shouldn’t be used in that way.
(00:15:25) Darco: I realize that how to do this without using the layer as a crutch is not strightforward
(00:16:39) Carlos: the bones have ducks the ducks comes from parameters, parameters are in layers … that’s the best way we found
(00:17:40) Darco: Perhaps add some logic to the duck system to notice when a duck value node is being used…?
(00:20:04) Darco: Also… Can you link vertices in bone-blines to other objects, so that when you manipulate the bones other objects move?
(00:20:34) Carlos: yes
(00:21:34) Carlos: at the beginning (when there weren’t ducks for the bones) we did that to “see” the bones in the screen
(00:23:42) Carlos: the vertices are converted to a Bone Influence type, the bone influence is a bone list and a weight of influence per bone and per vertex.
(00:25:25) Darco: ok, makes sense
(00:26:03) Carlos: So we needed a place to see the bones valuenodes and its parameters and its waypoints and so on… the best place was the layer. We though on the child list first but then we loose the possibility of transform the ducks of the bones according to the transformations of the vertices by other layers (ie. rotate, translate, etc)
(00:26:44) Carlos: so the bones are like objects that doesn’t render anything
(00:28:13) Carlos: but they are modified by other layers if the user place them in the proper place
(00:36:12) Darco: Then there should be a way to have the duck system notice when bones are being used in a layer and display the appropriate bones accordingly…
(00:36:56) Carlos: Yeah, dooglus did a complete transform stack for bones ducks
(00:37:47) Carlos: so they are displayed like any other object that has a render part but just show the ducks in the proper place
(00:38:52) Carlos: it helps a lot when use scale, rotate, and translate layers mainly. But all the other that move ducks (spherize, twirl, etc) also move bones ducks (at risk of the user )
(00:40:06) Carlos: you’re certainly right on place the bones in a separate place than the layer list, but as they have parameters and waypoints it makes sense to place in the layer list
(00:41:51) Darco: But the bones should be displayed for layers which use them. If they did that, then they would always be in the right spot in the layer stack. Having another layer to keep track of is superfluous and confusing.
(00:42:45) Darco: imagine if you have three different layers at different positions using the same bone structure
(00:43:16) Darco: well, actually, that doesn’t quite work like that now
(00:43:25) Darco: sorry thinking out-loud
(00:43:33) Carlos: no, please continue
(00:45:13) Darco: The idea of needing to keep track of an invisible “bone” layer when moving layers which use bones in unappealing… and potentially confusing to the user. I think most users would be very confused as to why their bones aren’t matching up anymore after they moved the layer.
(00:45:34) Darco: er, “which use bones IS unappealing”
(00:46:28) Carlos: I know what you mean
(00:46:32) Darco: The duck system should be able to inspect a layer, determine if it uses bones, and display them appropriately for that layer’s position in the layer stack
(00:47:02) Carlos: and when you select a layer you see only the bones that affect that layer?
(00:47:16) Carlos: then the user lost the skeleton meaning
(00:48:03) Darco: You can create new duck types for bones, so that the user can hide or display bones. This follows the existing pattern.
(00:48:36) Carlos: that’s the way it is now. we are using ATL-7 and ALT-8
(00:48:58) Darco: It’s been a while since I’ve thought about this stuff, so I’m a bit rusty
(00:49:34) Carlos: but still having brilliant ideas
(00:50:37) Carlos: the fact that a skeleton can be used by different layers (any one on a different scale and position) is a problem, yes
(00:50:38) Darco: heh, well, while you are thinking my ideas are brilliant, I’ll go ahead and tell you another idea I have had for a while on a completely different subject
(00:51:12) Darco: I now believe that my decision to tie line width to vertices was a mistake
(00:51:27) Carlos: oh
(00:51:36) Darco: You should be able to specify the width of the line at any point
(00:51:40) Darco: vertex or not
(00:51:56) Carlos: that idea is in the feature tracker already
(00:52:32) Darco: What would be needed is a new type, probably a generalization of the gradient class
(00:53:04) Carlos: Interesting idea
(00:53:15) Darco: Basicly a type that is a funciton
(00:53:26) Darco: f(x) = y
(00:53:35) Darco: You specify a width function to the outline layer
(00:53:49) Darco: and it evaluates it across the length of the outline
(00:53:56) Carlos: cool
(00:54:13) Carlos: and the interface?
(00:54:20) Darco: to the user, they would still see the circle width things, but they could move them
(00:54:34) Carlos: great
(00:54:48) Darco: but… heh…
(00:55:10) Darco: I can’t really go implement this right now. I just thought I would mention it.
(00:55:11) Darco:
(00:55:16) Carlos: he he
(00:55:57) Darco: it would allow you to do things like have stroke types, but still have widths
(00:56:07) Darco: imagine a value node that adds noise to the width
(00:56:56) Darco: then you could still do things like have control over the width of the line, but have it look more organic looking
(00:57:30) Darco: meh
(00:57:52) Carlos: I see you back soon
(00:57:59) Darco: heh
(00:58:21) Darco: I need more of myself
(00:58:42) Darco: Feel free to post this conversation on the wiki or whatnot
(00:58:45) Carlos: for your info: the skeleton and the layer affected should be defined in the same coordinate system initially, because there is a “setup” state what is used for the later bone transformation
(00:58:51) Carlos: ok, sure
(00:59:09) Darco: I’m guessing others might find it interesting
(00:59:24) Darco: I figured as much about the initial state
(00:59:34) Carlos: of course
(01:00:00) Darco: I just want to make sure that it is as difficult as possible for a user to move things around into an inconsistent state
(01:01:27) Darco: …and the best way to do that is to ensure consistency at the data-model level.
(01:01:45) Carlos: right
(01:03:50) Carlos: but skeletons are not only a set of bones, bones have relationship (parent-child) and that relationship cannot produce loops
(01:04:38) Carlos: and the user should want to setup the skeleton seeing all the bones involved at the same time.
(01:05:06) Darco: It is a complex problem
(01:05:09) Carlos: it is difficult to separate the setup and the animation status in synfig
(01:05:18) Darco: which is one of the reasons why I avoided it in the first place.
(01:05:26) Carlos: because they use the same interface
(01:05:28) Carlos:
(01:07:15) Carlos: it has been a nice talk. if you want to kill your time seeing the progresses take a look to: repo.or.cz/w/synfig.git
(01:07:39) Carlos: also I’ll post this conversation on the forum or the wiki as you mentioned
(01:11:38) Carlos: btw, having a skeleton layer doesn’t deprecated the idea of that the layer that is influenced by bones show the right bones ducks. They both can live together
(01:12:22) Carlos: a skeleton layer to edit and setup the bones and also that the gui shows the bones ducks when one layer that uses it is selected
(01:13:37) Carlos: that keeps the best of both worlds: simplicity for the user (one single layer to be selected) for the manipulation and for the setup (using the skeleton layer)
(01:14:15) Carlos: thank you for your time. Talk to you other day
(01:14:19) Carlos: Bye

[rore]

So … If I understood correctly, instead of making layers for bones, we could have a kind of specific control duck that is displayed for each object (layer) using bones? (sounds good).

[size=85]And on a side note, I love the idea of having a function to draw the border width, and being able to change the width at any place. [/size]

[Genete]

dooglus implemented already that feature (the ability to select a bline and see the associated bones)…

… I cried when I saw it…

-G

[KonstantinDmitriev]

…So, maybe we could hope to have separate Bones panel instead of layer in the (far-far?) future?