Here is my another weekly report. This time it is slightly delayed, because of the release of Synfig Studio 0.64.1. That’s right, we finally got it released! Read the release notes and download!
Now we can merge the “0.64.1” branch into the “master” and continue development towards 0.65.0! There are also some other things pending to merge into the “master” branch, which I can’t wait to test. The release procedure took much of my time, preventing me from testing the actual development version, so I’m very excited to have this opportunity again.
On November 1st me and Ivan had initial discussion about the priority of this month - the Bones feature. It turned out quite unexpected for me. For example, after 3 hours of brainstorming we come to conclusion that it’s better to stick with existing Skeleton Layer, instead of implementing the Bone Layer. That’s right, I have to admit that my proposal to have Bone Layer was not a good idea. Right now Ivan studies the bones documentation and does some initial tests.
Last week we also finished the English voicing of Synfig training package. Now it’s pending to fit the recorded text to the video and prepare both Russian nad English versions for publication. We’re heading to release the training package this month, so it will be quite a hot time!
One more thing to mention. This weekly report indicates the start of the 4th month of Ivan’s full time work. This month wouldn’t be possible without the support we have recieved through our fundraising campaigns in September and October. Let’s say thank you to all people who supported our campaign and made this happen.
I wouldn’t hesitate to list them all here:
What?
Does it mean that the bone as value node, is going to continue? Or on contrary, the skeleton layer would do its work via context?
Is it possible to have a summary of the conclusions that you have reached after that meeting? That would be awesome to have it for the benefit of the development itself.
Both true - the bone will remain as a value node and skeleton layer will be used to define a context.
Preparing the summary and explaining the conclusions on paper in English will take an amount of time comparable with doing the actual implementation. I hope this is understandable reason to concentrate on doing actual work instead.
Hmm, now I’m curious about what you are planning. Let me try to guess.
There’s one skeleton per each skeleton layer. Each skeleton layer has one root bone (and thus one tree of bones). Errr, now that I think about it having skeletons which span multiple skeleton layer (ie. skeleton layers using other skeleton layer as root) would be helpful for scalability. Each skeleton layer can then be smaller, with fewer bones and fewer influenced vertices, thus smaller lists.
Bones become local rather than global (ie. each tree of bones belong to one skeleton layer only) On second though, scratch that. There’s a use case for same bone tree being used in multiple skeleton layers.
When a vertex is converted to Bone Influence, the code searches upward, looking for the a Skeleton layer and binds the bone influence to that skeleton layer (this is when the “context” part comes into play)
The skeleton layer holds a list of vertexes under it’s influence in addition to a list of bones.
Each bone influence holds a list of Bones (which is linked to the list on the Skeleton layer) and a separate list of weights (which is independent for each vertex). The Bone Weight List goes away
Selecting a vertex from the list on the skeleton layer allows editing the weights of each bone over that vertex (ie. via radius handles).
All bones of a skeleton would affect all bone influences bound to that skeleton. Bones which have no influence over a vertex would simply have weight zero for that vertex
The Bones list in the skeleton layer work pretty much the same as it works now.
IMO, the most problematic issue with current skeleton layer is rigging each individual vertex. For example, rigging a simple hand side-view with two fingers only took me 20 minutes, and 13 minutes were spent converting each vertex to bone influence and adding the correct bones to the Bone Weighted List.
With the above solution that process would be pretty much automated. Manually selecting bones in the Bone Weighted List becomes unnecessary. And adjusting the weights would be much easier to do by using radius handles in the workarea, instead of editing fields on the parameters panel.
One thing I’m missing very much from the current bone feature is binding layers to bones. Tell a layer, like an image, gradient or even a region, to stick to one bone (without being influenced by other bones).
If this is not in your planning already I ask you to please include it, it would be a tremendous help and make cut-out animation in Synfig much easier.
With outlines and regions we could perhaps bind whole layer first and then choose some individual points and bind these to other bones. Could speed up rigging as well.
Doesn’t converting the origin of the layer in question to Bone Influence solve that? The problem is if you want rotation also (there’s no bone influence for angle valuenodes ).
Also it would be nice to have an “enable skeleton” boolean parameter in Skeleton layer. When it is OFF then the skeleton would have no effect, like when on Bone Setup Mode. Except having this parameter would allow selectively turning ON/OFF individual skeletons, and it in animatable manner too. In fact, the Bone Setup Mode could be dropped in that case.
I see this being used to for example have an object be static until a character picks it up. At the moment of the pick up the object becomes influenced by the skeleton of the character. This could be implemented with two skeleton layers sharing the same bone tree, except that the skeleton layer influencing the object starts turned OFF.
Perhaps, I never got that to work. Images just dissapear after linking to bones… But rotation would be necessary for animation. That brings up an old issue again, we need rotation in layers, just as we have translation and scale…
Everyone, thank you for your thoughts and ideas, some of them are good to consider.
… or vice versa? Selecting the bone and linked layer could display the influence for current bone as radius handles for each vertex. Just like the vertex width. So it could be “painted” the same way like with the Width Tool. This is just a quick idea, no promises yet.
This is planned to get solved by allowing to link vertices to bone in the same way as we link vertices to Splines (which was implemented by you, if I remember correctly ^__^)
This is the first task that we are heading to implement right now. So, it’s very likely, that the results will also cover this - Relative animation?...! - #13 by rylleman
Works if the imported image is put inside a group layer, and then the group’s origin is converted to bone influence.
It’s even possible to “cheat” to calculate the rotation angle by using valuenode converts: boneimage.zip (8.89 KB)
The trick is to calculate the needed angle from only vector value nodes. Luckily there is the Vector Angle value node which can extract the angle from a vector. Then it is only matter of generating a vector which gets rotated by bone influence.
I did this by using two Circle layers, converting their origins to Bone Influence, and then Substracting the resulting vectors. The result vector from that has a direction which will rotate according to the Bone Influence. Then it’s just matter of getting the angle of that vector and plug it into the Rotate layer.
Yeah. Each layer should have a “transform” parameter which works similarly to “transform” attribute in SVG.
We only need a way work with 3x3 matrices. Maybe by introducing matrix calculations via valuenodes. Would allow for arbitrary stacking of transformations. And each individual transformation would also be animatable.
Think about the possibilities, we would finally be able to directly rotate Rectangle layers!!!
As far as drawing shapes goes, I fully expect that drawing a transformed shape would be equally fast as drawing an untransformed one. Cairo library can do this efficienly for us.
And even if we needed to transform the shapes on Synfig’s code, it would still be super efficient. Matrix calculations are relatively cheap compared to the cost of rendering (there’s many more pixels than there are vertexes, specially true for 2D only objects).
Yeah, it is true that transform parameter would make no sense (or would be difficult to implement) on the many layer types available on Synfig. But we could at least have the transform parameter on the basic shape layers (ie. Outlines, Regions, Circles, Rectangles).
Also keep in mind this change brings Synfig closer to SVG, which means easier conversion from Inkscape SVG to Synfig SIF.
Right now Ivan studies the bones documentation and does some initial tests.
).
