|
|
| (7 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| = Google Summer of Code and Krita = | | = Google Summer of Code and Krita = |
|
| |
|
| We welcome students who want to work on Krita for Google Summer of Code. If you want to work on Krita, keep in mind that we would like you to stay with the project, also outside Summer of Code. Summer of Code isn't just a summer job with some mentoring added -- it's a way of becoming part of the team. | | We welcome students who want to work on Krita for Google Summer of Code. If you want to work on Krita, keep in mind that we would like you to stay with the project, also outside Summer of Code. Summer of Code isn't just a summer job with some mentoring added -- it's a way of becoming part of the team. We're also really underpowered at the moment, and we can only take on mentoring students who have a proven knowledge of C++ and Qt. |
| | |
| If you haven't worked on Krita before, we want you to demonstrate your skill beforehand by fixing bugs or implementing some features. It's a good idea to start on that in January. Here is a list of pre-gsoc ideas:
| |
| | |
| == Pre-GSOC ideas ==
| |
| | |
| ==== Idea: Integration with Web-Services ====
| |
| | |
| * https://bugs.kde.org/show_bug.cgi?id=274866
| |
| | |
| ==== Idea: Extended history manipulation ====
| |
| | |
| * Cumulative Undo/Redo (needs modifications to tiles engine to be able to merge several undo revisions)
| |
| * Snapshots?
| |
| | |
| ==== Small Project: Wavelet Filter====
| |
| | |
| ==== Small Project: Virtual Second Tip of the Stylus ====
| |
| | |
| ==== Small Project: Lazy Brush ====
| |
| | |
| ==== Small Project: Advanced Composition Docker ====
| |
| The Compostion docker needs some work to make it's use more fluent and useful to artists (comics,textures, regular export setups)
| |
| *Compositions should be updatable and have managment options (renaming,ordering)
| |
| *Workflow improvements for more easy use (selecting should not activate composition immediately)
| |
| *Save locks and other layer settings (preserve alpha,collapse state of groups etc.)
| |
| *Storage of exported image links
| |
| *Selective export (selection options to export all or some compositions)
| |
| *Snapshot preview of composition (optional)
| |
| | |
| | |
| https://bugs.kde.org/show_bug.cgi?id=322159
| |
| | |
| == GSOC ideas ==
| |
| | |
| We really like students who come up with their own project ideas. To get you started, however, here are some ideas we've come up with:
| |
| | |
| ==== Project: Painting and Separation of 3D Textures====
| |
| | |
| As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.
| |
| | |
| Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.
| |
| | |
| ==== Project: 3D Material Image Maps====
| |
| | |
| 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:
| |
| | |
| * Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.
| |
| | |
| * When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.
| |
| * In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).
| |
|
| |
| For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita.
| |
| | |
| Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.
| |
| | |
| ==== Project: Matte painting====
| |
| | |
| One of Krita's main use cases is as a professional tool for painting textures and mattes in digital film. Mattes are primarily made of sequences of images generated by a combination of two methods, first by animatable spline based shapes, which currently exists and is being developed in blender, and then after that, by hand painting frames for detailed areas and corrections. The trouble is that no currently maintained FOSS application currently tries to provide the ability to create hand painted mattes. This project is to extend Krita for this purpose. What's needed here is the following:
| |
| * The ability for Krita to load manually selected sequences of color managed images as frames to be represented as a single layer in Krita. Optionally would be the ability to display playback at reduced resolutions to increase performance and to offset the time at which sequences were inserted.
| |
| * A “Timeline” docker which would display the current frame displayed, and allow clicking and dragging to different points in time, updating the image displayed in the canvas to match. Optional would be the ability to zoom and scroll the timeline, mark modified frames on the timeline, playback the image sequence, forwards and backwards as video (most likely only in the openGL mode of Krita or with an external tool like ffplay) and display times in a range of formate EG SMTP, PAL, NTSC, Secam etc.
| |
| * Updating the paint and transparency layer types, so that when Krita is using a frame sequence and one of these layer types is created, they also represent a series of frames rather than just a single image. This could possibly be a toggle switch on layers, much as visibility, alpha lock etc. are now.
| |
| * The ability to save layers that are displaying frame sequences out as frame sequences also, giving them user definable names (eg where to insert the frame number, how many digits to pad).
| |
| * Keyboard shortcuts to move forwards and backwards 1/10/100 frames, to jump to the start and end of the timeline and forward / backwards play if video playback is supported.
| |
| | |
| ==== Project: Cartoon Text Balloon System====
| |
| | |
| Krita already has two text tools, but neither is suited for creating cartoon balloons. The system should allow the creation of vector-based balloons in different styles. The balloons can contain styled text. The text and balloons should be translatable and a system to select the current language should be created. It should be possible to save the balloon text to a separate file that can be used as input for translations. Finally, care must be taken to support right-left languages.
| |
| | |
| ==== Project: Substrate simulation ====
| |
| | |
| '''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.
| |
| Expected results: an optional substrate simulation that works with all current Krita tools
| |
| | |
| ==== Project: Real Paint Emulation ====
| |
| | |
| We already did some research on the emulation of real-world paint and we do already have some essential pieces of it: Hairy Brush and Bumpmap filter. Now we need to bring this all together and allow a painter to use it easily, so that he could paint images like that: TODO. This project would involve creation of a special type of layer and a new colorspace, so the student should already be familiar with our layer stack and pigment code.
| |
| | |
| ==== Research Project: layer stack optimizations ====
| |
| | |
| Right now when one layer got changed our merger should walk through all the layers of the current group and compose all of them into projection one by one. But this doesn't take into account that COMPOSITE_OVER (which is the most popular composition mode) has an associativity property, which means we can merge all the layers below and all the layers above dirty one into two groups, and calculate a group of any size with only two composition operations, which would give huge speed advantages.
| |
| | |
| Unoptimized group:
| |
| | |
| * layer 6
| |
| * layer 5
| |
| * layer 4
| |
| * layer 3 <-- active layer (becomes dirty quite often)
| |
| * layer 2
| |
| * layer 1
| |
| | |
| Optimized group:
| |
| | |
| * <flattened 4-6>
| |
| * layer 3 <-- active layer (becomes dirty quite often)
| |
| * <flattened 1-2>
| |
| | |
| After this project is done, we can start implementing layer composition on the GPU using openGL.
| |
| | |
| | |
| | |
| ==== Project: Improved Animation Brush implementation ====
| |
| This should result in animation brushes being more readily available and adjustable. The current way of doing this is not as userfriendly as it could be.
| |
| | |
| *Dedicated "Animation Brush GROUP"-> everything in group is a frame of the animation. (for use in current file,instead of in another instance of krita)
| |
| *Convert group to animation group ->Normal group becomes animation brush reference.
| |
| *Save as animation brush PRESET
| |
| *options to set animation brush continuity to custom, random, incremental, pressure,angular,loop...
| |
| *animation brush presets (in settings) need a timeslider to flip through the available frames
| |
| | |
| https://bugs.kde.org/show_bug.cgi?id=322159
| |
| | |
| ==== Project: seamless textures by using UV layout as self-wrapping paint mask====
| |
| This is a tool that should help in creating seamless (or as close as possible) textures for organic models. It will help in painting creases and other details across seams.
| |
| http://www.sintel.org/wp-content/uploads/2010/01/face_uv_export.png
| |
| | |
| *Convert intersections on uvlayout to seam transfer points.
| |
| *use those points to transfer painted strokes to connected points on other side (set by user)
| |
| *create userfriendly way to add,manage those seam transfer points.
| |
| (multiple should be active at once)
| |
| | |
| https://bugs.kde.org/show_bug.cgi?id=324072
| |
| | |
| ALTERNATIVE
| |
| *Similar to previous idea,but with movable curves/grid with adjustable seam transfer points in stead of converting a whole UV layout automaticly
| |
| | |
| https://bugs.kde.org/show_bug.cgi?id=321547
| |
| | |
| == Past GSOC projects ==
| |
Google Summer of Code and Krita
We welcome students who want to work on Krita for Google Summer of Code. If you want to work on Krita, keep in mind that we would like you to stay with the project, also outside Summer of Code. Summer of Code isn't just a summer job with some mentoring added -- it's a way of becoming part of the team. We're also really underpowered at the moment, and we can only take on mentoring students who have a proven knowledge of C++ and Qt.
