Synfig Dev

Development Coding synfig
1

Hi I have a couple of questions/comments about synfig.

1.) Concerning the synfig-core, what is the difference between src/tool and src/synfig?

2.) In the src/modules, what is the *.nsh stuff? I see that it is a script, but for what? NSIS install stuff?

3.) When creating modules, how does Vocab get_param_vocab() work?

4.) Can I write a module in a new directory, recompile and use synfig-studio to directly access it? or do I need to change something in synfig-core? Or one of the many configure.ac?

5.) What is the status of bones? What will it take before they can be merged into the normal trunk?

6.) As far as additions goe, is it a problem if some of them are setup as seporate programs? I was to do this so that they can easily be replaced or upgraded, especially since the GTKMM synfig-studio may not be around the whole time.

7.) If I write a program that makes configuring the keyboard short cuts easier, would anyone care? I figure it would be a good intro to GTKMM programming for me. Before I do more serios work on synfig-studio.

8.) Not sure who do tell this to:
dooglus.rincevent.net/synfig/logs/
synfig.org/Build_Instructions should redirect to something on the forum like: How to Build Synfig Studio in Ubuntu Karmic Koala 9.10
If there are missing links on the site, what is the best way to alert people? (sub-forum, for instance)

[EDIT: server is not letting me send a direct link to the image located at ultagod.com/saveall.png]
9.) I don’t understand why “save all” is text, the only text button. It looks weird to me, but that is my own opinion. It has a tool tip that is therefore redundant. I have made a new button to replace this, located here: ultagod.com Sorry for the main site, the server died of old age and coffee spills. Using other’s hosting for the moment.

10.) What is happening with units, for example rootcavas>carret>File>Options>Units? Its not implemented, but why does Toolbox>File>“Setup…”>“Misc.”>“Unit System” exist? What is going on?

11.) There are some times when synfig hangs. I think I have done a quick fix for at least one of them, where is the master list of bugs?

12.) What is the status of moving away from floating point math? And why would we care to? It was a big deal a few years back, but most of that is now hardware level. Floats beat fixed nowadays - I’ve run the tests. On the other hand, where is acceleration?

Thanks for the help. Synfig is awesome, everyone keep up the great work!

Cheers,
-Josh

2

I’ll do my best to reply or clarify most of them. Anyway some of your questions doesn’t have a straight answer.

src/tool is the source code that produces the command line interface, synfig.
src/synfig is the source code that produces the libraries (layers, renderers, importers, exporters, value nodes, etc.) used by the command line interface (synfig) and by the graphical user interface (synfigstudio)

Yes, the NullSoft installers for Microsoft Windows.

There are two types of modules: layers and importer/exporter modules. In this case you’re referring to the Layer modules because the member you’re referring takes action with the ParamDesc that is a member of a layer.
The get_param_vocab() member belongs to synfig::Layer and to synfigstudio::Action classes which in both cases retrieves the ParamVocab class that is a list of ParamDesc (aka Parameter Description is a class to handle the information of a parameter and handle it). According to Action::get_param_vocab documentation: ** - static ParamVocab get_param_vocab(); ** - Yields the ParamVocab object which describes what ** this action needs before it can perform the act.
See synfig/paramdesc.h synfig/layer.h and synfigstudio/action.h for more info.

Depending on what kind of module you have to do different things. In case you write a new layer you can follow this recipe:
synfig.org/wiki/Dev:Adding_a_Layer

Bones has been stopped for two main reasons: a) The main developer who did all the work has gone from the developing environment of Synfig. Dooglus (aka Chris Moore) is not active lately on development and I, what was involved with him on testing and feature addition, am not full ready now to take the torch to continue the bones work in this moment. And b) The bones system needs a interface for the bones. The interface that was implemented in the past development was a pain to handle and to code. We used the duck Value Nodes interface to represent bones, when instead of that, they must have its own render interface.

The best is to keep the new modules integrated in the Synfig core (the libraries) so they can be used by the tool and by synfigstudio in any time. Anyway you’re free to use the synfig libraries for any other project you can have in mind. If it is interesting we can setup another git repository for that development so it continue being part of the Synfig Project.

It would be a very good addition!!. I wish that if you do that, please tell us the story and we can integrate the changes in the main trunk. :slight_smile:

dooglus logs are a great support and we are so thanked to the guy who stands it. We want to have our own log system so I think that at the moment there is not reason to redirect those links because we have the dooglus link in the support web page.

The real link for the build instructions is this one: synfig.org/wiki/Dev:Build_Instructions the other one is deprecated. The particular build instructions for Ubuntu are just for people that want to build under ubuntu and doesn’t want to be a developer. The official build instructions for developers is the link I wrote before.

