So I started working on the backend code. It’s mostly done, but I haven’t prototyped code for snowflake symmetry yet. Normal rotational symmetry is implemented. Just need to actually do a test build in my VM before I publicly share the changes.
However, there’s two main API issues so far are:
There are a few fields that’re exclusive to rotational and snowflake symmetry. Those fields are:
number of symmetry lines
angle offset for the rotational symmetry lines (eg: you want the 0 degree line of a rotational symmetry line set to point downward)
If snowflake symmetry is merged with normal rotational symmetry, probably a boolean that says, “Mirror around rotational lines”
That being said, would fields that’re for rotation mode best be dedicated to another function and/or struct to avoid API breakage? I’d think so, but I wanted to double-check.
We don’t have tests for symmetry right now. Given the amount of modes we’ll need to support, I think this is mandatory since we’ll need to make sure the strokes not only end up at the right coordinates, but also get the correct angles applied to them.
Secondly, there’s some UI concerns that I wanted to ask about. I can’t find the comment I originally left about it on the main frontend issue :S. It seems like either it never went through or it got deleted.
The main UI concerns for implementing the alternate symmetries are such:
When grabbing a rotational symmetry line, should the user be allowed to move it in both x and y directions? This might not always be the case when the user just wants to make a slight adjustment to the center of the rotational symmetry.
How are we going to indicate 4-fold rotational symmetry with no angle offset as something different from having both horizontal and vertical symmetry enabled? Both would wind up having a horizontal and vertical line in the symmetry overlay. The first idea that comes to mind is overlaying little arrows near the ends of the rotational symmetry lines to indicate that they’re not mirror lines.
Sometimes it doesn’t pass the rotational symmetry lines value to the backend. This typically happens with rotational lines in the 2-3 range.[PUT WORKAROUND FOR NOW]
Re-add the trashcan button after I figure out how to adjust the code.[DONE]
Add an overlay that indicates where the radial symmetry lines occur?
Make the rotational lines dropdown insensitive when picking a non-rotational symmetry mode.[DONE]
I’ll be pushing this to github soon. Going to update top post with WIP links.
I guess you are working on displaying all rotational lines (not just the two like right now). So moving it x or y only would not work anyway (where to move a line that’s displayed at 45°)? Moving has to affect the whole rotational star, I guess. My first thought was: Have an Icon near the middle for movement, grab any rotational axis to rotate around middle. But maybe its better the other way around: grab anywhere to move the whole thing, have an additional icon/handler at an axis that rotates when grabbed.
I agree, just two arrowheads should make it clear. Could also show the difference between snowflake and rotational. I’d position them near the center:
Ah wait, Vert-Horiz and Snowflake-4 would have the same appearance, but don’t do the same thing (snow flake 2 does), or maybe not, maybe I’m just confused. YES PLZ!!!: “Add an overlay that indicates where the radial symmetry lines occur?”
I also noticed that the side panel gets stretched a lot wider. I guess the text “Number of rotational lines” is too long. In Portrait mode almost half my screen gets covered (I usually have it to show 4 columns of brushes):
You should tackle “repeating pattern” mode next! You seem capable. I read through all your commit code, but I’m still overwhelmed by the frontend stuff.
Oh I just noticed: GIMP will have symmetry painting too!
They call it “Mirror” = horizontal-vertical-snowflake, “Mandala” = rotation and “Tiling” = repeated patterns. Maybe symmetry in MyPaint should be similar? I didn’t test gimp symmetry, but I guess it makes sense to have a similar UI for the sake of convenience.
Hey there! Sorry for the delayed reply. Was refactoring a few things yesterday. Anyhow, to answer your questions and answers!
One possibility I was thinking is having the axis display as crosshairs when in edit mode, but have it display as the rotational display when it’s non-editing mode. (<- the drawing the axes code is intermingled with the trashcan placement code, even before the edits)
As for the alternate way around you suggested (having alt buttons for movement and rotation), there’s also the issue of placing the trashcan button. That’s already trying to be placed near the center of the existing axes. What do you suggest we do about the trashcan button?
Vert-Horiz and Snowflake-4 do indeed do different things. Vert-Horiz and Snowflake-2 do the same thing. I was wondering if Vert-Horiz would be redundant since one can just snowflake-2 for same results.
Yeesh D:. I’ll go rename the label for that. “Rotational lines” would probably be the best way to name it without adding the bloat of “Number of”.
Mandala would be a nice name for rotational symmetry mode. Tiling is tiling. Mirror in GIMP terms is implemented differently than in MyPaint. Ticking on both Vertical and Horizontal will draw two expected dabs, but not the third dab diagonal from the initial stroke unless central symmetry is on.
I’ve been eyeing that repeating pattern mode for quite a while! I’ll take a look at your code and enhance the UI for it in the next two weeks.
You seem capable. I read through all your commit code, but I’m still overwhelmed by the frontend stuff.