Feature proposal - vector eraser that erases strokes up to intersections

Very often when cleaning an ink drawing, the artist will need to clean up line overshoots. A good example of this is hair, but it applies to many places in a drawing.
In vector software, we tend to favor line overshoots, because that way we know for sure that our shapes will be closed off and ready for the bucket tool.
The first time I see this idea applied in an open source project is in  OpenToonz - the 'Remove Vector Overflow' command. This is where this command is supposed to come in and save the day.

It however hardly works. Very often it does noting at all.In fact almost 80% of the time when you select two overshooting individual lines, nothing happens, or it erases parts of the lines you want to keep.

My suggestion here is to add two new modes to the eraser tool - when you are using it on a vector level. These two modes can already be found in other software such as toonboom, clip paint studio and last but not least - inkscape:

A. Erase up to intersection - This can be found in both Toonboom and clip paint studio. What it does is it erases the lines up to the intersection point - where they intersect with another line. Clip paint studio has it as an eraser tool mode and it works excellently.

Toonboom has two strategies to deal with this. One is the one clip paint uses. But as a second strategy - there is an option in the brush tool - to always create a new node where the stroke you drew overlapped another stroke. From there on it is easy to erase all the nodes exactly to that point and you dont need to move nodes around to get them to overlap. Another strategy with the brush tool is to automatically snap the beginning and end of a line to a closeby node of another line or the line itself (toonboom). Inkscape allows you to continue previously drawn lines - but unfortunately works at the end points of lines and is very limited.

B. Object mode eraser- very often the artist would require to erase entire strokes of a drawing - every stroke is a vector object. Right now in OT you have to go to the select tool, select the strokes and hit delete, then go back to the eraser tool to continue working. In inkscape the eraser tool can also erase entire strokes like this:

The implementation in OT almost never works in practice. It works when you draw a simple square, but when you draw a character and start trying it out - the one in clip paint does the job , while vector overflow in open toonz fails

I wonder how clip paint does it. It's the best one I've seen so far. Strokes there dont create nodes at intersections - so they must be somehow figuring out where the intersecting points are:

Here is my theory

--when the stylus starts a stroke in vector eraser mode:
1. Vector erase stroke collects a list of lines (like inkscape does in example B.) that you touched during the stroke.

--On release the following happens:
2. Instead of deleting the entire lines (which is an option also), it splits them all up at intersections points (cache result)
3. Using the result from step 2 , It marks the parts of the lines that your stroke has touched and deletes them
4. The lines that were split up (in step 2) are connected again
5. All the lines in the list of lines from step one are deleted and in their place are created the lines created by this operation.

To the user it looks like lines were deleted up to the intersection - just like it happens in the gif of example A .

Anyways, if i knew c++ i would have tried to figure out a way to make this. Hopefully a more experienced programmer will be interested.

So in order to implement a vector eraser mode that deletes lines up to intersections, you will first need to implement a mode in which it can collect a list of all the lines that it has touched.

You get two awesome vector erase modes in one!

Inkscape developers are much closer at achieving this tool, as they posses the main elements.
The default eraser tool mode already collects a list of lines that the stroke has touched.
The 'Cut Path' command can split a line where another overlapped it, it however deletes the line that overlapped it - which is something we do not want in this case!

Krita Developers - Are actually currently trying to collect funding via kickstarter to improve the vector tools in it. There is no statement made in the campaign that they are planning on adding such a mode to the vector eraser. It is not a stretch goal either. But in any case, I found out that some of them are quite aware of this tool in Clip Paint Studio. Whether we see it in Krita or not - only time will tell. It currently needs an entire rewrite of the vector system, but for that to happen they need your help:

If you haven't seen krita yet, feel free to give it a try. Downloads to the latest version are available at the kickstarter campaign page.

OpenToonz - The development of opentoonz is active as I write this, we will see if in the future they improve this feature. In any case, I filed it here #287 in their bug tracker.

Opentoonz adventures - mini review

