feat(JOML): migrate polyworlds

[pollend]

This is a complete migration of Polyworlds. I moved in line2f and Poly2f in from termath and we can work out if we want to move them to joml-ext. not sure how it would fit in with the rest of the stuff though. we would basically be adding a winged edge data structure to joml-ext. not sure how that fits in with the rest of code current in joml-ext.

Depends On

• feat(geom): create Rectangled/f from point (and set to point) MovingBlocks/joml-ext#16
• feat(JOML): migrate BresenhamCollectorVisitor CommonWorld#6

Required By

• feat(JOML): migrate with Polyworld Lost#33

[Cervator]

Looks fine to me and tests out. Two remaining items:

• Line2f and Poly2f should probably be moved to joml-geom particularly if they came from TeraMath anyway
• There are 3 probably simple unit test failures

Additional discussion on a final tiny use of stuff from CommonWorld happened after I did my review and testing

[jdrueckert]

* `Line2f ` and `Poly2f` should probably be moved to `joml-geom` particularly if they came from TeraMath anyway

@Cervator These seem to me rather PolyWorld specific. They are part of the delaunay package which includes even more classes used for the triangulation logic, e.g. Vertex, which we afaik don't use widely.
If we were to perceive Line2f and Poly2f as joml primitives (from my point of view they're not), we IMO would need to add a whole bunch more to make the level of structures we see as joml primitives consistent.

[Cervator]

These seem to me rather PolyWorld specific

That was my thought initially, yup, with PolyWorld just being the library module for poly things related to world gen. Then Michael mentioned they actually came from TeraMath, which threw me off and made me wonder if they were more "generic" and should be in a literal lib rather than a library module. If we don't expect to use them anywhere else then PolyWorld makes sense 👍 Then that just makes me wonder why they were in TeraMath in the first place, but then we probably won't win any awards for being super organized :-)

[jdrueckert]

Where do these values come from?

[pollend]

I didn't want the dependency to Sector so the sector area is defined her and allocated as a BlockRegion

https://github.com/Terasology/CommonWorld/blob/93cc9918d28b29d9c64e3a8d884edcbc82c6dccb/src/main/java/org/terasology/commonworld/Sector.java#L33

[skaldarnar]

@Cervator I would not throw this into joml-ext right away, but only after careful consideration (let's try to keep that lib high quality instead of dumping things in there).

We already have LineSegmentf which is the same thing in 3D, missing some utility functions.

I'll create a ticket on https://github.com/MovingBlocks/joml-ext to remind us about merging the feature set of this class and the LineSegment class we adopted from JOML, and probably provide 2D variants for it. (👉 MovingBlocks/joml-ext#14)

[skaldarnar]

I might be worth to move this to joml-geom at some point - ideally, when we know (or can think of) good use cases where this class would be used.

Would definitely put that on the backlog, though.

We'll take care of moving things to joml-ext later, as discussed.