Re: [Synfig-devl] Current master at synfig giithub

[Carlos L. G. <gen...@gm...>]

Hi Yu!


2013/5/22 Yu Chen <jc...@gm...>

> Thanks Carlos,
>
> One question regarding bone system. I am not sure, but if I remember
> correctly, in the forums or somewhere you mentioned that the current
> implementation of bone system is not good enough and would be re-design and
> code from scratch.
>
> I can't find the text anymore, and forgive me if I am wrong :)
>

Possibly I commented that on the chat or forums. I don't remember exactly
either. It is true that there are other approaching for bones system, like
the one that Konstantin outlined on the "Synfig development priorities
meeting" at LGM 2013. In any case, only the part of the development that is
used to convert values to bone influenced types is affected by that change
in the concept of the bones. The idea of Konstantin, if I remember
correctly, was to apply the bones influence via layer, to the bone layer's
context. In any case, the concept of bone, bone hierarchy, parents,
influence matrix (direct and inverse) and everything related to bones and
valuenode bone is still valid. Only the convert to bone influence would be
not used and/or replaced by a layer-context influence system.

Note: The layer-context influence system implies to pass down to the layers
the transformation matrix of the bone(s) and then use it properly on each
layer. Somehow the layer that receives the bone matrix via context, should
know what to do with that matrix, so the parameters of the layer that are
influenced by the matrix has to be defined in some way. The solution for
that proposed on Anime Studio (Moho) is based on two options: 1) influence
by distance to bone and bone strength and 2)  influence by direct bone
binding weighted by the bone strength. They use both options because the
one based on distance to the bone lead to many problems on the compositions
with complex joints (overlapping of bones). The second option is the one
that allows to select the bone that has influence or not over a certain
parameter. When dooglus and I developed the bone system, that second option
covers the first option because the first is just a particularity of the
second (the weights are distance based) and so we developed the most
general case. That development lead us to create the bone influence type.
So the concept of influence of bones by layer-context system or by
valuenode convert type are not incompatible but complementary.

I think that there is not any worry on merge the bones development on
master since it is a  feature that won't hurt the normal user if not
applied and will make happy many people if use it (with difficulties now
because there is not GUI). On the other hand, only merging it to master
would allow us to develop a GUI for it without the risk of keep a old old
branch out of date. The more the bones branch is not incorporated to
master, the difficult to keep it up to date. Take a look to the head of the
bones branch and see how many merges have been there to keep it sync with
master.

>
>
> Cheers!
>
> Yu
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Synfig-devl mailing list
> Syn...@li...
> https://lists.sourceforge.net/lists/listinfo/synfig-devl
>
>


-- 
Carlos
http://synfig.org