Call for Testing: 2-Point Perspective Assistant

Yes I need to design a way to configure the colors for the grid lines.

TODO: this assistant should probably have multiple configurable default colors per-axis.

Wooow Lazy Nezumi Pro has gotten very very advanced these past couple of years, their perspective system is different but looks very pleasant to use so I’ll definitely be taking some of their ideas. Would be great to have this kind of thing possible for the non-Windows Krita users out there (like myself).

CSP’s perspective drawing tools are also very advanced (video)

If you mean the snap that occurs when drawing, then yeah it is somewhat rough and not very sophisticated at the moment, I will need to do some deeper modifications to how assistants work as a whole to make it more pleasant.

TODO: this assistant probably should allow toggling snap per-axis

Yes. It’s the snap between 2 Point Assistant axes that doesn’t lock after it starts tracking.
Snap will lock nicely to the 2 Point Assistant and not jump to another nearby Assistant line when tracking, even if you try to force it.

Except for that little problem, it’s a very nice Assistant :slight_smile:

They came back after a restart. It may have been a strange file in the resources (as has been seen before) or just a random glitch.


Thanks for this new assistant :slight_smile:

On my side, only 2 remarks:

  1. The ALT as modifier is not a real good idea for Linux/KDE users as by default the ALT is used as a desktop modifier to move windows (so, except if I change how system is configured, I can’t use the ALT modifier)
  2. Like most of other assistants, it suffer of a snap delay that make the tool difficult to use because start of stroke is not made properly
    Example, on a A4@600dpi, need to move mouse about ~20pixels before starting to draw…

    Can’t use assistant tool for “small” strokes
    I opened a topic about this subject last year with a proposition to fix this problem:
    Assistant tool can't be used under a given size - #7 by Grum999

