3-point perspective grid in SeExpr, I want some feedback

[tiar]

Hi, I am working on a SeExpr scripts bundle. I’m going to make several grids, I already have standard grid (define the grid by pixels), divided grid (by default: “rule of thirds” grid, but it doesn’t need to be divided into three sections), phi grid (“rule of thirds” but with the golden ratio), and I recently coded the 3-point perspective grid as well.

However it’s not really as straight-forward as other grids, hence I’m writing this thread to get some feedback from other users.

This image above was created in Krita using three Fill Layers with those scripts attached with some different configurations. I used Multiply method there.

Instruction of installation

You need to use Krita Plus and download my script from: Perspective_Grid_Usable_With_Offset.kse - Google Drive

See detailed instruction

1. Download Krita 4.4.0-beta2 from the website (Second Beta out for Krita 4.4.0 | Krita):
   • Windows: (get the .zip file, unzip, double-click on krita there)
   • Linux: (get the *.appimage file with krita in it)
2. Create a new document.
3. Add a Fill Layer using the little arrow next to the [+] button in the Layers docker.
4. Select SeExpr.
5. Press the button with folder icon. It has a tooltips that says “Import resource”.
6. Find the script you downloaded. It’s probably in the Downloads folder. Then select it in the scripts choice area. (It has an ugly white + strokes icon).
7. Go to the Script tab and change settings until you’re satisfied.

Instruction of usage

General tips:

• You can drag the divider and hide the script area completely.
• For all options you can write down a value that has decimal places (0.1) or value outside of the range (for example default range for start and end are to 5000, but if your canvas is bigger, you can make this value bigger as well… although, I worry about the performance )
• It works best with a filter mask with Color to Alpha filter, or maybe instead of the mask, you can use Multiply blending mode on the layer. The Fill Layer is always opaque by default.
• You can convert it to a paint layer easily afterwards.
• options fast, start and end affect performance!

Every option explained (+ tips!):

Click here to unwind

Common options

• fast - you can choose an algorithm:
  • fast (1) will be faster, but the width of the line will vary.
  • slow (0) will have consistent lines width, but is much slower.
  • TIP: Keep it on 1, then switch to 0 when you’re satisfied with the perspective
• thickness - in both algorithm it has a bit different interpretation, but generally it makes lines thicker or thinner.
  • TIP - you can actually write values like 0.5 there.
• start and end - define the area covered by the grid.
  • the first number is x, the second one is y, and the third one doesn’t do anything
  • for example if you have a canvas 1000x1000 and you want the grid to have 100 pixels margin, you can put it in like that: start [100, 100, 0] and end [900, 900, 0] (note: that’s because 900 = 1000 - 100 )
  • TIP - it affects the performance: the smaller it is, the faster the algorithm gets
  • you can also paint with black on the Fill Layer itself, but it won’t affect the performance. Still, nice for when your comic panels are not rectangular
• backgroundColor - color of the background. It cannot be made transparent, sorry that’s a SeExpr limitation.

Options for every vanishing point:

• color# - color of the lines
• xS# - x location of the # vanishing point
  • TIP for the slow algorithm, for pixel art, for now I’d suggest using values like 10.5, 100.5, always with 0.5 at the end. For normal-sized pictures it won’t make much difference.
• yS# - y location of the # vanishing point
• angle# - angle between lines for the vanishing point
  • TIP - you can add decimal places here too!

My questions

• Is it usable at all? Isn’t the performance, or setup too much of a drag?
• if you look closely, I have two different ways of defining X and Y:
  • a vector of three, that only two numbers out of three are used (start and end)
  • defining both separately (xS1 and yS1 etc.)
    which one is better? the second one means lots of options… (I cannot do two-values vector)
• any other thoughts you have about it?

[tom]

While this is an interesting showcase of what SeExpr can do, unfortunately my dated i3 Haswell isn’t powerful enough to utilize this particular script to a usable degree, even when using all four threads. Maybe others with more modern and powerful processors would be able to make use of this, but the performance problem also exasperates the difficulty of the UX, as I can’t drag the points on the canvas to where I’d want them, so I’d have to make estimates with the sliders. After editing the x/y locations using these sliders, it will take at least a couple seconds for the canvas to update to truly see where the vanishing point will lie, even when using the fast setting.

(It also appears to crash when reloading the default script preset, but this appears to also be a problem with other bundled scripts in git commit version ec42777.)

[tiar]

Thanks for your review! That helps a lot, even if it wasn’t positive.

@tom

(It also appears to crash when reloading the default script preset, but this appears to also be a problem with other bundled scripts in git commit version ec42777.)

This is on master/Krita Next, which has issues with resource management right now, so it’s expected. I don’t think it happens on stable though.

[Zer0Frost]

@tiar

• Is it usable at all? Isn’t the performance, or setup too much of a drag?
• if you look closely, I have two different ways of defining X and Y:
  • a vector of three, that only two numbers out of three are used ( start and end )
  • defining both separately ( xS1 and yS1 etc.)
    which one is better? the second one means lots of options… (I cannot do two-values vector)
• any other thoughts you have about it?

I had created 4000 x 4000 canvas and run the script.
Changes takes 4s on Fast and 5s on Slow using Xeon E5-2620 (8 cores/16logicalprocessors)

Script seem to use all processing power of all cores

So I would say performance leave something to be desired. But maybe SeExpr cant run faster idk.

For UX it wouldnt really matter. Ofcourse if unused vector would be hidden on UI.

As for my suggstions:

• There could be additional controls to transform all points together (translate and rotate)
• 0 0 values for xS could start from the middle of the canvas and maybe doesnt allow Vanishing points to change sides (left would go from -x to 0 and right form 0 to +x)
• Sliders have limited range so they seem to not be good choise for setting Vanishing points that more often than not are way off canvas. Imo better functionality would be having event where Clicking LMB and dragging over numerical value Left-Right would decrease or increase it.
• adding option to have one pixel AA lines maybe (now Slower renderd lines are 2pix wide)
• option to have straight horizontal and/or vertical lines for one/two point perspective would be usefull.

Its good feature to have for people that prefer to have their perspective grid on rasterized layer.
It can be used to generate one vanishing point on the middle of the canvas and then paste it as layer onto your other projects (thats pretty popular workflow around the internet) - slow performance of script doesnt matter in this workflow.

Krita’s Assistant perspective tools are really amazing and its hard to top it, but I belive this script will find its users