Page MenuHome

Brush resizing got locked to 1 axis.
Closed, InvalidPublic


System Information
Operating system: Linux-5.0.12-050012-generic-x86_64-with-neon-18.04-bionic 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.50

Blender Version
Broken: version: 2.81 (sub 14), branch: master, commit date: 2019-10-08 09:53, hash: rB270562fe125d
Worked: blender 2.80 release

Short description of error
This makes it hard to resize the brush while using a tablet. In fact, makes it nearly impossible to get the exact size you want on first try.

Exact steps for others to reproduce the error

  1. Add an object
  2. Go to Texture Paint mode
  3. Hit F to resize the brush

Event Timeline

This is an intended change

@Pablo Dobarro (pablodp606) I've talked to @Julien Kaspar (JulienKaspar) and it seems like some people still prefer to be able to move up and down as well to adjust the brush size.

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 80.

I'll put this on "waiting for dev..." as I don't think this needs to be triaged further. Only discussion is we are going to change this again or not.

@Pablo Dobarro (pablodp606) In my experience it's best to change the brush size/strength/etc with a diagonal hand movement. This feels more natural and while working with my Cintiq I am not blocking what I see with my hand (That is very much the case at the moment when moving from left to right).

If we want to keep the cursor centered, we need to measure the mouse displacement on a single axis. You still can drag diagonally and it should work, but the previous method was also not ideal for that (It was measuring the distance to the brush center + offset).
I can add a user preference to change the resize axis from X to Y, but I think that is going to be even more inconsistent with the previous behavior.

@Pablo Dobarro (pablodp606) Why does it have to be centered though? It feels pretty weird now because to scale it down u need to drag all the way to the left instead of center of the brush.

Also, now dragging diagonally makes it resize way too slow so you have to trigger the shortcut multiple times or move your arm alot.

@D. O. (Likkez) The distance you need to drag is exactly the same and it is constrained, so it should be easier to scale the brush down.

I dont know what's going on behind the scenes exactly but it definately feels way less responsive and snappy. The only benefit i can see this brings is you can scale the brush down to 1 pixel easier, however that is barely needed especially in other modes like sculpting and weight painting.

I agree with Likkez - while the distance may be the same having it constraint to one axis kinda breaks the work flow that many people have gotten used to. I just see no need for something that works well to be changed out of the blue. But I mean, if it HAS to be changed can't there be a middle ground? Like putting an option in the user preferences to change it back to the way it was.

Please try D6020 and check if resizing behavior is better.

@Pablo Dobarro (pablodp606) There must be a way of using the vertical axis as well. In my opinion this is the only issue with this.

@Julien Kaspar (JulienKaspar) Do you prefer an option to change the resize axis instead of being automatic?

@Pablo Dobarro (pablodp606) I think this patch is a great middle ground but right now it seems to be a little inconsistant like in the end of this video:

@D. O. (Likkez) That is because it is using the top/right direction to split the viewport in two areas and check if it needs to increase or decrease the value in that direction. If you drag in the bottom/right direction you are constantly activating different areas.

@Pablo Dobarro (pablodp606) is it possible to maybe create a vector from the direction u first start moving the cursor in and then read values from it instead of splitting viewport into areas?

@D. O. (Likkez) Yes, but in that case you will be always increasing the value first when dragging in any direction. To decrease the value you will need to drag and change the direction of the movement.

@Pablo Dobarro (pablodp606) I feel like that would be a really slight movement and won't be as annoying but that's just my opinion of course.

@D. O. (Likkez) If you want to try it, remove this line after applying the patch
Line 2699: mul_v2_fl(rc->resize_direction, -1.0f);

@Pablo Dobarro (pablodp606) Yea scratch that idea it feels pretty bad. I guess picking what axis to use manually would be the best in that case and maybe a sensitivity slider? Idk I wana hear what @Julien Kaspar (JulienKaspar) thinks.

@Pablo Dobarro (pablodp606) If it has to be only one axis then here's my suggestion:

We could have a setting in the preferences to offset the rotation of the horizontal axis that is used for the brush size/strength/etc. By default I would suggest that it'fs offset by like 30 to 40 degrees to be more diagonal. This is more fitting with the arc of the wrist rotation.
An example of another software that is doing this is Steam. Since the Steam controller is touch based you need to use your thumb to swipe along the touchpads that control the camera and character movement. In the controller settings there is a settings that offsets the horizontal axis to account for the arc of a thumb swipe. This makes the controls more comfortable.

The thing is: Different people have different needs. Some might want to have it completely horizontal or even vertical (Who knows). Also if you are left handed, you would want to have the axis at -30 to -40 degrees offset since your wrist rotation is flipped.
Some people with display tablets also rotate their tablet (Or themselves) when not being able to tilt the view (Which is still the case in Blender). This will also mess up the axis and cause confusion.

We decided to lock the brush resizing to one axis to support the new widget. There was some design experimentation on how to improve this by detecting the resize direction automatically or making it configurable, but each option has its pros and cons. This is a UX design project, not a bug.