The missing links of the wiki must be alerted with the talk page. Anyway, it is a wiki so any registered user can fix it. If there are any broken link on the website please let me know here in the forum.

But you can upload the image to the server. Nice Save all icon, btw.

The proposed save all icons have not been satisfactory for any of us. Maybe your proposal will go to the code :wink:. If you search for a Save all icon in other applications, there are so few that have them implemented. It is just a question of laziness ::oops:.

Yes, the Set up system is a bit cluttered. Any help on that is welcome. The integration of a Setup system like Inkscape or Gimp would be great.

Please use the sourceforge tracker for bugs and patches. It is the master list of patches and bugs.

IIRC we have not moved away from floating point math. I think it was an attempt from the main developer to use half size calculation but it is clear to be slower than the current float calculation.
Can you be more explicit about the “acceleration” question? (i.e. context where you have seen that word)

Thanks to you for the future contributions :smiley:
-G

3

13.) I have been reading the automake documentation, and although it appears to have MANY levels, it seems straightforward. Are there any custom checks that were written?

14.) Apparently KDE3 used automake, and was converted to cmake for KDE4 release. There seems to be conversion tools, although I am unaware of their status. Has anyone here looked into this?

15.)

Ok, great. I will start that after I reinstall linux. Is the shortcut script similar on all GTK+ applications, or is that entirely made up for synfig?

16.)

Thanks!

Looking at synfig-studio in windows, it appears that there are a different set of icons. Is this going to be merged? Or at least have a default and alt set that can be switched back and forth? I have pixel art-ed a win version of the save all button as well now. For comparison of the two: http://www.ultagod.com/

17.)

Ah. Well, from 0 to 100 to represent beta user level implementation, what would you say its at? Even though the bones are not well implemented, it seems like a much needed feature. Would people be against including it in the normal trunk and having a toggle in File>Setup for instance that switches from “Standard” to “Unstable” mode thus enabling bones? During Save, you could just through all the bone data between a comment, and alert the user that Bones requires Unstable mode to run when saving or loading.

cheers,
-Josh

4

Automake does a lot of dependency checking, and it also includes libtool, which is used to link synfig core with studio and to do the synfig-core modules.

I tried running the KDE converters, but unfortunately they didn’t work very well. All of the linkage that occurs (modules to core to studio) isn’t well recognized. Plus, the converter automatically inserts KDE dependencies that don’t apply to synfig.

5

The shortcuts are hardcoded in the app.cpp file from line 1019 to 1109. I don’t know if it is the same for other GTK+ applications but I think they are.

AFAIK windows icons are the same than linux ones. Only the icons that are obtained from the GTK standard icons (Save, New, etc.) can differ from linux to windows because in linux you can change the Gtk theme and not in windows.

Hmmm, not so simple like that. The bones (maths involved) theory is well known and there is not problem with it. I wrote a page with the information on that but needs some conceptual corrections. The problem comes with the implementation. Let’s me explain it briefly:
Bones affects to 2D Vector points (from now on, Point). Points can belong to any kind of layer (not restricted to BLines). When a bone affects to a Point it transform its coordinates from the cartesian global coordinates to the “Bone System coordinates”. Each bone acts like a transformation. Any 2D transformation can be represented by a 4x4 matrix. Lots of bones can affect to a Point at the same time. A bone can affect to lots of Points a the same time. The bone affection to a particular Point is “weighted”. That means that all the bones doesn’t affect the same amount to that Particular Point. From the point of view of the Point there is a tranform matrix that summarizes the affection of all the bones (each one with its own weight). So given a Point it is easy to calculate the transformed Point: P’=MP. The implementation of the last formula was made by a Conver type: A vector parameter (x,y) is converted to a “Bone Influenced Vector Parameter”. The subparameters were: The original vector parameter (the one that originally define the geometry P in the formula) and the needed information to construct the M matrix. Those needed parameter were a list of Bones and its associated weight.
The thing worked fine. You move the bones and the points follow. The problem that stopped development was the inverse manipulation of the points. When you want to fine tunning a movement of a point that is produced by the bone you need to click on a point a move it in the bone coordinate system. This implies to solve the inverse situation: if P’=MP and you want to move P’ to a new place (P’‘) you cannot animate P’ (it is a calculated value) you need to animate the original value P to P2. And then P2=N*P’’ where N=inverse(M). This problem that can be simple from the point of view of maths, was complex (we don’t know how to proceed) form the point fo view of the code, due to the fact of the Value Node conversion for the transormed Point.
Apart of that the setup of a group of bones and the influence on the points was made by hand (no gui for that) what made the solution not usable.
So, from my point of view the bones implementation was 50% done but form the practical point of view it is 0% because it has to be rethinked globally again.

