![]() Registered Member ![]()
|
This was done in part as a idea for some of the issues mentioned by TheraHedwig for comics.
However, it more generally applies to animation as well. Keep in mind though that I have no idea how 2D animations work. :S I used Flash over 10 years ago during a summer camp, and that was about it. I remember that you could double click on an image and adjust the element from there, but it didn't work recursively (i.e. there was only one "level"). Elements in Krita will potentially allow you to embed as many levels as you want, creating complex animations from simple components. There should be a system to check for loop abuse though. The general idea behind elements is the ability to easily define any image (in whole or in part), animation or text as an "Element", and be able to re-use them in another file. Basically, it should be: - Easy to define and save elements - Easy to manage them (as there will potentially be a lot of them) - Easy to insert them into a document - Basic operations such as resizing, rotating etc. should also be available after inserting, by controlling the "frame" rather than the content itself. (I'm not sure how control for text would work though, maybe separate the text content from the text style?) - All changes to the source update the target, live! (think layer clones across documents, except more general. Live updates!) So anyway, a few very, very rough mock-ups: ![]() As you can see, it'd integrate well with the Flipbook: just open the layout document and the frames at the same time. Although printed comic books fit nicely in a rectangular area, online comics can either have long vertical formats or long horizontal formats, and the scrolling gets annoying, not to mention looking for the right layer among all those layer groups. Currently, when I draw comics, I draw the frames individually then import them into Inkscape, but with such a setup, I think I could do all of it from Krita. ![]() To define an element, you could either define the whole image as an element, or draw a frame and save it as an element. Now, the frame would mostly be static, so to further control visible areas, you can use masks or alpha-inheritance at the layout level. ![]() Integration with Calligra Words! This is for those who want to keep the script and layout separate. Just select a folder, highlight a piece of text, and name/tag it. No need for page by by page saving, just save all the script to your chapter in the same file. Heck, save the script to the whole book in the same file, if you feel like it. In the layout page, you can insert the text and adjust style. When you modify the text from Calligra Words, they will automatically be updated in the layout page as well (not sure if the reverse should work. It doesn't work for images, but maybe it could work for text) (not sure how text effects would be handled) ![]() There could be a pop-up for management, where you can arrange the elements however you need. Note that managing elements is separate from managing files, so you can duplicate or place elements wherever you need. Not sure what happens when you move the source file, though. ![]() Lastly, animations! I'm not sure how animation in Krita currently works, I haven't tried the plugin yet. But anyway, this won't make Krita replace all the other animation tools out there, but it should make it much easier for people to do basic 2D animations. |
![]() KDE Developer ![]()
|
Flash did have this for a long time, but chances areyou weren't introduced to it. Look up tutorials on the symbols library to see the idea. The usage of these is also possible in the svg format with symbol and view. Inkscape is supporting these in 0.49.
overal, I guess, a good idea. Each frame of a comic is already a picture on it's own, to extend it this way would definitely clean up the layer dialogue. (I don't think it's going to save people from layer-abuse though, that's a disease that can only be cured by themselves ![]() And of course most animation program have this technique for a reason ![]() |
![]() Registered Member ![]()
|
Interesting proposal, though I don't think it's adequate for krita:
The "elements" concept works good for vector based softawre like flash, but for bitmap based is not suitable (there's a reason why it's not available in TVPaint, which is more comparable to Krita as really made for drawing/painting, not tracing vectors...) , because if you work on each frame at arbitrary size, and resize them on the final page, you'll have random resolution results on each frames, making the page render totally inconsistent= that's not a good way to work. So it could somehow work just for importing sketch (only stage where such resolution insonsistency wouldn't matter much), but then it gets limited usefulness compared to the amount of work to make it. |
![]() Registered Member ![]()
|
^ I think it depends on how you set things up, though.
If you get the frame proportions in advance, then you can set things up so your individual frames are exactly the sizes to be displayed in the layout frames, or a multiple of the final size (like, 2x). Then, with proportional resizing, you can keep consistent image quality. Also, Krita has quite good transformations now. Depending on the style, some resizing here and there could be quite acceptable. You are probably thinking more about printed comics, but many people are drawing online comics nowadays, where such things are less noticeable. I've drawn a few digital comics, and heck, I resize the individual frames in Inkscape. :\ Pros would set things up in a careful manner. Hobbyists would be able to do whatever they want. |
![]() KDE Developer ![]()
|
I agree. Perhaps though, we should consider putting feedback for this in the UI? Like, if a use-frame has a pixelbased larger size than the source element, there's a little yellow watch-out triangle... in the transformation/info screen? With a little tooltip to explain the situation?
|
![]() Registered Member ![]()
|
Sure with frame size already defined for each frame it can work, and can be very cool tool. But then I see it more as a composition/layout tool than a re-usable/adaptable-elements tool.
Yes I was first thinking about printed comics where highest original resolution is best, sure with digital comics one will probably reduce resolution at export to fit screens resolution, and so it'll all have the same low resolution at export. Just outlines width may still look disproportionate depending on transformations. |
![]() KDE Developer ![]()
|
Well, yeah, within comics the only real use is as a layout tool, but there it can still be valuable, reducing the amount of clutter happening on a typical comic page.
within animation, where you have a lot of different elements to deal with, it might be useful to handle each element seperately as well. especially in the case of a walk-cycle, where the person needs to animate through frames, while smoothly translating. Anither use-case would be spritesheets, for similar reasons as animation, but also because sprite-sheets are really rigidly constructed so that the computer may read them properly. actually, this would be pretty great for spritesheets, because this facilitates game-mockups too, allowing an artist to preview their work. (this can be done right now with tiled, but I know of at the least one project where tiled just comes too short for previewing(the project had irregular tilesizes) |
![]() Registered Member ![]()
|
Hm, so the verdict so far:
- Because of consistency issues, it may be better to not have a resizing feature - Without resizing, this feature can be useful, when set up properly, to clean up the clutter in the workflow for comics, allowing the artist to concentrate on the composition/layout - Again, features such as resizing would cause issues within animation. This setup is instead best suited to simple sprite-based animations. It should also be useful in producing simple pixel-art gifs (when there are 2 or more parts moving, figuring out how the animation works can be hell D: ). This is, however, not suitable for professional animation (which isn't Krita's goal anyway, right? It wouldn't be bad to have an alternative to Gimp for animated gifs, though it is a niche use case) - It occurred to me recently that the separation between text and comic could be useful when translations are necessary, so the translator doesn't need image editing skills (which is a separate competence). Romantically Apocalyptic for example encourages readers to translate the comics into different languages. Well, again, a niche use case. By the way, in chat one of the devs told me that Boud is coding another feature: the ability to open images as layers. So, that could resolve the comic workflow issue, though you still have to export and import back in. Could layer clones work across different files? |
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], Sogou [Bot]