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.

Winning Game Jam plovdiv

This year we participated in the first global game jam event in my home town- Plovdiv.
"Team Chameleon" was formed out of 5 people: 2 programmers, one graphics guy (me) ,a musician, and a level designer.

You can play the game HERE in your browser.

And THIS is it's entry page- on the global game jam website.
Howto play the Demo:
Please note that the game doesnt have a loading screen yet, so you will need to wait a bit for the graphics to load from the web. 
The astronaut can see in one of the 4 different color spectrums. Hit spacebar to switch between them and make their platforms visible. Also note that seeing in a color spectrum also makes you SEEN by the monsters that exist in that spectrum. The goal is to get to the bunker! :) 

The game won us the industry game jam award- given to us by gameloft!

------------------------

Organisation

During the first day of the event, when the topic was revealed:

"We don't see what we see, we see what we are" (or something like that)

All I did was wonder around and try to get to know people in the room - find out what their take on the theme was and also to see if I can find some programmers. 

The initial idea of the game is that we, as human beings have a limited perceiving of the world - for our eyes can not see the complete spectrum of light. This idea came to be after a chat with a color blind guy, whom I met at the event (what are the odds).

After finding 2 excellent programmers, or more like them finding me- we got together at the table and had to come up with a game pitch in less than 30 minutes!

For this part the best thing for me to do was to allow for everyone to shoot ideas and on my part-write them all down on a piece of paper and compile the pitch. 

Some of the ideas were:

- Colored vs black and white

- Perceiving things in a wrong way (in different colors)

- Seeing only things in certain colors.

- Forcing the player to memorize where platforms are

- Point and click items in a room in a sequence - in order to proceed to the next room (puzzle)

- Platforming (voted on this - it's a popular genre that people understand)

- At the end of the brainstorming session I enforced on the team the need for antagonism. Memorizing platforms is not enough to keep the players on their toes. Thus enemies need to be hidden in every color spectrum.  

After the pitch was done, I got everyone on the team sit down together and flesh out the idea.  We were 4 people in the room -  having us all vote wouldn't have worked, so my involvement in this part was not to vote on ideas. Instead I sat outside the idea pool and acted as a mediator. I outlined our production plan on the white board -going through everything we need, see if everyone is on the same page and if not- let voting do the work. People brought up valid issues in the design and they voted on the best solutions - fleshing out the design. Would invincible platforms still act as platforms or not? Would invincible enemies continue to chase you while you don't see them? Is the outlined plan realistic for the 48 hours? What are our priorities- which features can be labeled as "extras"? What do the programmers need from me- the artist and from the rest of the team. What resolution would the game run in. How big is the sprite. And so on.

While one of the event organizers told me that we are wasting time with this planning, I still believe that one hour wasted on planning saved us from several hours wasted in arguing and headaches. I have been through this with other teams in the past and I knew what a recipe for little disasters looks like. It's when problems are brought up really late during production!

---------------------------------------

Workflow

First of all, game jam is an event in which a team has to make a game in 48 hours. Since I was the only graphics person in the entire team, I had to choose my battles wisely.

It started with an animation pencil test (done in pencil2d) - so i can give something to the programmers early on- for them to test with and also for me to get an idea about sprite size. This would later determine the line thickness of the final sprite and also the detail design.

Next on I looked for inspiration from "The forbidden Planet" and other b-movie posters from the silver screen era of awesomely cheesy 3d movies.

And thus drew the initial background- as tall as the game resolution and as wide as I my heart desired (then cropped it).   

Using Artrage- for it's natural media tools. Those helped me get closer to the poster vibe. Back in those days artists had no computers. I even faked some scratches on the paper and extra paper grain.

Having a BG tile lets me establish the overall color palette of the game - something that is a reference point when choosing colors for the player,platforms and enemy sprites - those need to stand out.

For the final sprite animations I used Toonboom studio. This allowed me to tweak colors and crispy line thickness. Finally- exporting to any size that my heart desires (or more like the programmers desire)- one of the greatest advantages of vectors.

Both the enemy and the player sprites are animated inside the same file- to save time and to have an easy way to compare them. The enemy design and coloring is inspired by a stylistic effect some pulp posters use - depicting it as a dark shadow with a detail defining neon rim light(s).

I managed to plan enough time for doing some 3 tone cell shading on the player sprite. The programmer required me to export both the player sprite and the enemy sprite in 4 different color mode versions. 

I know I could have done this as a cut out animation rather than inking all the frames. I chose to do it the proper way because setting up a cut out rig alone would have wasted that time anyway- the sprite animations are short so it wasn't worth it compromising their quality. If they were longer or the programmers needed it cut out for some procedural things- like armor swapping- then I would have had used "Spriter" instead of toonboom studio.

All this and much more was done in less than 48 hours!!!
Even managed to speedpaint a picture for the title screen during the last thirty minutes.

The title picture reuses the Planet graphic. There is the obvious mistake of having a different number of fingers. That index finger sure is crazy. But this is what generally happens after some sleep deprivation. :)

What didn't make the cut:

Our level designer kept insisting on having different backgrounds (suns) for each color mode. I resisted  because it complicates the core "hook" of perceiving colors and it is also creating more work for me.

He also insisted on having cut scene drawings to tell a comedic narrative. While this was welcome by me since his ideas on those are really entertaining- I decided not to do it because things with more priority were not finished. 

If we had more time I would have had the programmers change the font at the title screen, fixed the issues with my own half baked graphics, had insisted that platforms in the game are jump through type rather than solid, had insisted to place a different background for each level and a different music too (the musician made more than one tracks for the level) and many other things.

But this game is finished now and it's time to move on to better things. :)

Toast! storyboard ver1

Today I got some valuable feedback for the storyboard from my animation tutor at uni, who also has a blog here . He liked my storyboard. I am really glad that there is someone like him to show it to, because he's a guy with experience and his feedback is valuable..

Here is what I got this far:
First of all, the rules of my assignment do not allow me to make the animation longer than 30 seconds. But I have too many shots put in that small time window.And the duration of some of the shots is too short. So 10 seconds must go. For that I must cut out some of the first shots. Some other scenes need a slight change in the camera and the composition (more space between and around characters).


after thinking about it, I decided to make a short version of my animation (for the module assignment) and later a longer one which will be as much as at least 2 minutes!

Before editing my storyboard , I would like to post it in the name of good documentation and progress evaluation. So here it is, no revisions- purely as it came out of my mind:

Toast! storyboard ver1 01.02.2010



I used software called Toonboom storyboard to do it. You can download a trial version, but you should export your work as a video/pdf before you close the app, because if it has over 30 panels, you are not going to be able to open it again.

It's a really awesome application for storyboards- simple and powerful. This storyboard took about 2 hours to make with it.