"Math" vectors and "lines": How to approach the difference?

Newbie & Debugging Questions
#1

Hi everybody! First time poster and rookie programmer over here. I guess I have a silly question because I haven´t found much info googeling it. :slight_smile:

I´ve been reading up on vectors for a while and I´m getting more and more ideas for their uses. I just finished a SAT implementation an hour ago, and this raised a few questions about how to distinguish between mathematical vectors and ”line” vectors, the kind you actually draw on screen or use for collision detection? I´m having a hard time realising how to actually think about this. What classes to have, how they should be designed and relate… When I started out with game programming, I never thought this would be a problem. :slight_smile:

So, if you do separate the vector types, how do you organize your classes and how do you create polygon shapes? Do you save a ”math” vector for every line in a rect for use in collision detection, do you create rects by using lines (for easier conversion to a vector), do you extract vectors by using the points in a rect? Am I overthinking this…? ???

Do you have separate classes for math vectors and ”lines”, or do you bundel a ”line” class with a render() method and a dotProduct() method?

A mathematical vector is supposed to have only magnitude and direction? Is this concept of any use in game programming or do you keep an origin with your vector?

So to sum up: what´s a good approach to 1) managing ”math” vector and pure ”lines” and 2) a good object orienteted approach to managing polygons. I´m mostly after ”concept”, but if it helps I´m starting out 2d-style with LWJGL.

Thank you!

#2

A vector is just a 1xn or nx1 matrix where n > 1. Whether it represents a point relative to the origin or a direction or something else entirely is strictly about how you interpret it.

If you draw from a known origin, a vector is enough to describe a single line segment (or ray if you ignore the magnitude), so a vector is exactly what you’d use if you were to need a ray or something describing a line such as an axis. For other graphics operations, chances are you’re going to draw segments though, so you’d need both start and end points.

It’s not very common to ever need a separate class for individual lines, since it’s such a simple operation on two points, but it all depends on your app. What’s certain is you’re not likely to see graphical operations supported on Vector classes directly. Any vector class is going to have a dotProduct method (often just called “dot”), but you’ll never see a render method on the same class as the math class.

#3

When designing a rect class for example, do you save each point in the shape? I guess this is easier when dealing with vectors, but I´ve seen a lot of code with just an origin and a delta value, or “width” and “height” if you may. Of course it´s no sweat calculating the separate verticies from these values, but like I said, I´d really like to get my head around what the general concensus is. :slight_smile:

And what to do with a vectors origin? If I have a vector from a vertex, they are conceptually separated, but is there a reason (convenience or other) to actually save the origin in a vector class? And the same with “angle”: you can calculate it, but is it worth keeping angle from the vectors origin?

Hmm, it seems that what I´m really wondering is: What variables to keep in a polygon/rect class and what variables to keep in a vector class. :slight_smile:

#4

I’ve seen codebases (both Java and C++) which attempt to distinguish between (mathematical) vectors, points and tuples. Usually with some assumptions that a vector has an (implicit or explicit) w of 0, and points a w of 1.

While I can appreciate the angle they’re coming from, frankly it just makes things awkward and wordy. Code that should be one or two lines ends up being bloated with lots of unnecessary conversion from Tuple3 to Vector3 to Point3 and back again. It’s much easier (and saner) to have a Vector3 class (and maybe a Vector2 and Vector4).

Axeman: As for polygon’s internals representation - who cares? It could be an ArrayList or it could just be two float[] arrays. It should be an internal detail that users of the class don’t need to care about, so do the simplest thing first and change it later if you need to.

#5

javax.vecmath (part of java3d) is one of those codebases that distinguishes between various types of tuples, but it does it just about perfectly: Point, Color, Normal, Vector are all subclasses of Tuple, so if you need to manipulate them as collections of values, you’re perfectly free to do so, but if you choose the specific subclass, you’re still prevented from mixing up points and colors by accident.

#6

Heh, that’s funny - I’d say Java3d is exactly how not to do it. It’s completely over-engineered and unwieldy to use. Often you do want to treat something as a point at one moment and then a vector at the next, and the conversions are tedious boilerplate that obscures whatever calculation you’re trying to do.

Not to mention the horrible object churn due to all the temporary objects (you only have to look at any j3d memory graph to see how much crap it produces), and the hideousness of having inheritance on such a basic type. Yes, I’m sure people are going to insist that with a modern VM that those things are ‘nearly free’, but nearly is not the same thing as completely free, and you just don’t want that kind of over-engineered crap clogging up what should be a simple vector type.

#7

Java3D is overengineered, javax.vecmath is not. It’s entirely possible that one size doesn’t fit all, so if you really do need to take the distance between two lime green surface normals, strong typing might not be for you.

#8

Glsl do it right. vec4 is what ever you want it to be and that just works.

#9

Hell yes. Language support for swizzling is great.

#10

Thank you for the advice. I think I´ll stick with a vector and a point class and just see where it takes me. I´m old enough to know that you can´t make it perfect the first time and you learn by making mistakes. :slight_smile:

Regarding polygon internals, I agree with what you are saying. The “user” shouldn´t be bothered with that. But I was more interested in what information to keep in a class, like if it´s enough with just <x,y> in a vector class , or if it´s worth having “angle” and “origin <x,y>” also? These things can of course be calculated if a vector is connected to a vertex for example, but is there something to gain by having this in a vector class? It´s interesting to hear what you guys with experience have to say. I have none. :slight_smile:

#11

Polygons are usually stored simply as lists of vertices. Angles are irrelevant, they’re easily computed for any three points. java.awt.Polygon stores those vertices as separate arrays for x and y as an optimization, but logically you still think of it as a list of vertices (and java.awt.Polygon is still horribly slow unfortunately).

The best way to find out how things are usually implemented is to just pull up the source.

#12

Excellent! magnitude and direction…NOT length and direction. Remembering that will be handy for higher level mathematics.

sproingie gives the linear (matrix) algebra perspective of a vector. Another is that a vector is a one dimension subspace. Both notions are handy. WRT to coding, I prefer the whatever extends tuple style because you can abuse the mathematics when you want and at the same time have a concrete notion the the actual mathematical type (or concept) involved, but that’s simply a matter of preference.

WRT: Lines and line segments, these can be defined is numerous different ways and different representation will better at a given set of tasks.

WRT: Shader like syntax. Hopefully when/if we get structs, then they’ll expose some stuff like this.