When I heard that the software that ghibli uses is going to be open sourced, I became so hyped about it that I went through all the features that it will bring before even getting the open source version.

I kept stalking internet for more information, kept waiting for the day Dwango will release it on github - looking at what time it is in japan and for footage or livestream of the conference.

Opentoonz did get a release and it was a bumpy one.
On the day it came out, everyone thought that the developer is just dumping the code for someone else to maintain.
Compared to the latest version of toonz harlequin, open toonz turned out to be quite unstable, full of bugs and missing features.
The features were apparently removed by ghibli developers who thought that they get in the way of traditional animators.
Naturally all the features missing were the ones that paperless/cut out/2d rig animators cant do their jobs without. :D

I fell in love with the thing, but became disapointed at first in the same time.
I wanted it to get better, so every bug found -I reported at the bug tracker. Almost 30 reports there as I write this are mine:
https://github.com/opentoonz/opentoonz/issues/created_by/blurymind

I had a couple of false ones - which I closed myself. almost all of them - regressions created by alterations made to toonz harlequin.

And in the end - only one minor bug that both harlequin and opentoonz share:


The japanese developer (mainly Shun Iwasawa) has fixed a lot of them and brought back most of the removed ones. He seems to be the most active contributor and has patiently explained the reasoning for the changes in the software here:
https://github.com/opentoonz/opentoonz/issues/108


But there are still a couple of very serious ones.
Namely, it is no longer possible to edit sub x-sheets in place.The curves editor's interface has been made a pain in the ass to use.

The default layouts are broken - toolbar missing, nonsensical room layouts hiding vital editors - if you are a paperless animator. So If you do give OT a try, make sure to download these premade layout files I made:
https://github.com/opentoonz/opentoonz/issues/80
You might still need to add some menus back.

Development hasnt been active for a while now. I hope that devs are taking a vacation and not just abandoning it.  I really like the tool, I think it has a long way to go to be on par with toonboom - but it is already the most advanced open source traditional animation package out there.

It puts both krita and synfig in the dust. Not to mention pencil2d.

I might continue my review of the tools once they get on par with harlequin. My biggest hope is that OT continues to grow and even become something more than harlequin. Right now it is still something less. But things are changing.

Some design proposal I made recently on open source projects

It's been a quiet month for me. You can say that there has been some progress on a personal game project I am working on.

Blender - getting auto focus curves of selected channels and auto-hide unselected channels functionality

Meanwhile the thread I started at blender artist proposing better workflow for animators has grown into something productive.

Severin has implemented one of the features that I proposed. it got a lot of support from another ex-Maya animator Fahr.

https://developer.blender.org/D1128

The feature is to add the "Auto-focus curves of selected channel(s)"  functionality in blender. It works like this:

1. First you enable it from the "view menu" (new entry)

2. Then you get this new behavior. Every time a channel or multiple channels are selected, Blender auto-focuses their curves.

The other ex-maya animator Fahr also requested that we add to the feature another useful behavior from Maya and some other 3d software- The ability to also "auto-hide unselected channel curves".

You see Blender by default makes the user manually hide the channel curves they dont want to see. As a result by default it shows all channel curves and you have to do a lot of manual clicking if you want to only see the channel curves that you are working on. When other channel curves are visible, they get in the way because you can accidentally select another curve or its keyframe while working. It also creates a lot of frustrating visual clutter in the graph editor. In contrast Maya shows only the curves that are of the selected channels.

So what happened was that Severin actually implemented those two features as one. 

You can grab a blender build and try it out for yourself here:

Testbuilds:

• Linux (64 Bit)
• Windows (64 Bit)

I proposed some changes of course:

The patch was however met by a lot of opposition from two die hard blender animators/developers. I suggested that we split this into two auto-view features that are optional. And what ensued was a long conversation that turned the proposed new feature patch into a design task.

https://developer.blender.org/T43933

