I’m developing a new feature called “Width Outline” layer. Well, in fact I don’t have a name for it yet
It will be very similar to the current outline layer but the width will be controlled by a list of width points. Each width point will lie on the bezier line and can be moved along it.
I’ve coded the basics of the new types but before start to code the rendering of the new outline based on the width point list I wanted to code the insertion of new ducks for the width point’s origin and the width point’s width.
Then I realized that the needed modifications will conflict with the modifications made to the bones branch.
The bones branch is not fully completed and its completion needs a lot of work. Probably the “width outline” could get released to the stable branch before the bones branch.
So the question is:
What should I do?
a) Merge the width outline branch with the bones branch and delay it to be released together
b) Merge the width outline branch with the bones branch and incorporate it to a 0.63.00 future version and provide development snapshots meanwhile we develop it
c) Forget the merge conflicts and continue the width outline branch independent of bones branch and release it on a 0.62.03 version.
I have one idea that I want to share, to know what do you think:
Even versions would be called ‘stable’ 0.62.xx, 0.64.xx, etc.
Odd versions would be called ‘unstable’ 0.63.xx, 0.65.xx and would be the result of develop long and complex issues to be incorporated on the stable versions.
Stable versions would receive the bug fixings and the minor (quick) additions and and when the unstable version is mature enough, its changes would be incorporated into next the stable version when released for the first time (i.e. 0.64.00)
Stable versions numbering would be:
0.62.10
0.62.20
0.62.30
etc.
Every time a stable version is released the unstable version should be merged with it in order to receive all the benefits of the stable one. So a typical numbering for the unstable version would be:
0.63.10 (merged with 0.62.10)
0.63.11
0.63.12
0.63.20 (merged with 0.62.20)
0.63.21
Said this, I would vote for solution b)
I know that it means more work for the maintainers (need to release two separated versions each time) but it have some benefits:
Bug testing. The more users have earlier access to the unstable version the more stable will be in the future.
It is clear which features come with the next version, so the road map is clearer for the developers.
Current stable version is not according to this nomenclature but this will change in the next release. Both, stable and unstable will be released at the same time.
I’ve been chating with Zelgadis this morning and we have agreed one thing:
I’ll continue developing widht points V-lines, Woutlines or whatever it is called in a separated branch. Meanwhile I’ll take an eye on the modifications that bones branch has done on the same code area to try (when possible) to avoid conflicts. This would be possible because I have two working directories of the same repository to I can see two branches at the same time without interferences and both up to date by the other.
Then once the new outline is ready I’ll release it for public usage. Probably it would be a minor release or a major one if I can polish the new feature enough.
And regarding to invent a new naming scheme I think it is better to leave it as now: minor releases, minor numbers, major releases major numbers. Release procedure takes so long time and unfortunately we are not plenty of coders
For those who are interested on the new feature here is a summary (it will be useful to me to review the work and the pending one):
Current behavior: Current outlines has the width (the variable width along the line) controlled by the width parameter associated to each blinepoint (origin, width, tangent1 amd tangent2). This is great but when the number of blinepoints grows it is difficult to control the widths in a smooth variation along the line. Also, the outline is always drawn onto all the blinepoints, so if you want to only the outline over some blinepoints of a bline from a existing region (i.e an arc of a circle region) you have to: or set the width of some of them to zero (with the limitations of position of the outline) or create a separated ouline with less blinepoints and link each blinepoint with the corresponding ones from the region manually.
Future behavior: New outline would allow this:
Control points of width are not attached to blinepoints positions. The width control point will be slidable along the bline.
Width points can be dynamically set ‘on’ or ‘off’ allowing to increase/decrease the number of width points in animation mode. This will allow easy handlyng of width points when they must be overlapping on the same place. Also it would allow interesting animation effects.
The width points have a before and after side types that defines how the interpolation from one width point to other is made. Currently there is one interpolation type and three stop types (three width points sides):
*Interpolation: the width is interpolated between this widthpoint and the next one
*Rounded: The outline has a rounded end here and the width is set to zero in terms of interpolation to the next width point
*Squared: same as rounded but squared.
*Peaked: same as rounded bu peaked.
This feature would allow create secitons of outline defines by two or more width points with the proper side types that can slide along the bline and that can be placed in any position of it. It would be a dream for the designer!
-The user could control the type of cusps shape with a new one: rounded. Currently it can be sharp or unsharp.
-The user could control the limit of the sharp cusps by a new parameter.
-BLine tool and Draw tool will create this type of outline alternatively to the old one.
-Width tool should handle this new outline too.
-Draw tool should create much better variable width outlines since the number of points are now independent of the width so you can have now smooth blines with lots of width points or viceversa, depending on how are the widths taken and treated.
I don’t know if I could implement all those features but I think that only implementing the basic ones would be enough to be happy.
I hope this description helps on suggest a name for the new outline layer.
-G
sounds amazing!
why not just replace the current outline layer? since the new outline layer is so powerful, the current one will rarely be used i think.
Because I don’t want to break compatibility with previous files. It would be possible to convert an old one into a new one but that’s a second stage of development.
-G
Hi,
Just a few words to say VERY COOL work Genete! ^^
I think this new “Inking” layer is a very important step to enhance productivity on synfig.
With this, the last missing feature to get THE cutting-edge easy to use vector-drawing-animation-application, is some kind of “boolean operation drawing” tools, to quickly edit drawings
(I know this is not the “Making Synfig easier to use” topic but I think this can be related… and I’m a bit lazy to make another post there )
I hope we’ll get it some day…
I’m looking forward to give a try to this new layer!
Keep up the good work
in the next release the pencil will get the ability of drawing advanced outline, when drawing an advanced outline with the pencil tool, I hope the line width is pressure sensitive
)