Description
Tested versions
-Reproducible in:
- v4.3.stable.mono.official [77dcf97]
- v4.3.stable.official [77dcf97]
- v4.3.rc1.official [e343dbb]
- v4.3.beta3.official [82cedc8]
- v4.3.dev6.official [89850d5]
Not reproducible in:
- v4.3.dev5.official [89f70e9]
- v4.3.dev4.official [df78c06]
- v4.3.dev3.official [36e943b]
- v4.2.2.stable.official [15073af]
System information
Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 32.0.15.6603) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)
Issue description
Normally, using Geometry2D.offset_polygon() w/ JOIN_ROUND on, say, a square polygon produces the following; you can see the number of total points is 48:
However, as of v4.3.dev6.official [89850d5], it produces the following; a point count of 5316:
I am using the same code for both examples:
func _ready() -> void:
var poly : PackedVector2Array = [Vector2(0, 0), Vector2(500, 0), Vector2(500, 500), Vector2(0, 500)]
polygon = Geometry2D.offset_polygon(poly, 100, Geometry2D.JOIN_ROUND)[0]I assume that before, it had some way of determining the optimal, minimum point count for performance reasons; now, it seems to cram in as many as it can, which certainly looks nice, but has MASSIVELY affected performance in several areas of my project.
I'm unsure if this is a bug, or intentional; I can see in the changelog, a mention of, "Add closest_points_between_segments() basis path tests for Geometry2D (GH-48652)," but reading the thread, I can't say for sure if its relevant.
If it is intentional, a way to indicate to Godot that I'd like it to decide the optimal, minimum number of points to be used, would be appreciated.
I believe draw_arc() has something to that effect, for instance.
Steps to reproduce
Simply open the MRP; the Geometry2D.offset_polygon() script on the Polygon2D node will run automatically in the editor.