Konstantin's weekly report #29


#1

Hello, everyone!
My weekly report is a bit delayed again and we have lot of things to talk about.

First of all, we have an awesome new feature from Carlos - Dynamics!

It allows to emulate a dynamic system link of a “linear spring with damper” and a “torsional spring with friction”. It allows to define the mass of the system and moment of inertia. Also an external force and a torque can be applied to the tip of the system.

It’s best to see yourself! Demonstration - http://www.youtube.com/watch?v=dsO6FlhX9mA

The effect is achieved by introducing the new convert type called “Dynamics” and its basic documentation could be found here - https://github.com/synfig/synfig/pull/105.

This feature brings a great potential for making automatic animation of “secondary movements” of hairs, cloth, and… ahem… some other parts of body. :slight_smile:

Meanwhile, Ivan have finished visual representation of the bones. This allows to comfortable select bones right on the workarea, without the need to dig into Layers Panel.
Here’s a video demonstrating the current workflow - http://youtu.be/n1KseNv4uR0
Notice that the bones won’t appear on the final rendering, because Skeleton Layer have “Exclude from Rendering” flag enabled by default.

Ivan still fights for resolving the bug with “Multiple bone link”. If you remember, the problem appears when we try to link one vertex to several boes, giving the incorrect results.

Good news here - we have found a way to overcome this issue within current implementation. Here’s a little proof test, which demonstrates correct multi-bone influence - youtu.be/E-5bJzw4qQQ

At the moment it isn’t possible to assign “influence weight” yet. To make this possible Ivan makes a huge revamp of current system for handling Values and Links. This work is also targetted to make current ValueBase/ValueNode system less hackish and bring the better architecture into it. End users wouldn’t notice a difference after this work, but it will give a good impact on the developer work and from our side this is a necessary investment into future development.

And yeah, as a consequence of this work on fixing the multi-link bug, we now have another new convert type - “Average”, which calculates an average of the given set of values.

But that’s not all news.

Yu Chen have continued his work on polishing user interface. This time, his work is about making a toolbar at the top of the main window. Here’s how it looks at the moment:
[attachment=0]ui1.png[/attachment]
Many people got concerns about the loosing the vertical space, but let me outline that this is still a “work in progress”.

From my side, besides the usual maintaining routines, there is a good news for our web infrastructure - we have migrated our server to SSD hosting, which should give a good impact for website perfomance. The changes touches all website components, except the wiki, which I plan to pay my attention soon.

That’s all my news for today. Let’s rock the new week!


Konstantin's weekly report #30
#2

Well, that’s one way for Synfig to get more attention. :laughing:

Can you explain a bit further? Is it about how list of valuenodes work?

I feel like synfig suffers a lot from lack of proper list processing. I mean, each time we need a value which is composed of several components we need a new ValueBase, a composite ValueNode convert, etc. When we need a list of items, the layer that implements it needs a bunch of code to look into the list, check the type of each item on the list, context menu actions to add/remove/cycle/etc items on the list.

Everything would be simplified if there was a solid concept of a list:

  • A Vector is just a list of two Reals
  • A Color a list of 4 Reals
  • A “polygon” a list of Vectors
  • an Animated Valuenode a list of Waypoints
  • a Waypoint a list of a time, a value and before/after interpolation types
  • a Spline a list of Splinepoints
  • a Splinepoint a list of a vertex, a width, an origin, a split and 2 tangents
  • and so on…

Ideally it should be possible to have a Concatenate valuenode which can take two Splines (two lists) and join them together. Or maybe even one which executes a boolean operation between two Splines and returns the resulting Spline.


#3

Just one mention. Consequence of creation of the Dynamic convert type a new convert type has born: Derivative. It allows to calculate the derivative (first or second order) of a given value node using the finite differences method.
It has the following sub parameters:

Link: Value Node whom is calculated the derivative (Real, Angle, Time, Vector)
Interval: Size of the interval to calculate the finite differences (Real >0).
Accuracy: Accuracy order. (Integer ROUGH, NORMAL, FINE & EXTREME)
Order: First or Second order derivative (integer, FIRST, SECOND)

See:
en.wikipedia.org/wiki/Finite_difference
en.wikipedia.org/wiki/Finite_difference_method
en.wikipedia.org/wiki/Finite_dif … efficients
-G


#4

I don’t see a list here :slight_smile: :unamused:
-G


#5

I’m afraid my capabilities of explaining this in English would not be good here.
You could track the progress by watching the changes in this branch - github.com/blackwarthog/synfig/ … -valuebase
(Ivan didn’t pushed all the changes yet, but there is already something to look at there).

In short: the idea is to change how ValueBase types are handled. We have a lot of checks for ValueBase types everywhere and that makes adding/changing new types a kind of hackish. Also, if we want to introduce some kind of Weight Pair convert type, i.e <Vertex, Weight>, then we have to make explicit convert type, which works for Vertexes only. And there is no way to define common Weight Pair like <AnyType, Weight>. The upcoming reorganization will fix that. Also, the possible continuation of such work opens the possibility to move the loading/saving code right into the ValueBase type, which is more logical. This is not a priority at the moment, it’s just considered as possibility for further improvements.
I hope my explanations are not brought too much mess. ^__^"


#6

It is a list of valuebases. 8)

Granted, a map would be a better abstraction on this case.

EDIT: On second though, what’s needed is a Python valuenode convert. :slight_smile:


#7

Genete, Would you mind share your demo file (sifz, sifg?)

Xiexie.


#8

The file that I used to generate the animation demo won’t work with the latest version because I’ve added more parameters. I’ve manually added the new parameters to the file, so you have to open it with the latest version (commit ID on the file name). If you need the old version you can manually remove the following subparameters: torque, spring_rigid, torsion_rigid and origin_drags_tip.

Notice that the movement of the smiley is different from the original video because I’ve corrected some mistakes on the physics formulas with the latest pull request.

Enjoy!
-G

EDIT: the layer that holds the dynamic convert type is the circle that is disabled. The value node is exported and used when needed but you need to select that layer to edit the parameters. It is not mandatory do it that way, it was just the way I did it.
spring-master-c10f4f.sifz (2.97 KB)


#9

Thanks a lot. Dynamics is really a nice feature!


#10

get the basic idea finally :smiley: