New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: brush stabilizer, layers, roadmap? #1

Closed
blurymind opened this Issue Aug 9, 2015 · 23 comments

Comments

Projects
None yet
5 participants
@blurymind

blurymind commented Aug 9, 2015

Hi, frst of all thank you for this amazing contrubution to the open source world of animation and vector graphics.

Would it be possible to share the development roadmap for vpaint? I am very excited as to what is to come to future releases!

As an animator and cleanup artist/inbetweener - I've used toonboom and tvpaint in the past.
Vpaint is a very exciting piece of software for me, because of it's open source nature and the underlying technology which is really revolutionary!

Some of the biggest features that would get me to use vpaint more professionally:

  • Layers that containt different drawings/keyframes, ability to turn on and off onion skinning on a per layer basis, to add and remove layers, hide layers, layer opacity, etc. Here is a crude mockup
    crudemockup-layers
  • Improve onion skinning - color code past frames in red and future frames in blue. Ability to onion skin only keyframes and not inbetweens
    001onionskin
  • A transform tool - ability to rotate a selection! Thats important because a big part of movement is based on rotating joints that cause arcs.
  • Ability to import an image sequence to use for reference/cleanup - this way cleanup artists can import rough animation from other software and clean it up in vpaint and then do inbetweens - take advantage of vpaint's awesome vector drawing and inbetweening
  • for cleanup - a brush stabilizier - for the sketch tool - it will allow easier inking/cleanup.
    lnpmacatchup
@scribblemaniac

This comment has been minimized.

Contributor

scribblemaniac commented Aug 9, 2015

I am also really exited for future releases for the same reasons as you. This project shows a lot of potential. I would love to see a roadmap.

I agree with all of your suggestions, however I think that the layers should be in a separate panel. Having multiple timelines like shown in your picture seems redundant to me since the current, starting, and ending frames will be the same on all of the timelines. I think it would be better if left with only one timeline and had it show dots either for the active layer, or a merged version from all of the layers.

Also to build a little bit upon your improve onion skinning idea, the colors should be configurable for people who have color blindness or even simply a preference for certain colors.

@blurymind

This comment has been minimized.

blurymind commented Aug 9, 2015

I suggest that the developers look into other existing animation software such as toonboom and tvpaint for refference about the animation timeline.
It's best to look into existing succesful designs and take the best parts :)

yes, it will be nice if onion skinning colors are configurable.

@dalboris

This comment has been minimized.

Owner

dalboris commented Aug 10, 2015

Hi Blurymind,

  1. Layers. Yes of course. Actually, if you look at the .vec files generated by VPaint you'll see that the whole thing is contained into a "layer" tag. It is currently useless, but was made to anticipate when I will implement this feature. I also agree with having one "timeline" per layer (Actually, only one timeline, but below it all the layers). Scribblemaniac: the multiple timeline seems kindda redundant in the crude mockup of Blurymind because it is indeed just a crude mockup. In practice, they should be more "glued together", with the common information factorized at the top, and the specific info displayed per line. Being able to see the dots per-layer is critical for complex animation.
  2. Improve onion skinning: yes, I really like the red/green + decreasing opacity. I wanted to have at least the decreasing opacity for VPaint 1.5 but didn't have time. Thank you for the suggestion to have an option to have only onion skinning for the keyframes, I've never thought about this before.
  3. Transform tool: yes yes yes. This will be in 1.6, this is the first thing on my todo list, I am very frustrated that I didn't have time to add that to 1.5.
  4. Import image sequence: yes. And also, import other .vec files, possibly dynamically so you can compose shots by working on different files.
  5. Brush stabilizer: actually, there is this in VPaint already. I just need to improve it and tune it a little, then expose the settings in VPaint so you can set how much stabilization you want yourself.

Roadmap: I will try to share this once I have it. I don't want to be secretive, I'm just a bit busy ;-)

@blurymind

This comment has been minimized.

blurymind commented Aug 10, 2015

you do need a time line for each layer. The preview range is a global value. Have you used flash,toonboom or tvpaint? The dope sheet in blender? Their layers have individual timelines. It's part of the workflow - being able to compare keyframes is very important.

@blurymind

This comment has been minimized.

blurymind commented Aug 10, 2015

ah i just read dalboris' comment.
I am glad it is planned. Yes, you have the right idea indeed. :)

Makes me very excited to get the goods the day you commit them to github. Now that we have a build script at AUR, things will be very interesting for me in the coming months.

Thank you for developing this awesome baby

@blurymind

This comment has been minimized.

blurymind commented Aug 10, 2015

to me onion skinning the inbetweens is useful only when you do the spacing of movement. For posing, it is key to tell the onion skin to show the previous/next (1-5 or 6 at least) keyframes without the tweens

@scribblemaniac

This comment has been minimized.

Contributor

scribblemaniac commented Aug 10, 2015

Yeah, you guys make some good points about the timeline. Now that I think about it a bit more, it makes much more sense, my bad!

@blurymind

This comment has been minimized.

blurymind commented Aug 10, 2015

Another must have feature imo is the ability to HOLD a drawing/keyframe for more than 1 frame!
And also be able to turn on and off all existing tweening globally. That way it would be easier to determine the timing of action, before you set up it's spacing.
I made another crude mockup:
holddrawing-crudemockup
Holding a drawing for more than one frame is very important early on in the workflow, before you do any work on the inbetweening!

Moving keyframes in the timeline, copying and pasting them, inserting frames before and after keyframes. Selecting multiple keyframes,etc.These are all key features that are needed. You probably have them on the roadmap.

Apologies if its already in there, I couldnt find it

@blurymind

This comment has been minimized.

blurymind commented Aug 10, 2015

btw the krita developer working on animation features this year made a timeline design mockup:
http://kritaanimation.blogspot.com/2015/05/hitting-ground-running.html
animation-ui-3

Maybe you would find it interesting :) Not saying its the solution here, just a source of ideas. He obviously ripped off the onion skin editor from tvpaint :D

@dalboris

This comment has been minimized.

Owner

dalboris commented Aug 10, 2015

So many great designs from the Krita folks! I'd definitely use this as inspiration :-)

@sruloart

This comment has been minimized.

sruloart commented Aug 13, 2015

@dalboris maybe not just as an inspiration, think about integration: Krita is missing good vector tools, and Vpaint is apparently already being considered : https://mail.kde.org/pipermail/kimageshop/2015-August/012850.html

I'm looking into it, with the probably far-fetched goal to add vpaint layers as a new vector layertype for Krita

I'm not even talking about the animation branch (you can check the blog here: http://kritaanimation.blogspot.com/), but that can awesome.

Of course, this is just a mere pipe dream, and most likely you want to keep this as a standalone project, but Vpaint can gain a few things from integrating with Krita, like a great user base, windowing, workspaces, exporting options, a bunch of tools to build upon...Am I making a good pitch here? :D

@blurymind

This comment has been minimized.

blurymind commented Aug 13, 2015

You will get some of their experienced developers too. The thing is to
start a conversation with them, so as to plan a partnership where they
contribute to and support vpaint's core vac functionality, while it is a
part of krita. Any bugfixes would then feed back to this repository.

This way for example mypaint developers sepparated it's brush engine from
mypaint , so other developers can contribute to it and integrate it in
their software.

On Thu, Aug 13, 2015 at 5:14 PM, Sruloart notifications@github.com wrote:

@dalboris https://github.com/dalboris maybe not just as an inspiration,
think about integration: Krita is missing good vector tools, and Vpaint is
apparently already being considered :
https://mail.kde.org/pipermail/kimageshop/2015-August/012850.html

I'm looking into it, with the probably far-fetched goal to add vpaint
layers as a new vector layertype for Krita

I'm not even talking about the animation branch (you can check the blog
here: http://kritaanimation.blogspot.com/), but that can awesome.

Of course, this is just a mere pipe dream, and most likely you want to
keep this as a standalone project, but Vpaint can gain a few things from
integrating with Krita, like a great user base, windowing, workspaces,
exporting options, a bunch of tools to build upon...Am I making a good
pitch here? :D


Reply to this email directly or view it on GitHub
#1 (comment).

@blurymind

This comment has been minimized.

blurymind commented Aug 13, 2015

Blender developers did the same for cycles rendering engine and even gave
it a MIT license, so it can be used by proprietary competitors. This led to
partnership and support from other developers.

On Thu, Aug 13, 2015 at 10:08 PM, Todor Imreorov blurymind@gmail.com
wrote:

You will get some of their experienced developers too. The thing is to
start a conversation with them, so as to plan a partnership where they
contribute to and support vpaint's core vac functionality, while it is a
part of krita. Any bugfixes would then feed back to this repository.

This way for example mypaint developers sepparated it's brush engine from
mypaint , so other developers can contribute to it and integrate it in
their software.

On Thu, Aug 13, 2015 at 5:14 PM, Sruloart notifications@github.com
wrote:

