Ok, here is a new episode of the development of the new approaching:
When a constant value node is turned into animated and the constant value
node is "bline linked" the animated value node what is replacing the slot of
the old one is set to be "bline linked" too. That allows to do the standard
to homogeneous conversion at ValueNode Animated level.
Replace one constant value node with other new animated is not the only way
to sustitute a constant valuenode. There is other one:
You can link (or connect) the constant value node to other existing value
node. In that case when you Connect a new value node to a value node
description (linkable children) it is needed to pass the bline linked status
to the new replacement value node.
In the previous email I mentioned that when a constant real value node is
turned into animated it passes the bline linked stuff to the new animated
one. I've moved that code to the ValueNodeReplace action, since it might
catch any other value node replacement than the animation case.
Also, when you link two valuenodes there is a member at valuenode class
level called to replace the old value node with the new value node
(ValueNode::replace). I've added the code to check if the old value node is
bline linked to transfer it to the new one. This is done if the new one is
not bline linked already because in that case the new one will have
preference.
With those modifications it is possible to:
1) animate a widthpoint position as usual. Then when the cursor time is onto
one waypoint, the modification of the bline won't affect to the widhtpoint
position (as requested) and it is the standard position over the bline. When
the cursor time is between two waypoints the position is the standard
position calculated for a homogeneous interpolation. It means that the
movement along the two waypoints is homogeneous and so, any bline
modification on those times will affect the widhtpoint's position (as the
old homogeneus behavior).
2) link a existing value node (animated or whatever) to a widthpoint's
position. Then it might happen two things:
2.a) If the value node selected to link is not the widthpoint's position and
it is not bline linked then the bline linked information is passed to the
link value node trasfering the bline aspect to all the linked value nodes
(regardless if they are widthpoint's positions or not). It is mandatory to
do that way if we want to keep the behavior of "work with the standard
values but calculate animations in homogeneous world".
2.b) If the value node selected to link is bline linked then the discarded
valuenodes wont' pass its bline link stuff to the selected one and it will
keep its own bline data. That means that when you link two widthpoint's
positions, one of them will loose the bline info in favour of the other.
There are more weird situations with this approaching:
When you have a non bline linked valuenode (animated for example) and you
link it together with two widhpotins positions, who will pass the blineinfo
to the animated one? The link procedure assures that one animated value node
has preference over any other one so the selected one will be the animated.
When the animated is being linked to more than one widthpoint's positions,
it is the first one considered the one who wins (once the first passes the
bline info, the rest are forbidded to override it on the animated one due to
the 2.b) rule.)
All this mess is making me think if we are going in to the right direction.
^___^''
Carlos
http://synfig.org
El 29 de agosto de 2011 08:21, Carlos López González
<[email protected]>escribió:
> Hi!
> maybe you've already seen my commits on the genete_advanced_outline branch.
> I want to explain you what I've done to implement the behavior of standard
> widthpoint position but with homogeneous movement.
>
> 1) I've removed the homogeneous parameter from the layer. For new layers
> the behavior of widthpoints will be always standrard but with homogeneous
> movement. It wont' never be user optional.
> 2) A Value Node is "bline linked" when it has a bline value node reference
> not null stored. That bline reference is stored at ValueNode class (the
> ancestor of all value nodes).
> 3) There are two members to get/set the bline defined at Value Node class.
> 4) The set_bline at ValueNode class is virtual what means that any
> inherited value node can override it. In particular, the LinkableValueNode
> class overrides it with a member class that spread the bline along its
> children only if the children is "bline_linked" by its parameter vocabulary.
> For the moment the only Linkable Value Node sub-parameters that are "bline
> linked" are: Dynamic List Items, Composite_ValueNode::position when type is
> WidthPoint. Notice that all ValueNode_Constant that are children of a "bline
> linked" Linakble Value Node, are set as "bline linked" too by this member
> function.
> 5) The responsible of start the set_bline calling is the class Layer (the
> ancestor of any layer). The parameters of a layer can be regular parameters
> (like radius, amount, etc) or "dynamic parameters" which are all the
> linkable value node parameters and all the regular ones that are animated.
> So, when the layer is called to connect a dynamic parameter it does two
> things:
> 5.1) If the parameter to connect is a bline, then looks its parameter
> vocabulary and try to find any parameter that is "bline_linked". Then it
> calls the set_bline for that parameter.
> 5.2) If the parameter is not a bline then it look to its vocabulary to
> check if the passed parameter is "bline linked" and then look for the bline
> and link it to the passed one.
> This way, the responsible of set the bline is the layer's parameters
> vocabulary.
> 6) There is one new private member for ValueNodes: homogeneous. If true the
> Value Node will act like homogeneous. So a Value Node can be bline linked
> but not homogeneous what assure backward compatibility. It is not possible
> to set the homogeneous variable if it is not calling the set_bline member.
> By default all the value nodes are homogeneous = true.
> 7) And now the magic: When a Value Node is turned into animated then it
> takes the bline reference and the homogeneous boolean and sets it to the
> ValueNode_Animated created.
> 8) When a ValueNode_Animated is "bline linked" and it is homogeneous, it
> happens the following:
> 8.1) All its waypoints (which must be real type what is checked to be like
> that) are transformed to the homogeneous world based on the bline at the
> waypoint time. A copy of the original waypoints is kept.
> 8.2) The calculations of the curves between waypoints is done in the
> homogeneous world. It is done everything a waypoint is changed/inserted and
> everytime the bline is modified. That must be this way because now, the
> aniamted value node is bline dependant and its changes affects the value
> node.
> 8.3) When someone wants a interpolated value between two waypoints the
> value is taken from the homogeneous curves and then untransformed to
> standard world before been returned.
>
> So, I think that it is implemented for animated value nodes at the moment.
> I have to think a little bit more the strategy for the rest of linkable
> value nodes that can be a "bline linked" parameter converted to.
>
> There is one drawback with this behavior. When the bline dissapears the
> "bline linked" value node gets orphan. I've not decided what to do to solve
> this: I can force to export the bline when it is used as linked or I can
> load/save as part of the value node. Same problem happen with current
> 0.63.00 widthpoint list.
>
> Also I need to think what to do with current BLineLinked Value Nodes. I
> don't know if it is a good idea to use the same approaching.
>
> It is interesting to see how the curve of the parameter between the
> waypoints follows a shape "bline dependant" like you predicted ^___^.
>
> Please, when you have time test the current development point to see if
> there is any introduced bug I've not seen. If you have some ideas about my
> last comments, please let me know.
>
> Cheers!
> Carlos
> http://synfig.org
>
>
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
