Sure.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 19 2019
Jan 30 2019
Shall we close this?
Dec 11 2018
Possibly a stop watch symbol??
I'm not good at drawing but good at photo shop.
Dec 2 2018
Nov 3 2018
In T3496#163171, @scottpetrovic wrote:
Oct 7 2018
Here is an idea I had about how the UI and UX would work with animation cycles. Not sure what people thought.
Jul 10 2018
My main concern for the cycles is making sure these controls don't start overlapping. If we start overlapping any existing items, this could be difficult to use fast. We will only be able to change and move things from a right-click menu since there selecting it on the timeline will be difficult (are we selecting the frame contents or cycle?). So far the two versions of the mockups I have seen have overlapping UI elements between the frame and the cycle which is going to make manipulating more difficult.
- User can select a (continuous) range on the timeline, open the context menu and select "Create cycle".
May 22 2018
I assume in your example the run cycle is drawn somewhere outside the range of frames you describe here.
In T3496#143273, @emmetoneill wrote:Sounds good. Does "draw on repeats" mean that if you drawn on a "ghost" of a frame it will also modify the original frame and all other ghosts? That sounds convenient, if I'm understanding it right.
May 21 2018
Our users should be able to:
- mark a cycle on the timeline
- change the range frames which are repeated
- edit the frames of a cycle. Changes should be reflected in the repeats.
- convert repeats into actual keyframes or clone frames
- draw on repeats without breaking the cycle due to automatic keyframing (option in autokey?)
Thanks for the mockup, Emmet. Based on it, we continued discussing the feature with Bollebib today. We gathered some requirements and possible solutions.
May 20 2018
Hey everyone, I just wanted to share a possible design mock-up for animation cycles that I put together.
Feb 20 2018
Sep 2 2017
May 29 2017
In T5882#95638, @woltherav wrote:KisBaseNode has a keyframes() which does not give access to a QMap, but rather the QList of of a QMap.values(). This is not too bad, as the QMap.keys() contain standard IDs noted in KisKeyFrameChannel.
May 27 2017
Outch... Generating a list of the values in a map is _expensive_. That really needs to be refactored in KisBVaseNode.
KisBaseNode has a keyframes() which does not give access to a QMap, but rather the QList of of a QMap.values(). This is not too bad, as the QMap.keys() contain standard IDs noted in KisKeyFrameChannel.
May 25 2017
May 24 2017
May 21 2017
Plugin to add a docker that shows most recent opened documents with thumbnails - same as the other docker idea?
May 19 2017
When developing games, they often need to combine multiple grayscale "channels" (hightmaps, textures, lighting) into one RGBA image to pass to the game engine. This combining is very custom and it is an ideal target for being implemented as a script. And it is also a nice target for showing raw data access.
I suspect that you haven't built Krita with scripting yet? This is already implemented, and managing the scripts is part of the settings dialog.
May 18 2017
I would argue having one or two regular operations scripts(such as web export) would be good because then we can verify whether this is possible with the current API. Similarly, people use these scripts as a basis for their own.
In T5885#94481, @dkazakov wrote:Hi, @eliakinalmeida!
I'll try to lay out my ideas about scripting here:
- As far as I can tell, the main purpose of the interactive scripting editor and the showcases is to allow the user to extend his Krita with some custom functions that save his time. It means that we should pay attention not only to the script editing part, but also to way how to run them. So at least such features might be necessary for the user:
- A docker with a list of "registered" scripts that allows the user (can be implemented in python as par to the showcase actually):
- add/remove "registered" scripts
- run/stop script
- group scripts in folders
- assign a shortcut to the script
Yes, I think that the Frame object should have a pixeldata method just like the Node object.
I'll try to lay out my ideas about scripting here:
- Image color space for multiple documents - yes, that should be an easy one
- Changing canvas size for multiple documents - same thing, doesn't need new api either
- Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list). - yes
- High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972 - yes
- Docker that shows thumbnails for last ten opened images - yes
- A multifill script - http://davidrevoy.com/article306/tons-of-potions-part-2-multifill - yes
- Export all the layers (batch) - http://registry.gimp.org/node/28268 - yes
- An "export to web" script - doubtful...
- Duplicate image. Could be interesting
- Scale down an image. - same as the second one?
- Export to jpg X% quality. - doable, a bit trivial
- Plugin to add a docker that shows most recent opened documents with thumbnails - same as the other docker idea?
May 17 2017
i second what woltherav said.
As I told to Boud, I'm talking with users to get some interesting ideas and suggestions to these next three months implementing Krita's showcase to for the GSoC.
May 16 2017
Yes I agree with a lot of @Bollebib points. If we are doing a "cycle", we need to have some concept of a set of frames to be repeated. Right now everything is just one frame at a time. With adding the idea of cycles, there might be a lot of work needed behind the scenes to support that concept like empty frames and a different display for a group of frames.
there might be some discussion needed still,you can often find me on IRC for an animator's input.
The following will be my initial thoughts but can be downscaled to make it more manageable or expanded to make it more feature complete. I have no idea how big this project needs to be for the student,so it will need discussion.
May 15 2017
I think it would be good to see how this fits in to the big picture when we do the UI. Here are the mockups for the original discussion. https://phabricator.kde.org/M2
One of the students chose the task for his practice task. Please add your ideas about what you think should be implemented here! :)
Apr 18 2017
Apr 14 2017
Hm... wouldn't it be necessary as well to make sure that people can access the resultant pixeldata of a given frame? especially when dealing with opacity keyframes. Like say, if someone wishes to make an exporter that generates a spritesheet, they would want to take a node and itterate over the frames, but not touch the actual keyframes.
I would suggest having an object to represent a keyframe, as there are a fair number of properties they have. Specifically, all keyframes have time and color label. Opacity frames have their value, interpolation modes and tangents. Raster frames of course have pixel data.
Apr 12 2017
Jan 3 2017
I'm agreed with @stamoglouodysseas. We need a checkbox in preferences not to draw behind the canvas. I guess it's easy to add.
With this checkbox everyone will be happy.
@woltherav
At the moment you cannot see what you do beyond the canvas boundaries, so it wouldn't really serve that purpose. It would make sense if we had a bleed area like layout software (coreldraw,illustrator, etc), where you can actually see the whole image. But perhaps this goes a bit too far..
Bleeding space would fit into artist's workflow, as it is how people use the same concept in printing. We just need to allow a 'export with bleeding space' type of option somewhere and it would fit right into a print workflow.
These options could help, although in practice it is almost the same effort as trimming the layer to image size or manually cropping the image. You require the user to take an extra action to trim the layers to image size.
I personally do not have any use for the strokes beyond image boundaries, and would like to have a default setting that prevents it from happening.
I understand that others might have use for it though, so this is where the bleeding space idea came from.
I'm also fine with not writing pixels when painting outside the canvas area -- that way, strokes can still start outside the canvas, but it won't grow the image.
I would like to also hear other's opinion about the "bleeding space". I'm not sure it fits the workflow of any kind of painters...
Another idea would be to define something like a "bleed" area in pixels, in the document settings.
For example:
We make a 1000 x 1000 px document.
We define a bleeding space of 200px. That would create something like a "buffer" zone around the canvas, so that the strokes are not cut at the image size but they can be extended by 100px more in each direction.
This will give us more control over the whole thing. The strokes won't be able to extend to infinity, but we also maintain the "stroke beyond boundaries" feature. If we want the strokes to end at the image size, we simply do not add any bleeding space (0 pixels)
You cannot draw outside the canvas in PS. But if you move/resize the layer, so that part of it is out of the canvas borders, the information is preserved. The same is true if you paste an image that extends beyond the canvas boundaries. You can trim these pixels by cropping the image.