@dalboris https://github.com/dalboris maybe not just as an
inspiration, think about integration: Krita is missing good vector tools,
and Vpaint is apparently already being considered :
https://mail.kde.org/pipermail/kimageshop/2015-August/012850.html

I'm looking into it, with the probably far-fetched goal to add vpaint
layers as a new vector layertype for Krita

I'm not even talking about the animation branch (you can check the blog
here: http://kritaanimation.blogspot.com/), but that can awesome.

Of course, this is just a mere pipe dream, and most likely you want to
keep this as a standalone project, but Vpaint can gain a few things from
integrating with Krita, like a great user base, windowing, workspaces,
exporting options, a bunch of tools to build upon...Am I making a good
pitch here? :D


Reply to this email directly or view it on GitHub
#1 (comment).

@scribblemaniac

This comment has been minimized.

Contributor

scribblemaniac commented Aug 13, 2015

and even gave it a MIT license

No they gave it Apache v2 license

I would like to look back to the original intent of this issue and ask @dalboris to please put a roadmap as the top priority. There are many questions that are asking for the same features (transformation, erasers, svg support, etc.) and a list of planned features would help reduce some of this repetition that you will no doubt get tired of very quickly (if you have not already). It will also help potential contributors to decide what is important to work on. Also, I feel this project needs a more definitive expression of what its goals are. You've hinted at commercializing in the future, and now we're discussing integration into other projects. I feel that it is necessary for you to put your views on these and other potential future directions for this project out into the open so that people involved in this project know what to expect.

@blurymind

This comment has been minimized.

blurymind commented Aug 13, 2015

ah right. Sorry I remembered it wrong. Thank you for sharing the link to
the article. Its a great example of moving away from GPL in order to allow
for commercial software developers to get on the train

On Thu, Aug 13, 2015 at 11:05 PM, scribblemaniac notifications@github.com
wrote:

and even gave it a MIT license

No they gave it Apache v2 license
http://code.blender.org/2013/08/cycles-render-engine-released-with-permissive-license/

I would like to look back to the original intent of this issue and ask
@dalboris https://github.com/dalboris to please put a roadmap as the
top priority. There are many questions that are asking for the same
features (transformation, erasers, svg support, etc.) and a list of planned
features would help reduce some of this repetition that you will no doubt
get tired of very quickly (if you have not already). It will also help
potential contributors to decide what is important to work on. Also, I feel
this project needs a more definitive expression of what its goals are.
You've hinted at commercializing in the future, and now we're discussing
integration into other projects. I feel that it is necessary for you to put
your views on these and other potential future directions for this project
out into the open so that people involved in this project know what to
expect.


Reply to this email directly or view it on GitHub
#1 (comment).

@dalboris

This comment has been minimized.

Owner

dalboris commented Aug 17, 2015

@sruloart Yes, integration into other packages, e.g. Krita, would be really nice, I think we should keep that in mind. @scribblemaniac Yes, a roadmap and clarification of what the goals are is definitely the top priority, I'm working on it! I just released the code one week ago, I didn't expect people to be eager to contribute so fast ;-)

@dalboris

This comment has been minimized.

Owner

dalboris commented Aug 30, 2015

Hi all! I have finally written a tentative roadmap :-)

@scribblemaniac

This comment has been minimized.

Contributor

scribblemaniac commented Aug 30, 2015

@dalboris Thank you! 😄

@blurymind

This comment has been minimized.

blurymind commented Aug 30, 2015

exciting! Looking forward to the next release ;)

@dalboris

This comment has been minimized.

Owner

dalboris commented Aug 30, 2015

By the way, blurymind, would you mind creating a separate issue for each features you proposed here? This way, we can close this one, then independently discuss each feature. Thank you!

@blurymind

This comment has been minimized.

blurymind commented Aug 31, 2015

no problem :) I would be happy to do it

@dalboris

This comment has been minimized.

Owner

dalboris commented Aug 31, 2015

Great, thx!

@dalboris dalboris closed this Aug 31, 2015

@Emasoft

This comment has been minimized.

Emasoft commented Sep 8, 2015

I don't see "Export animations as SMIL SVG" on the roadmap. Please add it to your roadmap, it is very important.
SMIL is the THE standard format for animations, used both for the Web as part of SVG:

http://www.w3.org/TR/SMIL/
http://codepen.io/search?q=smil&limit=all&depth=everything&show_forks=false

… and as the official OpenDocument format for animations and graphic effects:

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416228_253892949

Many professional animation packages can import, edit and save directly in SMIL. With SMIL support you can do in minutes things that would require days to do otherwise. It also provides an universal interchange format for animations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment