Closed davesmith00000 closed 6 days ago
I'm leaning towards the latter with some extension methods to aide conversion.
I've had a go and the implementation sucks and is quite spectacularly unfriendly to use. I think I'm going to keep it as-is and just recommend sticking with UV types in the examples.
This works, but I'm still thinking about what I've ended up doing here a bit.
I've realised (as a consequence of this work, wasn't the point of the PR) that you can now use one case class to define the data structure for both the Indigo and Ultraviolet side of passing data from engine to shader. The catch is that your definition must eventually use the few UV types we support for UBOs.
This means that either we allow all the types we can support (as-is, such as
Radians
) but the user has to know they need two different case classes (class 1 hasangle: Radians
and class 2angle: Float
), or we reduce support down to the 5 acceptable types and they get an error... but at least it's obvious when there's a problem.I'm leaning towards the latter with some extension methods to aide conversion.