-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brush inputs/settings calibrated for viewzoom and viewrotation +new input (viewzoom) #70
Conversation
Not sure why the check is failing. I will test it on Windows 10 soon |
That's a really cool way of doing it -- hadn't considered the possibilities of square graphs. (though I'm kind of losing track of how many pull requests you have pending, heh ;) So to be really explicit:
.. A base-radius of N and a view-zoom of minus N -> brush is rendered with "real" base-radius N at 100% zoom; "real" base radius N/2 at 200% zoom; "real" base radius N*2 at 50% zoom? And if view-zoom was set to plus N, "real" brush radius would be what (for each of: 100%, 200%, 50%)? (the reference to size zero @ 6400% confused me, partially because size zero isn't actually infinitely small in MyPaint) |
I think that's right-- if you mean "real" as in "pixels" (or exp(N)).
100% would brush radius of N - log(exp(N) * 1 / 1.0) I never realized that brush size of zero is actually 1 pixel. (exp(0)=1). So now having negative brush sizes makes sense for sub-pixel rendering I suppose exp(-2) is .13 pixels. So my example assumes that you want your brush to be 1 pixel at maximum zoom. That seems to make sense, but you'll never get to .13 this way. Also, after playing with it more it feels more natural to reach 1 pixel a lot sooner than 6400%. But that would entirely depend on your preference for a particular brush. So I think having this control is a lot more flexible than a checkbox-- albeit it is way more complicated-looking. here are charts for base radius of 2 and -1. Obviously if you start with a base value of -1 you won't be able to get to -5 when you zoom in to 6400%. Or maybe you can, hopefully it doesn't overlflow like that but I think it might. |
@briend seems like your pull request failed a test on appveyor. Could you check the logs and see if you address the problem? |
I'm still not quite sure what step_viewzoom and step_viewrotation should do. I think that part can be cleaned up/removed. If I understand it is supposed to interpolate the input data if changes, but I don't think the zoom or rotation will change during a draw event-- or at least they aren't likely to change. I've played around with "spinning the view" while drawing and it's not very practical. |
rebased with master |
When rotating canvas or zooming in, inputs such as speed, direction, etc should continue to work as if you just rotated a physical canvas in front of you or peered closer at your work. As it stands, rotating the view or zooming in/out will change the inputs in an (arguably) unexpected way. Viewzoom is made a useable input for end-users, as it can be useful for certain inputs such as changing brush radius as you zoom in. Closes mypaint#66
fixes #66
This branch and the associated mypaint gui branch (https://github.com/briend/mypaint/tree/view-zoom) add zoom-level and view-rotation as inputs to the brush library. The brush library then applies these inputs to the relevant brush inputs or settings such that the brush is not affected by zoom or rotation of the canvas. Two additional changes that were necessary to include in this pull-- ascension formula change and replacement of fmodf with custom mod function for negative values. Also, brush_radius is removed from the formula that affects speed because it is no longer balanced by the the zoom-effect.
inputs/settings affected: direction, ascension, speed, brush-dab-angle. Speeds are clamped at 4.0. The only brushes that should be affected are those that were expecting the overflow of speed (beyond 4.0) and the rare overflow of ascension, so it should be pretty backwards-compatible.