Difference between revisions of "Talk:Link to BLine"

From Synfig Studio :: Documentation
Jump to: navigation, search
(corrected typo)
m (Linking to Blines moved to Talk:Link to BLine: Discussion)
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
By a [http://dooglus.rincevent.net/synfig/logs/2008/%23synfig-2008-03-03.log discussion] at the IRC channel it has been requested to be possible to:
+
== Circular references problem ==
  
−
1) Attach a vertex of a bline to another bline but without the need of create a new vertex over that bline. That allow simplify the animation of complex compositions due to it needs less vertices.
+
As of http://dooglus.rincevent.net/synfig/logs/2008/%23synfig-2008-03-06.log the circular references problem appeared.
  
−
See Yoyobuae example:
+
In my (Zelgadis) opinion we have 3 problems:
  
−
[[Image:sif_icon.png|16px]][http://members.lycos.co.uk/yoyobuae/bline_attached_2sections.sifz bline attached]
+
# Detecting loops
 +
# Creating loops (handling detected loop while creating)
 +
# Dealing with loops (handling modifications of linked-to-bline vertices engaged inloops)
  
−
In that example there are some vertices converted to Bline vertex and some tangents converted to Bline tangents. Manipulating the exported parameter that represent the position of the vertex along the curve it is possible to easily modify the shape of the composition allowing a better morphing of the shapes created.
+
=== Detecting loops ===
  
−
2) Derived from that request it appears the need to be able to manipulate the ducks that have been converted to a composition. That is: inverse manipulation of valuenodes.
+
00:22 < dooglus> it turns out that every node in the network has a 'time last modified' field, so checking that will allow us to detect loops
−
For the moment there are some convert types that allow inverse manipulation and only for certain parameters. For example tangents allow inverse manipulation (you modify the x/y position and it calculates the r,theta values. It is know that inverse manipulation leads on some inconsistencies. If the the function that convert a type into other is not biunivocal then it can produce undesired results form the point of view of the final user. For example, the Scale convert type would not have any inconsistency due to it has a easy computable reverse function (the reciprocal)
+
  
−
Considering that and taking account that inverse calculation of valuenodes based on ducks position could need some extra computation, it would be good if some convert types can have inverse manipulation.
 
  
−
The proposal is that BLine Vertex converted types allow inverse manipulation. So, manipulating a vertex duck you move the attached vertex along the bline and also match the tangent of the attached vertex to the bline's tangent at that position.
+
=== Creating loops ===
 +
While creating loop we have a Circular references problem.
 +
 
 +
In example http://zelgadis.profusehost.net/files/synfig/circular_references/bline_link_loop_crash.sifz we have 3 blines A,B,C.
 +
 
 +
http://zelgadis.profusehost.net/files/synfig/circular_references/cr01.jpg
 +
 
 +
We want to link C2 to Bline A.
 +
 
 +
But if we do it, C2 will change it's position (it must lay on the Bline A). As result, the shape of Bline C will change and B2 (which linked to Bline C) will move. It will change the shape of Bline B -> A2 will move -> shape of Bline A changed -> C2 not on Bline A. Сontradiction.
 +
 
 +
We could move C2 to place it on Bline A again but then it'll end up not laying on Bline A again.
 +
 
 +
So, if we detected loop, we must do linking in special way.
 +
 
 +
# As the user invokes "Link to Bline" command for C2, we detected loop C2->B2->A2->C2. <br> http://zelgadis.profusehost.net/files/synfig/circular_references/cr02.jpg
 +
# We must solve  system of equations to determine position of C2 when: a) it belongs to Bline A; b) the shape of Bline A determined by position of C2;
 +
## How such system of equations will look like? See [[Linking to Blines - Equations]].
 +
# We placing C2 to determined position. So it definitely on Bline A. Blines A, B, C are updated according to new position of C2.
 +
# We linking C2 to Bline A. Position of C2 not changed while linking, so all blines not recalculated and Bline A keeps its shape and recursion not taking place.
 +
 
 +
'''Another possible solution (ah-hoc):'''
 +
 
 +
# As the user invokes "Link to Bline" command for C2, we detected loop C2->B2->A2->C2. <br> http://zelgadis.profusehost.net/files/synfig/circular_references/cr02.jpg
 +
# We adding a new vertex A3 on Bline A where C2 must be connected. Then we moving (moving, not linking) C2 to the position Bline A where user had clicked. The blines C,B,A will change so C2 probably won't be on A.
 +
# Just link C2 -> A3
 +
 
 +
=== Dealing with loops ===
 +
To be written... if needed to.

Latest revision as of 16:50, 22 October 2008

Circular references problem

As of http://dooglus.rincevent.net/synfig/logs/2008/%23synfig-2008-03-06.log the circular references problem appeared.

In my (Zelgadis) opinion we have 3 problems:

  1. Detecting loops
  2. Creating loops (handling detected loop while creating)
  3. Dealing with loops (handling modifications of linked-to-bline vertices engaged inloops)

Detecting loops

00:22 < dooglus> it turns out that every node in the network has a 'time last modified' field, so checking that will allow us to detect loops


Creating loops

While creating loop we have a Circular references problem.

In example http://zelgadis.profusehost.net/files/synfig/circular_references/bline_link_loop_crash.sifz we have 3 blines A,B,C.

cr01.jpg

We want to link C2 to Bline A.

But if we do it, C2 will change it's position (it must lay on the Bline A). As result, the shape of Bline C will change and B2 (which linked to Bline C) will move. It will change the shape of Bline B -> A2 will move -> shape of Bline A changed -> C2 not on Bline A. Сontradiction.

We could move C2 to place it on Bline A again but then it'll end up not laying on Bline A again.

So, if we detected loop, we must do linking in special way.

  1. As the user invokes "Link to Bline" command for C2, we detected loop C2->B2->A2->C2.
    cr02.jpg
  2. We must solve system of equations to determine position of C2 when: a) it belongs to Bline A; b) the shape of Bline A determined by position of C2;
    1. How such system of equations will look like? See Linking to Blines - Equations.
  3. We placing C2 to determined position. So it definitely on Bline A. Blines A, B, C are updated according to new position of C2.
  4. We linking C2 to Bline A. Position of C2 not changed while linking, so all blines not recalculated and Bline A keeps its shape and recursion not taking place.

Another possible solution (ah-hoc):

  1. As the user invokes "Link to Bline" command for C2, we detected loop C2->B2->A2->C2.
    cr02.jpg
  2. We adding a new vertex A3 on Bline A where C2 must be connected. Then we moving (moving, not linking) C2 to the position Bline A where user had clicked. The blines C,B,A will change so C2 probably won't be on A.
  3. Just link C2 -> A3

Dealing with loops

To be written... if needed to.

Retrieved from "https://wiki.synfig.org/index.php?title=Talk:Link_to_BLine&oldid=8063"