Add corner smoothing to StyleBoxFlat

[tsutsen]

Resolves godotengine/godot-proposals#13353.

This PR adds squircle/superellipse rounding with two parameters: corner_smoothing_enabled and corner_smoothing_strength. I'm not sure if it's better to omit corner_smoothing_enabled and just do corner smoothing when corner_smoothing_strength > 0.

[FFF27]

Consistent with existing behavior would be either x=0 meaning disabled, or defaulting to -1 and using x < 0 to mean disabled.

Also, would you mind updating doc/classes/StyleBoxFlat.xml to explain how to use this feature? corner_smoothing_strength seems somewhat arbitrary - what range of values do you expect?

[tsutsen]

Consistent with existing behavior would be either x=0 meaning disabled, or defaulting to -1 and using x < 0 to mean disabled.

In the last commits, I've got rid of the corner_smoothing_enabled and adapted the formula from the CSS docs. The default value there is 1.0, which basically coresponds to '100% rounded' and produces regular rounded corners. Increasing the smoothing value gradually makes corners approach a perfect square -- around 2.0 it looks like a squircle, and beyond 10.0 the shape is almost indistinguishable from a square. That's why 10 is the higher threshold for corner_radius_smoothing. The lower threshold is 0.0 because below 0.0 antialiasing and border width calculations break -- antialiasing vanishes and corner borders become thin.

would you mind updating doc/classes/StyleBoxFlat.xml to explain how to use this feature?

Of course! I've added the docs entry. Should we also mention the source I've adapted the formula and descriptions from (CSS docs)?

[tsutsen]

Here's an example of how different corner smoothing values look. I'm not sure how critical it is that with corner_radius_smoothing = 0 border width is significantly smaller around the corners, and with corner_radius_smoothing > 1.0 it's slightly larger.

We can either set the corner_radius_smoothing lower threshold to 1.0 so that this issue is less noticeable, or rework border width calculation.

Most likely, in the latter case, issues with concave corners I mentioned earlier will also be fixed and we'll gain an ability to draw astroids (n<0) in-editor. However, I haven't looked into that thoroughly yet.

[FFF27]

You're failing the automatic tests, see https://docs.godotengine.org/en/4.4/contributing/development/code_style_guidelines.html#using-clang-format-locally for how to run those tests locally before committing.

I don't see the point in arbitrarily limiting the max value to 10. You should allow any value that doesn't outright break things. You can use the property_hint ,or_less,or_greater to allow manually entering custom values outside the slider's visible range, see https://docs.godotengine.org/en/stable/classes/class_%40globalscope.html#enum-globalscope-propertyhint

[Voxybuns]

i love you. (platonically)

edit: shame about values <0 not being allowed due to breaking rendering code, it would allow for some neat effects like notched or scooped corners, but i'll happily take my squircles :)

[tsutsen]

shame about values <0 not being allowed

I am currently trying to fix it, and there's some progress. I've already fixed the consistency of border widths across different corner_radius_smoothing values by:

1. calculating normal unit vectors from each corner point and then
2. multiplying them by border_width

I am not sure how good of a solution this is though, because it changes current corner rounding logic and adds quite a bit of code. Anyhow, I'll tidy things up and make a commit soon I hope. AA is still kinda broken but there's some progress too.

And about the alternatives to the normals-based-solution: the one I've got is to create a heuristic to draw parallel-looking border lines. Here are the equations I've prepared in Desmos: https://www.desmos.com/calculator/qcqzysryq4. Maybe this approach would be more efficient but the results will be less accurate and stable I believe.

You're failing the automatic tests

Thank you for the link! I've missed the pre-commit part somehow.

You should allow any value that doesn't outright break things

Agreed, will do!