-G

6

Ah. Then, I would have to draw us a couple of “save all” buttons, then write code that would check which theme is loaded while displaying the correct one. I would like the “save all” button to always match the “New”, “save as” and “save” buttons. That’s not really a big deal to me as long as its not over 20 versions. Good pixelart practice.

Also, (do to math humor) I elect to call them Bspines instead of bones. (that or Splines) :laughing: (Splinalcords perhaps?)

Alright. We need to write a UI for it. The synfig-studio UI implementation can be independent of the synfig-core implementation, as long as we write nice names in the synfig-core library. Bones are an important feature in animation, so this is a priority to me. We may have to walk through the code in realtime at some point. But not until I write the shortcut program and make the pretty icon art. Why can’t you just modify the bone weight to match the new position, only relative to rotation? I assume the bones cannot be scaled, therefore upon translation points will be affected directly, while rotation will be based on a new weight assignment. This is assuming there is a weight gradient around a current bone coordinate system point (P’*M), relative to the original location (P’), thus yielding P’’ for that frame.

Its late here, so there’s a good chance that might be completely wrong…

So there are custom written (by hand) m4 checks then? That might make it harder to convert…

Well darn. Thanks for trying though.

Cheers,
Josh

7

Oh, you can change them in Windows too. :slight_smile:

8

Typical assumptions of a non windows user :wink:
-G

9

Hi guys, my last post was two years ago, it’s nice to read that you continue working hard on synfig.

That of implementing bones and rigging is a real challenge, AFAIK. Two years ago me and a couple of friends tried to produce a “quick and dirty” patch to the Synfig code (0.61 then) to implement that feature, hitting hard some obstacles:

  • understanding the core system, since documentation was not very rich
  • following and understanding the call flow between modules and methods, even in debug mode.

Our requirements, back in 2009, (very tight schedule) were to check the feasibility of getting a professional-level 2D animation tool with rigging/animation/physics/rendering capabilities. As said above adding features to Synfig revealed harder than expected. Our patches would be private at first, our intention was to share them, some time after tests, by contributing them to the main branch.

After three weeks of work we realized that extending synfig was taking too much time, so we chose a different approach (our plan B), i.e. develop a separate tool that allowed the user to draw the bones and rig with them and animate the characters, then producing a synfig-compatible export (without bones, only the rigged entities) to be loaded in synfig only for the final phases (rendering to mpeg).

This design tool, later named Skeleton Designer (!), had its own file format, keeping all the information in it, animation, rigging and bones included.
We analyzed and reverse-engineered the animation file produced by Synfig (not difficult, since it’s compressed xml), in order to write the exporter class and everything began to go into its place slowly.

The software was written in C# under MS Visual Studio, primarly due to the faster development cycle, but we used to run it under Linux (with Mono) as well. At the end of this project we showed it in a demo, with two applications, Synfig and Skeleton, apparently built as a suite that shared a common file format (unidirectional).
The prototype, at the moment of the project stop, could do some rigging and very little or no physics, but the animators did it to produce some nice but very short demo footages, that were then rendered to mpeg. Ah, we did translate synfig to italian in the process.

The source code should have stay closed until the first release to the public, which never arrived. I can’t tell reveal more details of this project, but as far as I know nobody has used neither used for production nor published it. In fact the tool never went into production phase, and I wasn’t fully paid for the work. None of the materials were shown to the public, but the source code should rest somewhere in my archives, if someone’s interested on it.

Apart from the anecdotic story, the reasons why I’m telling this story are:

  • it would be nice to get bones to work in to synfig, be it inside the application or outside it
  • the source code for my skeleton designer could be taken as an example and could give useful tips
  • in my opinion Synfig’s source code tends to grow out of control, (maybe I’m exagerating a bit, and it’s just a limit of mine :wink: ), separating or splitting could ease maintenance.
  • sharing this experience with the team could generate new/fresh ideas about how to improve synfig and its development.

Stay tuned, just in case, and Happy New Year of Coding!

10

Hi mesco jazz!

All that things that you tell in the post are very interesting. It will be very useful for animators to have those complementary tools available. I hope that the source code of your experiences were release in some future time.

From my side I can add some experience and knowledge about bones and its implementation because I worked with dooglus with his development and the mathematical implementation of bones concepts.

Relative to Synfig code and its organization, modularization, etc. I agree on that but it is out of my time/knowledge scope to board such complex task. I just modestly add some features and try to fix the bugs I find meanwhile I step by step understand how the code works.

-G