Make editor flip, rotate, and scale tools revolve around the grid center #26311
Conversation
This caused issues in rendering the outline of the grid because the outline was getting masked at some resolutions.
OliBomby
changed the title
|
I don't hate the idea, but I quite dislike the execution.
I will go ask around for feedback somewhere but this is not feeling great in my view. If you asked me how to implement it, it would be a third option rather than replacing playfield origin, and it would be limited to square grid for flipping. |
|
I'm kind of surprised by this reaction because it felt pretty awesome and intuitive to use for me.
I don't think a third option is necessary. If the user has moved the grid, then they are clearly not working with playfield center symmetry, so it wouldn't make sense to allow that. If the user specifically means to flip around the playfield center, then they can just reset the grid settings. Also there is no way to specify an origin option for the flip operations since that's only a hotkey.
Fair enough, it's technically not the playfield centre. I kinda meant to stretch the definition of "Playfield centre" to equal "Grid centre", like you are able to control where the playfield centre is. I'm not against renaming the buttons to make them more accurate.
I always meant the grid types to only affect snapping and to just be different representations of the same underlying grid configuration. If the everything starts behaving differently based on grid type that would break that notion and just be more confusing I think. I'll admit on the circular grid it does look a bit weird because there is no sense of rotation, but its nice to have that customizability. Maybe the mapper is using a specific rotated symmetry in their map and only temporarily enabled the circular grid. In that case its nice to be able to still use that rotation. That's another reason why I was against disabling the rotation slider in #26310 |
This reverts commit 4165ded.
|
@bdach The flip functionality on hexgrid now takes the axes on the grid that are closest to the direction that you want to flip, so you always flip along the axes of the grid and it makes sense visuallly. The circular grid defaults to 0 rotation flips. It felt wrong to disable flipping entirely for circular grids. The precise rotation/scale popovers now show "Grid centre" as an origin option which is the first option. |
|
Tests failing |
Dunno how to feel about this, feels essentially random: 2024-07-16.12-42-54.mp4This is all going to be very dependent on mapper feedback. So the options are to either get this out and bear the possible backlash/hope there is none or get experienced mapper(s) on board to provide early feedback. I'll ask around. |
|
I noticed an error in how it determines the axis for the horizontal flip in your video. |
|
When I asked the NAT the best idea of how to make flip work with triangle grid that I got was implementing a flow to actually select an axis for the flip rather than guessing / approximating and I do agree with that assessment. Either that or just straight up disable flip with triangular grid I guess. |
What should that flow look like? Maybe you can hold down the flip key and move your cursor to one of the six partitions made by the axes of the grid and then when you release the key it flips to that paritition.
I disagree with disabling flip entirely. I think a slightly confusing implementation is at least better than having no tools at all. |
It shouldn't be hold. I'd see the editor entering a special "modal" state wherein the axes highlight as you move mouse. Left mouse / enter to do the flip, right mouse / escape to not. |
I'm not sure about this flow because mouse down ending the movement is unlike anything we've done elsewhere. I'd rather have the flip works as it does currently, or select an axis to flip on based on your mouse position when you press/release the flip hotkey. |
Honestly I disagree with this. Just let the mapper use trial and error to get it right. It's such an edge case we shouldn't be overloading already complex user interactions just to save a few trial-until-succeed attempts. |
| @@ -20,21 +20,25 @@ public partial class PreciseScalePopover : OsuPopover | |||
| { | |||
| private readonly OsuSelectionScaleHandler scaleHandler; | |||
|
|
|||
| private readonly Bindable<PreciseScaleInfo> scaleInfo = new Bindable<PreciseScaleInfo>(new PreciseScaleInfo(1, ScaleOrigin.PlayfieldCentre, true, true)); | |||
| private readonly OsuGridToolboxGroup gridToolbox; | |||
There was a problem hiding this comment.
I'm somewhat uneasy with drawables being shoved into other drawables like this just for the sake of sharing data. Can the grid configuration be shipped into like a record, and then we can use bindables for this purpose rather than shoving components in wholesale?
There was a problem hiding this comment.
I tried implementing this with passing bindables but it just doesnt work. The bindables that you pass to the transform popovers get disposed when so you have to chain bindable updates, turning into a big mess. Also when I tried binding a bindable in the popover to a bindable you pass in the constructor, it would be null once the popover loads.
Maybe injecting drawables into other drawables isn't that bad. It's also being done with many other components and it seems to work fine.
Rewrite GetConvexHull using the clean room method
Part of #26303
Requires
Changes how the Ctrl+H and Ctrl+J flip mechanic works. It now takes into account the origin and rotation of the grid to flip around that axis. This makes it easy to map symmetric patterns which are off-angle or not around the center of the playfield.
Also the Ctrl+R rotation tool uses the grid origin as the center of the playfield.
The precision scale tool uses the grid origin as the center of the playfield and uses the grid rotation for axis constrained scaling (for scaling only along the X or Y axis)