#### Archived

This topic is now archived and is closed to further replies.

# The differences between vectors and vertices... in code!

## Recommended Posts

For my project, I have a vertex class. I know that some people have vertex classes and some have vector classes, and some have both. And I also know that vectors and vertices are very different in math. But the thing is, they don''t look to different in code! Probably the biggest thing is that the x, y, and z specify a direction for vectors, not a position. Should I use the vertex class for vectors too? Or should I make a vector class? Thanks for your patience.

##### Share on other sites
well, the main thing isn''t definition programatically, but mathmatically. a vertex is a coordinate defined by x,y,z components. a vector is a direction. in 3d space it is defined again by x,y,z components. you can define them as the same thing, but they mean two different things.

My Homepage

##### Share on other sites
You shouldn''t ever need more than a single class for both concepts.

I use "Vector#" (replace # by how many dimensions it has (2 for me, 3 for you))

500

##### Share on other sites
i use Vector for the x, y, z thing, and only the x, y, z. then i use Vertex for things that go to the card, like a mesh vertex might look like:

struct CVertex
{
CVector Pos;
CVector Norm;
CColor Color;
CCoord uv1, uv2;
};

but a vector always is just x, y or x, y, z.

##### Share on other sites
One benefit of seperate classes is simply error checking. You can add two vectors together, but not two points. You can take the dot product and cross product of two vectors, but not two points. In many ways it is no differant than indentation. It isn''t strictly necessary, but decreases the likelyhood of an error.

##### Share on other sites
quote:

You can take the dot product and cross product of two vectors, but not two points

Yes, you can. A point is nothing but a vector from the origin. I use the same class for both vectors and points. I use the name ''vertex'' for a point containing additional information, such as normal and texture coords.

##### Share on other sites
Mathmatically, a vector is different than a vertex. You cannot take the dot product or cross product of a vertex, in the strictest sense. You can subtract vertices, the result of which would be a vector. You can use the same class for both, but it can be tough to keep track of which is which. I personally like to keep the two seperate. Vector would have the functions magnitude and normalize, as well as the +, -, dot, and cross operators (though the last two aren't overloaded operators in the code). Vertex would have the function homogenize and the - operator, and can be multiplied by matrices as well. I'd also suggest you use homogenous coordinate systems, i.e., x, y, z, and w. Perhaps the biggest advantage is that, if using homogenous coordinates, all affine transformations can be represented as matrix multiplications. This will save you work down the line, even though you're working in an extra dimension. The difference between a vector and a vertex in homogenous systems is that the w component of a vector is 0, and of a vertex is 1. This will be important as you perform transformations on both, as a vertex does not transform the same as a vector. For example, if you translate a vector, it should remain the same, whereas a vertex, obviously, should move. I'll leave the math up to you. If you just need a vertex and vector, and they aren't related to graphics at all, use 3 dimensions and combine the classes. If this is for a graphic course, though, i guarantee you'll find it easier to use 4 dimensions and seperate the two classes. anyhow, that's how i do it. Whatever floats your boat. Just please don't quote my entire post and give a line by line account of why i'm an idiot. I'm only trying to help.

[edited by - kdogg on March 7, 2003 1:24:47 AM]

##### Share on other sites
quote:
Original post by kdogg
Just please don''t quote my entire post and give a line by line account of why i''m an idiot. I''m only trying to help.

You didn''t capitalize your ''I''! BWahaahaha!! You are so foolish!!

just kidding

##### Share on other sites
quote:
Original post by Yann L
You can take the dot product and cross product of two vectors, but not two points
Yes, you can. A point is nothing but a vector from the origin. I use the same class for both vectors and points. I use the name ''vertex'' for a point containing additional information, such as normal and texture coords.

No, you can''t. Mathematically, a point is a combination of a vector and an origin. Dot- and cross-products are defined on vectors, but not on origins; hence, there''s no way to do it.

Homogeneous coordinates (the w being 0 for vectors and 1 for points) is a somewhat kludgey way of doing things, IMHO, but it serves as a good illustration of what you can and can''t do with points and vectors.

But... but that''s what HITLER would say!!

##### Share on other sites
quote:
Original post by Sneftel
No, you can't. Mathematically, a point is a combination of a vector and an origin. Dot- and cross-products are defined on vectors, but not on origins; hence, there's no way to do it.

Yes, of course there is, assuming that all your 3D points have a homogeneous coordinate of 1. This is always the case with standard geometry. Mathematically, a point is a combination of the origin and a vector. In practice however, the origin being (0,0,0,1), the point has exactly the same value as the vector defining it from the origin (if we ignore w, and we can do this in the case of world space geometry).

If you have two points, then their coordinates define a plane, in combination with the origin. Hence, P1 x P2 (crossproduct between point 1 and 2) will yield the normal of that plane. This is a speed optimization often used in computer graphics.

If you have two separate definitions for points and vectors, then conversions are needed, and that's a bad thing, if you're interested in performance. Mathematically, they might not be exactly the same, but in practice they are. Sacrifying performance for a purely theoretical concern (with absolutely no prectical relevance in this case) is definitely not a good idea.

Oh, and I know that some people don't like the idea of 'betraying' mathematical concepts. But that's the way it works. Have a look at vertex-shader shadow volume extrusion, for example: it achieves quick and accurate extrusion by defining a point with a w=0. That is mathematically impossible, but it works very well in practice.

PS: if you *really* need the distinction in the source, then use something like typedef vector3 point3. At least you won't lose performance that way. But keep in mind, that lots of advanced graphics effects will treat points as vectors and vice-versa. So your exact distinction will quickly become very fuzzy.

[edited by - Yann L on March 7, 2003 4:21:30 AM]

##### Share on other sites
yann, here i first time have to disagree. points and vectors are two entierly different things, and points cannot have crossproducts and similar things.

sure, most the time you only think about what it is, and always use vectors to represent points, but they _ARE_NOT_THE_SAME_. not at all, not interchangeable at all, they just happen to have to do a lot with eachother.

and if you define them right, as two district classes, you will btw not loose any performance:D

"take a look around" - limp bizkit

##### Share on other sites
All very interesting, but surely for computer graphics terms a vertex has a colour, texture co-ordinates, a normal or whatever as well as a position. When would you need a single vertex on it''s own, not related to any other object, that you start arguing whether or not to use vectors/vertices?

##### Share on other sites
quote:

sure, most the time you only think about what it is, and always use vectors to represent points, but they _ARE_NOT_THE_SAME_. not at all, not interchangeable at all, they just happen to have to do a lot with eachother.

There, you hit the nail on the head with this one sentence: "and always use vectors to represent points". Because this is exactly what a normal 3D engine does. Every point is an (unnormalised) vector from the origin. Mathematically, yes, a point is different, we don't disagree on that fact. But in a typical 3D engine, it simply doesn't matter, because you basically only use vectors. Or stated in other words: for all practical purposes: a point == a vector from the origin. I never encountered a situation in Euclidean tri-coordinate space (x, y, z) based CGI, where this assumption did not hold. Even if it is mathematically incorrect terminology. OTOH, taking this assumption for granted, can give you access to some nice optimizations.

quote:

and if you define them right, as two district classes, you will btw not loose any performance:D

Well, one time or another, you'll have to interchange them. And you will lose performance at this point.

Points and vectors in a 3D engine (not mathematically) are a little like light: sometimes it's particles, sometimes it's a wave Limits are fuzzy, and definitions are too. You just named it above: is a vertex of a triangle a Cartesian point, or is it a vector from the origin ? How do you define it ? Both ways are possible.

But again, no need to think too hard about it, because as long as you don't use the w coordinate (which you shouldn't on standard geometry, at least until the projection matrix comes), it simply doesn't matter and will only overcomplexify things.

Oh, and out of curiosity: do you actually use two different types for points and vectors ?

[edited by - Yann L on March 7, 2003 7:18:49 AM]

##### Share on other sites
It all really depends on what your program does. If you''re just using openGL, you can use cartesian coordinants and probably get away with combining vectors and vertices into the same class. If you''re working on a lower level and trying to implement your own matrix stack, i think your code will be much simplified if you use homogenous coordinates and seperate classes. Before you ask why anyone would do that, A) it''s fun and can teach you a lot about how openGL (or D3d) works making you a better programmer and B) there are transformations that you might want to use that arent'' implemented by openGL.

I don''t see where you do excessive conversion between vectors and vertices. A vertex is a point in space and a vector is a direction. Three points define a plane, not two. And it''s very rare that a random plane in your program will contain the origin. If you have three non colinear points, P1, P2, P3, the normal vector will be (P2-P1) X (P3-P1). There is no vertex -> vector conversion there. Maybe i''m just a math purist. In graphics, you have to take liberties with how the natural world works. Look at the phong reflections model. Looks good enough, but really has little to do with what illuminates objects in reality. You approximate curves with flat polygons. And so on. But, if you start taking liberties with math, it usually catches up with you somewhere down the line.

I feel like this is calculus 101 here. You''re learning about vertices and vectors and they seem the same and you don''t see why you can''t combine them. If you''re gonna drop out after calc 102, it doesn''t matter, but if you aren''t clear on what the difference is, you''re gonna hit a brick wall in calc 666. You''re the only one who knows what your program is gonna do. If it''ll never be super advanced, you can go either way from here. If you want to go really deep into computer graphics, though, one of the roads is a dead end.

##### Share on other sites
Look, it''s very simple. For the purposes of 3D graphics we define a vertex as being a vector where its tail is at the origin. This allows you to do several things, most notably combining the vertex and the vector into the same data structure. In this way you can take the dot or cross product of a "point", but it clearly has no meaning taken this way. It''s just a meaningless piece of math. If you use them as vectors, however, all the operations actually mean something geometrically .

Being "able" to take a dot or cross product is a case of syntax. It''s whether or not your result means anything that matters.

##### Share on other sites
*sigh*

Let me put it into simple words:

* Mathematically, a point is not a vector. OK, we seem to agree on this.

* In practice, ie. when coding a 3D engine, it does not matter . We do not use points in 3D engines, because they do not mean anything in this context . We use vectors and vertices. Note the difference.

* Treating a point as a vector from the origin can be useful for lots of advanced effects: cubemap based HDRI lighting (needs realtime vertex normals measured from the origin), shadow volume extrusion (makes a point with a mathematically invalid homogeneous coordinate), etc. Those effects work in practice , look very good, and unfortunately violate a mathematical definition in favour of performance. Who cares ?

* Introducing two different types (points and vectors), only to satisfy a mathematical concept that has no relevance to the context it operates in, will only make things unnecessarily complex, without any benefit.

* Depending on the context, a vertex can be seen as either a point, or a vector. The same vertex. It's only logical to use the same type for both.

So, if you are writing a technical paper about some geometrical algorithm, then you should make the distinction. But when coding a 3D engine, then it's just a waste of time.

Use accurate mathematical terminology where it makes sense. Eg. when designing an algorithm for eg. a Metropolis photon tracer using Monte Carlo stochastic walks (say hello to 13-dimensional differential equations), then you better stick to it. But when it simply does not make sense, it is just a waste of time and brain power, that you could use on something more valuable instead.

[edited by - Yann L on March 7, 2003 3:57:29 PM]

##### Share on other sites
struct Vector3
{
float x,y,z;
}
Vector3 vector;
Vector3 vertex;

Problem solved?

This topic has been covered how many times in the last few weeks? If you can''t follow your own code, or need someone else to follow it, either comment it or name them properly.
Personally, I don''t name my verticies "Vector3 vectors[ someNumber ]" when they''re supposed to be verticies *rolls eyes*.

##### Share on other sites
quote:

Problem solved?

Yes. Problem solved.

##### Share on other sites
You guys should really get out more.

##### Share on other sites
i just was out with my girlfriend.. and i was out yesterday, and the days before.. so what? :D

"take a look around" - limp bizkit

##### Share on other sites
GameDev goers love to argue semantics

##### Share on other sites
quote:
Original post by Yann L
[quote]
and if you define them right, as two district classes, you will btw not loose any performance:D

Well, one time or another, you''ll have to interchange them. And you will lose performance at this point.

I assume you mean runtime performance. Which isn''t true, if you have a reasonable compiler, and choose a reasonsable representation.

For example, the following code exhibits no runtime performance penalty for conversion between Point and Vertex classes when compiled under MSVC .NET with the /O2 option.

  #include <new>class Point;class Vector {  private:    float _x, _y, _z;  public:    Vector()  { /* anyone placing statements in here will                   be flogged with a wet noodle */ }     ~Vector() { /* anyone placing statements in here will                   be flogged with a wet noodle */ }    // Vector(const Vector &) defined by compiler exactly right    // operator=(const Vector &) defined by compiler exactly right    // anyone defining a conversion operator to Point or a    //   non-explicit constructor taking a Point object will be    //   flogged with a wet noodle    Point & AsPoint();    const Point & AsPoint() const;};class Point {  private:    Vector _storage;  public:    Point() {  /* anyone placing statements in here will                   be flogged with a wet noodle */ }    ~Point() { /* anyone placing statements in here will                   be flogged with a wet noodle */ }    // Point(const Point &) defined by compiler exactly right    // operator=(const Point &) defined by compiler exactly right    // anyone defining a conversion operator to Vector or a    //   non-explicit constructor taking a Vector object will be    //   flogged with a wet noodle    Vector & AsVector() {      return _storage;    }    const Vector & AsVector() const {      return _storage;    }};inline Point & Vector::AsPoint() {  // strange enough to make a maintnence programmer think twice before messing with it  return *(new ((void *)this) Point); // glorified cast}inline const Point & Vector::AsPoint() const {  // strange enough to make a maintnence programmer think twice before messing with it  return *(new ((void *)this) Point); // glorified cast}// example driver code, take a look at the disassembly herevoid FuncTakingPoint(Point &);void FuncTakingVector(Vector &);void TestingFunc(void) {  Point p;  Vector v;  FuncTakingPoint(p);  FuncTakingPoint(v.AsPoint());  // yup v.AsPoint() turns into a simple lea  FuncTakingVector(p.AsVector()); // again just one lea  FuncTakingVector(v);}

##### Share on other sites
OK, point for you (although I haven''t compiled/profiled it, but I''ll trust you on this one ). But still, I really don''t see the point of doing that. Code bloat, even if admittedly a small one. Why add a useless functionality, only to satisfy an abstract mathematical paradigm without any relevance to the general concept ? what good for is a distinct representation, if you convert between both anyway ? Mathematical paradigms are broken every five seconds in computer graphics, get over it.

Oh well, yeah, arguing semantics (again). I''m personally very happy with using a single representation, as it makes the code much easier to read, avoids confusion (IMO), and my engine works very well with that concept (even on effects using highly complex mathematical and geometrical relationships). But if you''d like a distinct separation, whatever floats your boat.

##### Share on other sites
why not just assume the first point in a ''vector'' to be 0, 0, 0? it saves memory and processing time, plus you can using them directly in graphics vertexes without having to assing them to a different type.

##### Share on other sites
I''m thinking this topic has gone on long enough. The discussion is a moot point--it''s clearly not a mathematical consideration but a practical one.

• ### Forum Statistics

• Total Topics
628375
• Total Posts
2982319

• 10
• 9
• 14
• 24
• 11