vector2d and position2d

CaptainPants · Post by **CaptainPants** » Sun Jul 15, 2007 2:29 pm

Is there a good reason for the existence of both vector2d and position2d when vector2d could fulfill all the task that position2d it used for? (other than backwards compatibility)
After all, position2d is effectively just a vector without some of the useful functions.

-- also they theoretically have inverted y coordinates

teh_fabs · Post by **teh_fabs** » Sun Jul 15, 2007 9:17 pm

Perhaps a position2d uses less RAM than a vector3d?

Kimundi · Post by **Kimundi** » Sun Jul 15, 2007 11:22 pm

Of course, because Vector3d holds three values, but we talking about Vector2d

But I agree that Vector and Position 2D should be combined.
Edit: After looking at the SVN I really saw no difference between them except geometrical functions in Vector2d

zeno60 · Post by **zeno60** » Sun Jul 15, 2007 11:54 pm

Yes, looking at both vector2d and position2d from a source standpoint, they are similar, but from a geometrical standpoint, a vector and position are very different. The position2d which is basically a point, has a location, but vectors do not, they have a direction and magnitude. It would be confusing to just combine both when you begin to deal with 3d mathematics and want to distinguish between points and vectors in your code.

vitek · Post by **vitek** » Mon Jul 16, 2007 1:05 am

If there is a position2d and vector2d, then why not a position3d? Also, for ease of use, subtracting one position2d from another should give you a vector2d, and adding a position2d and a vector2d should give you a position2d. I don't mind having two seperate classes, one for a position and one for a direction, but if they are going to be seperate, then they have to work together for some operations.

When it comes down to it, the position2d is really used mostly by the gui framework and the vector2d isn't really used for anything.

Travis

bitplane · Post by **bitplane** » Mon Jul 16, 2007 1:45 pm

I personally would prefer to merge them, having two different classes to hold the same sort of information seems wrong.
Also as Travis said, having position2d without position3d is inconsistent. vector3ds are used for positions everywhere anyway, so I don't see any real reason why it shouldn't be the same for the 2d stuff.

CaptainPants · Post by **CaptainPants** » Mon Jul 16, 2007 6:00 pm

Is there somewhere to post this suggestion? its not really a 'bug' as such, it just appears to be a bit of a redundancy.

The main conceptual difference I can see is that a vector2d is a point in 2d space and generally would have the y coordinates increasing in an upwards direction.
whereas position2d (being basically a screen position) has y coordinates increasing down the screen.

JonLT · Post by **JonLT** » Mon Jul 16, 2007 6:40 pm

Is it at all mathematically defined how to add together to positions? Or to add a vector to a position (would the position then grow in to some quantity?

Or the other way around: Add a position to a vector, would the vector then split in to two vectors to include the position? )

In my world a position is just a point in space. You can calculate the distance between two points, and thats about it. I don't understand the operators in the position2d class. What does it mean to subtract/add/multiply two points? I understand that you can add somthing to a dimension of a point, but adding a point to a point

My surggestion would be to use origin vectors for positioning (like with vector3d and setPosition)

arras · Post by **arras** » Tue Jul 17, 2007 8:58 am

No position is not point. Position are coordinates of that point, not point itself. Therefore you can add or substract and make other operations on position. But yes, there is not much diference between position and vector here.

Point is something which have no dimensions, therefore you can not add or substract two points. Position on the other hand is something you can represent by values bigger than zero.

BlindSide · Post by **BlindSide** » Tue Jul 17, 2007 10:10 am

Actually the fact that Irrlicht3D's vectors (Ogre3D's too I think) are actually POINTs in 3D space and not a direction and magnitude is kinda weird anyway. But hell we're all so used to it like this that I wouldnt have it any other way, who needs a magnitude anyway?

Then again we can use vector3df to DEFINE a direction and magnitude because its not a unit vector so the length of the sides can be used to convey much information...

Ok I am going around in circles here, but yeah scrapping position2d for vector2d is a good idea I was thinking about it the other day. There is also dimension2d that is just as pointless. Sure from a conceptual standpoint a dimension is different, but that is inconsistant with the fact that we use vector3df for everything in 3D like scale, rotation, even dimensions, etc... So why not also use vector2d for 2D dimensions? (And scales and rotation if someone is kind enough to stick this into the gui system

)

Cheers

hybrid · Post by **hybrid** » Tue Jul 17, 2007 12:58 pm

But the different y axis will prevent this. We cannot have vector2d with y increasing to the bottom and vector3d increasing to the top. And writing GUIs in the opposite way would be strange as well. So I guess the best way is to properly separate them (if they are not, yet) and enhance the usability of those elements. If there's a benefit we could derive position2d from vector2d or so, but I doubt there is.

bitplane · Post by **bitplane** » Tue Jul 17, 2007 3:34 pm

oops, yes good point, that didn't even occur to me!

vitek · Post by **vitek** » Tue Jul 17, 2007 3:43 pm

Actually the fact that Irrlicht3D's vectors are actually POINTs in 3D space and not a direction and magnitude is kinda weird anyway.

Not really. A vector can represent a position in 3d space or a direction/magnitude. Lots of engines combine these two concepts because they are so closely related.

We cannot have vector2d with y increasing to the bottom and vector3d increasing to the top.

There is nothing about the definition of a vector2d that implies the Y direction is up or down. The vector2d<T>::y member is just a quantity, and the interpretation is up to the user. Conceptually increasing Y in a GUI usually means moving down the screen, but you could just as easily treat it as moving up.

Travis

CaptainPants · Post by **CaptainPants** » Tue Jul 17, 2007 3:46 pm

I don't think that the conceptual difference in the directions of the axes actually make a difference in most cases, and you generally wouldn't use the functions that are affected in the gui anyway.

Also, vector2d has --
getAngle() and getAngleTrig()
which handle both types of y axis. (getAngle() giving expected results for y axis increasing to the top)

As far as I can tell, the only real problem (and it may be a serious one) is that it seems slightly odd using the same data structure to represent screen coordinates as well as to represent positions in space.

also--
getAngle() and getAngleTrig() despite being almost exactly the same are written a bit differently, getAngle() seems to have a bunch of unnecessary conditions. They have festy ifs...

Kimundi · Post by **Kimundi** » Tue Jul 17, 2007 11:22 pm

vitek wrote:
Actually the fact that Irrlicht3D's vectors are actually POINTs in 3D space and not a direction and magnitude is kinda weird anyway.
Not really. A vector can represent a position in 3d space or a direction/magnitude. Lots of engines combine these two concepts because they are so closely related.

We cannot have vector2d with y increasing to the bottom and vector3d increasing to the top.
There is nothing about the definition of a vector2d that implies the Y direction is up or down. The vector2d<T>::y member is just a quantity, and the interpretation is up to the user. Conceptually increasing Y in a GUI usually means moving down the screen, but you could just as easily treat it as moving up.

Travis

Exactly was I thought!
Position2d and Vector2d contain the same Data, so why seperating them?
Vector3d is used as Dimension3d and Position3d , so why not Vector2d?
And the Class don't need to know if its y value is upside down or not, just the Code which is using it!