Hi
I’m working on a new layer type: Enhanced Outline Layer.
It has movable width points that override the width of the blinepoints.
See a WIP here:
youtube.com/watch?v=mQbqh_A2P9Y
-G
Very interesting!
I wish I had this in my last project where I animated child drawings being drawn.
Hi Genete,
I know it’s a bit belated, but what is it (feature, functionality) that you added that wasn’t in Synfig before?
G.
The current Outline layer has its width defined by three parameters:
- global width of the outline (w)
- expand parameter (e)
- the width of each blinepoint. (wi)
the resulting width of the bline in a certain point is calculated based on the averaged width between two blinepoints (wi) multiplied (scaled) by the global width (w) and shifted (added) by the expand parameter (e).
With this scheme you need a blinepoint to produce a change of width in the curve. Sometimes you don’t want to have a blinepoint in that position (blinepoints should take care of geometry only) because it is difficult to maintain aligned with its neighbours. In other cases you have a complex curve and just want it to have a smooth width variation from the first to the last blinepoint (the video example). It is difficult to adjust the blinepoint’s widths to produce a smooth linear continuous width variation…
So the idea is detach the width parameter from the blinepoint. The user will start with a pair of “wlinepoints” that define the width of the whole curve regardless of how many blinepoints it has. Those wlinepoints are defined by a position in the curve (from 0 - start to 1-end) and by a width at that position.
I’ve managed to store the wlinepoints in a dynamic list, so they can be set on/off by the time.
The old Outline and the blinepoints that holds a width should still existing for old files compatibility, although a conversion to new type can be done.
The current code in git render more or less properly the enhanced outline but has some cases not checked, like when two wlinepoints are in the same position. Also the render is not correct because of the use of the curve length for the case of “homogeneous” parameter (the widths renders are shifted a bit). I still working on it. For sure it wouldn’t go with the new release.
It has pending:
0) Improve the render result and fix any bug that still pending.
- Add ducks for control the wlinepoints. I plan to steal code from the link to bline code for vertices.
- Modify the Bline tool to allow create enhanced outlines.
- Same with the Draw tool.
- Use the same code for the Plant layer and Curved Gradient… err there is other layer that uses width?
- An optional converter from the Outline layer to Enhanced Outline layer at the open file time.
Maybe the Enhanced name is so pretentious… but it was the first suitable name I found. 
-G
Is this new line width tool meant to be a replacement or a compliment for the current way line width is working?
I think it’s just in some circumstances you would like to have this ability, in most other scenarios it would just add extra tangents that you need to manipulate.
I think that the current Outline layer should still working as it is working now. The Enhanced Outline is going to be a new layer with the same abilities than the Outline (from the point of view of tangents and curve control vertices) plus that the width doesn’t depend on the blinepoints widths but in other movable wlinepoints.
Err… I didn’t mention anything on a Width Tool but it might be used on the Enhanced Outline too. It is far from the reality now, because a lot of things needs to be done first. 
Alright, sound like it’s going to be a useful layer type then!
This feature would be great to have, but I have a slight issue with numbering from 0 (start) to 1 (end). Right now, it is used with the “link to bline” feature.
When I link a point in BLine A with BLine B, and them add another point into B, the position of the link point moves. This isn’t because the BLine length changes, I have tried it with a horizontal line and 0-length tangents. The numbering 0-1 apparently depends on the number of points. Problems could also arise when ActivePoint status changes during animation.
nikitakit,
yes it is a known issue when the Link to Bline feature was designed.
The problem is that the length of the bline is not constant for the same number of points. It depends on the tangents and then it has to be recalculated (the length) on each frame to keep the position of the link to bline value fixed in term of length counting from the start of the bline.
It was a decision taken at that time because (although it has much more calculations) it can be done at real time (calculate the position based on the length from the origin).
For wlinepoints can be the same issue. Current width of blines have two states: Homogeneus or not homogeneus. Those stated are selectable by the user.
The homogoenous situation is giving me lots of headaches to place the wlinepoints in the correct place because the width is calculated based on the lenght of the curve between two blinepoints. So keep the homogeneous option is computer consuming (and coding too ). On the other hand if I place the wlinepoints based on its relative length from the begining of the wlinepoint I would have problems to calculate the “non homogeneous version”. Also I plan to reuse part of the code of the Link to bline to place the ducks of the wlinepoints.
On the other hand if the problem you have with the insertion of a point were solved and the link to bline always link to a relative fixed length then other person can think that it is a bug because when he modifies the tangents far away on the bline, the link to bline position moves…
Which solution to use? I don’t know.
Current solution is the number of points.
Maybe it can be just optional or selectable by the user (the meaning of the amount parameter) but it needs someone that codes it 
-G