Implement GPU-compatible transformations with ORANGE

[sethrj]

I'm having second thoughts about declaring separate Trans{former,lator}{Down,Up} classes. Maybe we should just have a single class with down(), up(), etc.; and include utility functions (such as "calc_inverse" for the transformation) as part of the class definition...

[sethrj]

@elliottbiondo I'd appreciate a quick look and feedback for this.

[elliottbiondo]

Based on only what you have committed here, I don't fully understand what you are proposing, especially since you haven't implemented the translation + rotation case yet.

My best guess: we could easily have one class constructed like: Transformer(Real3 translation, Matrix rot) with up(Real3 point) and down(Real3 point) methods. In the translation-only case, the code has to check that there there is no rotation, or perform rotation as a no-op. But since this is done so frequently in the code, you want to use template metaprogramming to get around this?

[sethrj]

@elliottbiondo Yes, not only for the extra checks but also for the extra storage. Also having them as two separate types makes it much easier and more elegant to apply transformations to surfaces and shapes.

[sethrj]

@elliottbiondo I pushed the changes I'd neglected before. Most important properties we need:

• Apply one transform to another (super nice if we have separate classes with and without rotation)
• Apply a transform up and down to a position
• Apply a transform up and down to a direction (rotate only, nullop for translation)
• Apply a transform to a surface (if we have translation and trans+rot as a separate class, the surface class types can be determined at compile time)

[elliottbiondo]

@sethrj this all looks fine to me in terms of a draft. My only comment: is it necessary to have separate TransfromTrans{former, later} classes, or could these just be methods on Transformation and Translation classes? In the very least, these should be renamed TransfromTrans{formation, lation} to match the names.

[sethrj]

I think you'll see what I'm getting at when I submit the next chained pull requests: I'm defining function-like classes that when applied to a surface, return the transformed/translated surface type (type dependent input, type dependent output); and same thing for both translations and transformations. So the TT classes are translator/transformer rather than translation/transformation.

[sethrj]

@elliottbiondo I gave this a quick look over and it's ready for review! (I'm deferring the transform transformers to a later PR.)

[elliottbiondo]

Looks good @sethrj, just a few minor comments