The interesting thing is, looking source code of TwoPointAssistant, this comment match exactly with the origin of the problem:

    // TODO: Would be a good idea to generalize this whole routine
    // in KisAlgebra2d, as it's all lifted from the vanishing
    // point assistant and parallel ruler assistant, and by
    // extension the perspective assistant...
    qreal dx = point.x() - strokeBegin.x();
    qreal dy = point.y() - strokeBegin.y();

    if (dx * dx + dy * dy < 4.0) {
        return strokeBegin;


There’s 2 possibilities:

  • remove completely this code
  • need to review this code to let the move being relative to screen (ie: 3~4px on screen OK, 20pixels on a document it’s unusable…)

For example, this drawing was just hell with this problem, and for this one I had to modify source code and compile Krita to remove this to be able to draw all buildings, especially the small ones in background

So if this can be solved with 2 point assistant, it would be really great :slight_smile:


nice work here :wink: i’ve tested it and like @AhabGreybeard i had “issue” with snapping which jump to other axis when tracing lines.

@Grum999 I’ve just tried the appimage and the ‘delay’ that I see is 4px of image size at 2048 x 2048 and 4096 x 4096 predefined templates no matter what the zoom setting. These two templates are 100dpi.

With a 2028 x 2048 image at 600dpi, the delay is 18 px.
With the A4 600dpi, it’s also 18px.
At 1200 dpi, it’s 36px.
At 50 dpi it’s 2px.
At 10dpi it’s 1px.

The dx and dy seem to be physical image distances.

1 Like

Thank you for testing! You’re right the deadzone are based on the document’s dimensions instead of the screen’s. TODO: The deadzones for assistants should definitely be measured using screen pixels instead.

Regarding the Alt situation, I’m not sure what to do. AFAIK Alt is also used by the selection tools and shape tools by default to allow the user to freely move the shape before releasing the mouse button. So whatever solution I end up settling with should also apply to those tools on principal.

1 Like

This is not limited to this 2 point perspective assistant, that it’s quite annoying that new assistant is created every time I (even accidently) click the canvas. I think it’d be better to change the way it’s created from click to drag like the current text tool.

As @AhabGreybeard said, playing with dpi on document allows to avoid the problem.
I’ve made some tests and it’s a good workaround; just have to know it :sweat_smile:

So it’s less critical than I initially though, but using screen distance rather than document dpi dependent distance might be more intuitive than modifying document dpi :wink:

All assistants works like this: while you’re using assistant tool, clicking on canvas create a new one
Or I misunderstood something :thinking:


I also think this would be better, and would work for all assistants. The only exceptional assistant in this regard is the Vanishing Point assistant, which is technically made of just one control point, but could be refactored to be constructed by click-dragging 2 lines, which intersect to define the canonical location of the 1 control point.

The whole assistant system will be refactored in the near feature, so this is something I will consider, I accidentally click-create assistants all the time and have become numb to how annoying it is.

1 Like

Yeah buddy that is exactly the point. And it is annoying.

Wow ! I like this… alot…
If i draw too fast the magnetism dont work properly at the end of the line, it’s the only problem i see for the moment, the tool is great.
Thanks guys for your work

Kubuntu and KDE plasma and I think gnome too has changed this to Meta or super key so this won’t be a problem in future. Nowadays most shortcut concerning window manager are mapped to super

I’m thinking about a different way to arrange the control points. Instead of 8 different control points, there’s just 6 since each VP can just share 2 of them. What do you think? Does something like this look like it makes more sense? (also adding some modifier key behaviour for them)

1 Like

@NabilMaghfurUsman Sharing control points like that would mean that they can’t be moved independently of each other (?) from what you show in the video. Does this technique maintain an important relationship between the two VPs?

The advantage of independently adjustable VPs is that they can be fitted to objects in an existing image. However, using two 1-point VPs would be the fallback method to use if you want that facility.

They can still be moved independently, I just didn’t show it much

1 Like
  1. Regarding sharing control points - it sounds as if it was harder to build perspective out of a photo, if this feature was implemented?

  2. Bug: Even with View -> Show Painting Assistants and View -> Show Assistants Previews both turned off, the grid is visible. On Vanishing point assistant, it disappears on View -> Show Painting Assistants.

  3. Issue: As usual, but in this case even more, judging which assistant to use for the stroke is difficult for Krita. This causes issues when painting lines that are somewhat semi-parallel. It’s even harder in case of this assistant, because usually, you could check “Snap single” and just undo all lines that start with a wrong alignment, but in case of your assistant, you can start a good stroke but still end up with a wrong one:

    (this is of course made on purpose, but I had trouble with that last time I tried to use it for painting).
    This is a very important issue (one of the most annoying when working with assistants). I would like to know how to fix it generally for all assistants…
    Note: fixed in Improvements to 2 Point Perspective (!822) · Merge requests · Graphics / Krita · GitLab

  4. Issue: when using Shift + drag on a vanishing point that was already set up in a skewed position against the other vanishing point, the Shift makes it move on the horizontal line that the second vanishing point lies on, instead of the horizontal line of the first vanishing point.

  5. Possible new feature: “saving” different perspective setups on the document? So for example I was drawing this picture:

    and I had several buildings to draw, so I had to use the ctrl+drag feature. But every time I did that, I would lose the previous setup, so I had to set it up again when I was working on the same building in an approximate position instead the exact one.

A stop-gap solution I’ll implement is to force the assistant to behave in snap single mode so the user is only capable of drawing along one axis per stroke.

Eventually I want a more sophisticated solution that allows changing axes in the middle of a stroke.

Thanks for trying it out on a drawing! This particular use-case is what this assistant is primarily for. As a workaround you can duplicate an assistant by saving it to a file and then loading it again.

Since it’s possible we might end up refactoring the whole assistant system, I’m having a hard time imagining what frictionless UX for this use-case will look like. Perhaps a simple Duplicate Assistant button is enough for now?

1 Like

It’s very nice for quickly setting up a scene, makes it easy to play around with viewing angles. The only thing is, I immediately long for a third vanishing point, right now I don’t think I can actually use this because I can’t get correct vertical lines for e.g. a low angle view. If a 3rd VP was possible to add, I’d be all over this.

If I may add something, can you make the brush not being snapped when it’s in eraser mode? I think it’d be cool. :slight_smile:

I fixed the 3. issue from my previous comment:

And I implemented a feature that allows you to turn off the vertical assistance if you need to have it off because you are for example using a third vanishing point to get 3 point perspective.

The appimage for testing is here: krita-5.0.0-prealpha-8d97b6e-x86_64.appimage — Яндекс.Диск
The MR with changes is here: Improvements to 2 Point Perspective (!822) · Merge requests · Graphics / Krita · GitLab

If at least one person confirms that it’s good to have those changes, I think I’m gonna just merge it, because I tested it on the picture I wanted to draw and it worked much, much better than before those changes. I would prefer to have @NabilMaghfurUsman 's confirmation first but frankly, I don’t really see a reason to not want those changes…