JOML Migration

[OrcHound]

This thread is dedicated to our endeavor to migrate the engine from using TeraMath to using the joml math library.

I'm creating this thread in hopes we have central point for collecting important data and decisions, more organized and digestable than Discord. (I'm not sure if that makes sense yet, but we'll see)

To begin I want to point at my PR, which is an already working complete joml port:

https://github.com/MovingBlocks/Terasology/pull/3900

Even if it won't be merged for being to big, it can be used as a reference for porting smaller parts of the engine at a time. ALSO, please review the comments I added, some point to potential problems within the current state of develop.

Attached is a list of all modules that would be affected in case we migrate completely (as done in my fork).
The problems aren't always the same, so it would technically be possible to merge something that only breaks compatibility with some of the modules.

 

[OrcHound]

Hey,
our current approach in migrating to joml is to provide an additional joml API while keeping and deprecating the TeraMath API.

How do we handle simple TeraMath type returning getters?
TeraMathVector getPosition()

There are 3 approaches I can think of:

1. provide an alternative getter supporting joml along the lines of JomlVector getJomlPosition().
   This getter would need to be deprecated in round 2 when the TeraMath getter can finally be converted into a joml getter. API usage would need to be adjusted twice that way, which I consider to be pretty ugly.
2. implement the new getter using a destination parameter like this: void getPosition(JomlVector dest).
   That would be my preferred solution, but it might make the API inconsistent, since some values would be simply returned while others would require a destination parameter.
3. screw API compatibility for these cases, do a hard migration to a joml getter and check how many modules would be affected.

Opinions? Decisions?

 

[Michael]

I think the strategy would be some combination of all of that. some classes are much more used then others to the point where swapping everything across the entire project would be prone to a lot of bugs where creating a new method and deprecating the old one would be less likely to cause problems and is also easier to test and verify. some classes are fairly small where a class will have a couple dependencies and in that case its easier to just do a hard replace.