Two ex Maya, now blender animators (me and Fahr) are trying to convince two Blender developer/animators (Cessen and bassamk) that if the feature is not implemented as a workflow mode, it will loose a lot of it's convenience and usability.
It seems like the argument is mostly on the "hide unselected channels" part of the feature and how that is being triggered.

Their stance on the subject is that:

• It is cluttering the view menu - it is already cluttered enough already!
• It's not their preferred way of working , but they see some merit in it.
• it might confuse some users who enable it by mistake- as it changes the show/hide behavior of the software- merging selection of channels with their visibility toggle switch.

--a proposal was made to make this work by holding a modifier key each time when clicking on the view icon rather than the channel name to trigger the hiding of other channel curves and the focusing on the selected ones.

Our stance is:

• The view menu should be cleaned up anyway with nested menus. This should not be a reason to complicate its design so much.
• We are confused as to why there is so much opposition, since it does not nullify their preferred workflow at all. It is optional.
• We firmly believe that this is not a problem, since it is already done that way in other software and is even a preferred way of work to many animators who are converting to blender. Since it is not going to be the default behavior, the user will need to toggle it on and it's name is self explanatory and clear enough to communicate to the user what is being enabled.
  • Both me and Fahr strongly oppose that proposal to changes in the design since it makes our proffered way of working very inconvenient as compared with how it is done in other software and was originally done in the initial patch.
    • It enforces the need to hold a modifier key each time, which gets even more convoluted when you want to apply the behavior on multiple channels- holding multiple modifier keys to do it.
    • To add to this, the proposal to click on the "view" icon rather than the channel itself also reduces the clicking pixel space.

Trying to salvage what we have, and following on a suggestion from blender artist I proposed that we add both the auto-view behaviors and also have the same functionality triggered by holding a modifier key (as Cessen and Bassamk suggested). If you are an animator using blender and have in the past used Maya, surely you know why this feature is extremely useful and why forcing a modifier key would mean that it is no longer automatic. If so, please take the time and write down what you think at the blender artist thread. We need suggestions as to how to solve this problem.

Sometimes politics is part of it and you have to be careful. For example if you post any links to videos showing how a feature works in another 3d package, that is met with a lot of disapproval on the blender bug tracker. They take it as a literal request to make blender be like the other software. Instead what needs to be the case is explaining why feature X and Y is very useful and why it makes other software a better tool for the job. I tried to do that and it didn't seem to change their minds. 

Solution to the fake user problem with Actions

At least that is something that I managed to get Aligorith to address and change with a lot of help from the blender artist community and some of the other blender developers. So in the end, blender devs do listen to their userbase. Even if we tend to get annoying and melodramatic at the forum some times. :)

X-sheet dock design - an alternative way to manage layers. Layer tagging 

Now moving on, here is another wild proposal I made to both Drawpile and Mypaint developers.

https://github.com/callaa/Drawpile/issues/180

https://github.com/mypaint/mypaint/issues/222

I took the time to create a quick mockup and explanation as to how it could work:

Under the hood x-sheet dock is just managing the same layers that are in the layer's dock. It's just doing it in a radical new way!

key pose drawings can occupy frame ranges. So When you extend a drawing to occupy three frames instead of one, the x-sheet dock technically creates two new copies/clones of that layer above or bellow it (depending on which of the two arrows the user dragged)
when playing from xsheet, mypaint can operate in solo layer view: like the "hide" feature, but hides all other layers except the selected one.
Onion skin mode: hide all layers above the selection and show the ones below it with adjusted opacity

The ability to scribble annotations is very very nice, but not a must have.

Copying and pasting+insert drawings could be done with the right click menu.
Deleting a drawing should move all the drawings bellow it upwards- filling its spot, so as not to have a missing drawing in its place.
moving a drawing in the x-sheet could be done by just dragging it.

Other features needed:

Export to animated GIF
Export individual layers (this already exists in a way: ORA files are actually zip files containing the >layers in PNG format)

In any case, I always find it fun to make proposals to open source projects. More often than not it is very important the way you make it. Having a mockup certainly helps a lot to communicate the ideas. Having other software case examples does as well.