Inheritance and polymorphysm conundrum

Question

Okay, I'm trying to write something resembling a 3D game engine. That means I have to deal with matrix transformations and similar stuff.

For any of you who don't know, you need to use three basic matrices to define where a vertex will be positioned on the screen: projection matrix, view matrix and entity matrix.

View matrix moves the camera, while the entity matrix moves an entity in the world. We don't care about projection matrix here. Since the camera doesn't exist, it's simulated by moving the whole scene in inverse way (negate translation vectors and inverse rotation quaternions).

Given their similarity, I wanted to write a base class to act as an interface and write two implementations that would deal with each of the matrices, entity one using the values provided, and view one inverting them appropriately. That way the client can move the camera more intuitively leaving the inversion conundrum to be dealt internally. It also allows me to write methods that operate on either of matrix types.

But there are two things that oppose each other, making achieving this a bit difficulty (or at least messy).

Entity matrix has three components: position, rotation and scale. The view matrix only has the first two - it makes no sense to scale the camera. I could code the first two components into the base class and have the scale be specific for the entity matrix.

NOTE: When I say matrix type, or refer to a matrix, I actually mean a custom type that holds the components I can create the matrix out of, not a matrix object.

But I want to write another class that would hold a single method that would take in a matrix and transform it based on some rules (I'd have an abstract interface and client could implement any number of methods which somehow transform the object - move/rotate object based on player input, move it along a specific curve, rotate around a point, etc). You can see that this methods could be executed on either entities or camera(s). Making the base class makes it possible - I can pass the base matrix type to the method and have it return the transformed matrix, regardless of it's concrete type.

However, if I put scale component in entity matrix, I won't be able to use it in that method since it will take the base type that will not have it defined.

If I put scale in the base type, it makes the whole thing a bit dirty, since I can now scale the view matrix. In this particular case, scaling the view matrix changes nothing and nothing bad happens due to the way I construct the actual matrix from the data, it just makes me feel bad and dirty.

But imagine this same situation in different environment. Doing this there might cause your computer to spit fire and dragons to come out of your display and eat your face off.

My question isn't about my specific case (where I can ignore it, but feel dirty and bad), but a generic one (with dragons and fire). How can I achieve what I want without having a dragon chew my face off?

Answer 1

You're using the wrong tool here, as is often the case when people try to use inheritance-based polymorphism on basic types.

For example, a view matrix is first and foremost a matrix. The fact that you use it for a camera is about the meaning of its value, not about what you can do with it. To give it a separate type from a regular matrix is simply not a reasonable design. It limits your ability to do things that you might ultimately want to do. The same goes for the perspective matrix.

So there is no need for them to have a distinct type from a "matrix" type. What makes them distinct is their values, not the type itself.

That is, consider if you had a speed type. You wouldn't make separate "car speed" and "truck speed" types; cars and trucks would simply have a speed. A speed is a "car speed" because the speed came from a car.

The same goes here. A "view matrix" is a matrix that gets used for the camera part of the transformation.

Your definition of "entity matrix" as having "three components: position, rotation and scale" (RPS) represents something that is actually distinct from a traditional matrix. What you have isn't a matrix at all; it is a specific kind of transformation. That's separate from the concept of a "matrix".

You can use the transformation to generate a matrix, but the transformation is not a matrix. You cannot multiply an RPS transformation by an arbitrary 4x4 matrix and still have it be an RPS transformation. Well, you could, but doing so would require performing singular-value-decomposition on the resulting matrix in order to get your RPS values back. And that can fail if the arbitrary matrix included sheering or projection properties.

Since an RPS transformation is not a matrix, it should not inherit from a matrix type. It should be its own type with its own operations. You convert it into a matrix as needed, but it is not the same thing as a matrix.

Now, I have had need of a special type that represents an RPS transformation, but can also be combined with a matrix. Basically, what I did was store a variant<RPS, matrix>. So the object could either be an RPS transformation or a standard 4x4 matrix.

If it was in decomposed RPS form, then you could affect the position, orientation, or scale of the decomposed form with decomposed operations. But if you tried to combine it with a 4x4 matrix, then it switched to the matrix form. Once that happened, you couldn't affect the RPS components directly; you had to use matrix operations on it.

But note that this type was not a "matrix". It was a composable transformation, a distinct type that had some inter-operability with matrices. But you could not reasonably replace matrix with composable transform or vice-versa. So there was no need to use inheritance.