I wrote delaunay triangulation for my own project in GDScript, and I know at least one other person did, too.
I wrote delaunay triangulation for my own project in GDScript, and I know at least one other person did, too.
It's about performance. I could write A* in GDScript too but I'd rather not wait 246 seconds to find a path from A to B (_that actually reminded me, a proper AStar to 2D should be implemented; having to calculate a 3rd distance that's useless doesn't sound very efficient, and breaks workflow since you have to convert Vector2 to Vector3. Plus in reasonably small maps calculating twenty A* paths takes 0.06s which is not great_). Wouldn't you agree? 馃槃
I believe this is suited to be a plugin (GDNative)
Isn't there a Geometry singleton already with a triangulate() function in it?
Isn't there a Geometry singleton already with a triangulate() function in it?
It's not Delaunay. Also it doesn't work very consistently. Also when it works it doesn't include all points. Basically it's pretty shit.
@Zylann: Geometry.triangulate() only works for convex polygons, also most delaunay implementations can work with inner points unlike this.
Should it be made available in Geometry singleton as triangulate_polygon_delaunay alongside triangulate_polygon? Perhaps an enum could be created for different types of triangulation, or a simple boolean.
@Xrayez I think a triangulate_delaunay would suffice. I mean there's just two types of triangulation, an enum would just confuse people.
Most helpful comment
It's about performance. I could write A* in GDScript too but I'd rather not wait 246 seconds to find a path from A to B (_that actually reminded me, a proper AStar to 2D should be implemented; having to calculate a 3rd distance that's useless doesn't sound very efficient, and breaks workflow since you have to convert Vector2 to Vector3. Plus in reasonably small maps calculating twenty A* paths takes 0.06s which is not great_). Wouldn't you agree? 馃槃