Separating color from vector struct

[kwannoel]

Currently Color is an enum value of VectorType.

Perhaps we can model these separately since a Color is not a vector.

The book this project follows models it this way as well, maybe there's a good reason which I am unaware of.

[advaypal]

From tutorial:

"Almost all graphics programs have some class(es) for storing geometric vectors and colors. In many systems these vectors are 4D (3D plus a homogeneous coordinate for geometry, and RGB plus an alpha transparency channel for colors). For our purposes, three coordinates suffices. We’ll use the same class vec3 for colors, locations, directions, offsets, whatever. Some people don’t like this because it doesn’t prevent you from doing something silly, like adding a color to a location. They have a good point, but we’re going to always take the “less code” route when not obviously wrong. In spite of this, we do declare two aliases for vec3: point3 and color. Since these two types are just aliases for vec3, you won't get warnings if you pass a color to a function expecting a point3, for example. We use them only to clarify intent and use."

We could certainly model it differently

[kwannoel]

Down the road if we choose to separate these:

Color can use record fields of u8.

Gives us compile time assurance for Color values

[advaypal]

FYI I've moved it out of the enum and used type aliasing instead because a vector can be more than just a Point/Color, and I wasn't using the VectorType enum anyway.

I think one nice way of doing this would be to have a separate struct for Color, and a trait which both Vector and Color share. The trait can have all the normal vector methods, but write_color can be implemented just for Color