adbrown85 / gloop

Lightweight C++ wrapper for OpenGL
BSD 2-Clause "Simplified" License
1 stars 0 forks source link

Add 3 and 4 component vector implementations #1

Closed adbrown85 closed 12 years ago

adbrown85 commented 12 years ago

Since OpenGL no longer has math built in, we need to have some vector implementations. There should at least be three and four component versions.

It would be nice to have them match the vectors in GLSL as much as possible. Therefore Vec3 and Vec4 seem to make sense for the names. I'm not sure if they should be capitalized or not though? Also, to make things easy for now we won't worry about doubles. If we think we really need doubles in the future we can make something like Vec3d or Vec4d or even go template-based.

I would like to see the implementations have all the usual vector functions as top-level methods.

It would also be nice to have some non-standard ones for convenience.

adbrown85 commented 12 years ago

Nevermind, let's just go with doubles only.

adbrown85 commented 12 years ago

Maybe hold off on direction and distance for now.

adbrown85 commented 12 years ago

Cross product is really only defined for three-component vectors, so that might be an issue...

I think it will just force the user to make a temporary here or there. Much like GLSL, we've provided a Vec4 constructor that takes a Vec3 and a fourth parameter, so they can use Vec3 when they need to do cross products, and then just create a quick Vec4 with a 0 for the fourth parameter if they need to transform it. Or just use a Mat3 to do the transformations instead, since the vector will ignore translations anyway.

But this is kind of a good case for switching to dedicated classes for points and vectors, i.e. Point3D and Vector3D. When working with vectors, you could then do everything without creating temporary objects, since Matrix3D would know what to do for both, and you would still have cross product of course. The problem is it's difficult to define what gets returned when you do operations. For instance, subtracting two points should probably actually return a vector. Arguably that is probably actually what should happen, but in the general case it's hard to say users won't run into issues where they can't do something they want. We would have to sit down and think how it would work for every single operation.

adbrown85 commented 12 years ago

This is probably all we would need if we went with the dedicated points and vectors:

Point3D
  operator-(Point3D) : Vector3D
  operator+(Vector3D) : Point3D

Vector3D
  operator+(Vector3D) : Vector3D
  operator-(Vector3D) : Vector3D
  cross(Vector3D, Vector3D) : Vector3D
  dot(Vector3D, Vector3D) : double
  normalize(Vector3D) : Vector3D
  length(Vector3D) : double

Matrix3D
  operator*(Matrix3D) : Matrix3D
  operator*(Vector3D) : Vector3D
  operator*(Point3D) : Point3D
  inverse(Matrix3D) : Matrix3D
  transpose(Matrix3D) : Matrix3D
adbrown85 commented 12 years ago

Unfortunately the real killer of this idea is that we can't assume that points and vectors have fixed homogeneous coordinates once we start working with perspective matrices... And a perspective matrix doesn't have a [0,0,0,1] in its last row, so Matrix3D would start to fall apart with that too.

The idea of having dedicated point and vector classes is still really nice when you're working in just model and view space, but it's not general enough to include by itself, which then means we would have two different classes for each thing. We'll just have to stick with what we've got and make sure we use the right versions where applicable.

adbrown85 commented 12 years ago

Maybe add a toVec3 converter in Vec4 to make going back and forth easier.