Java-Gaming.org Hi !
 Featured games (83) games approved by the League of Dukes Games in Showcase (581) Games in Android Showcase (162) games submitted by our members Games in WIP (632) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
 Home Help Search Login Register
Pages: [1]
 ignore  |  Print
 "Math" vectors and "lines": How to approach the difference?  (Read 3149 times) 0 Members and 1 Guest are viewing this topic.
Axeman

Senior Devvie

Medals: 7

 « Posted 2012-04-07 23:15:42 »

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.

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.

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!
sproingie

JGO Kernel

Medals: 202

 « Reply #1 - Posted 2012-04-08 04:55:18 »

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.
Axeman

Senior Devvie

Medals: 7

 « Reply #2 - Posted 2012-04-08 14:13:51 »

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.

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.
 Games published by our own members! Check 'em out!
Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

 « Reply #3 - Posted 2012-04-08 16:01:20 »

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.

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<Vector3> 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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
sproingie

JGO Kernel

Medals: 202

 « Reply #4 - Posted 2012-04-08 16:32:43 »

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.
Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

 « Reply #5 - Posted 2012-04-08 16:46:29 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
sproingie

JGO Kernel

Medals: 202

 « Reply #6 - Posted 2012-04-08 16:55:35 »

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.
pitbuller
 « Reply #7 - Posted 2012-04-08 22:25:43 »

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

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

 « Reply #8 - Posted 2012-04-08 23:52:45 »

Glsl do it right. vec4 is what ever you want it to be and that just works.
Hell yes. Language support for swizzling is great.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Axeman

Senior Devvie

Medals: 7

 « Reply #9 - Posted 2012-04-09 21:18:41 »

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<Vector3> 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.

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.

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.
 Games published by our own members! Check 'em out!
sproingie

JGO Kernel

Medals: 202

 « Reply #10 - Posted 2012-04-09 22:22:47 »

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.
Roquen
 « Reply #11 - Posted 2012-04-11 10:08:21 »

Quote
A mathematical vector is supposed to have only magnitude and direction?
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.
Pages: [1]
 ignore  |  Print

You cannot reply to this message, because it is very, very old.

 MrMapcom (16 views) 2015-05-23 20:26:16 MrMapcom (22 views) 2015-05-23 20:23:34 Waterwolf (29 views) 2015-05-20 15:01:45 chrislo27 (35 views) 2015-05-20 03:42:21 BurntPizza (70 views) 2015-05-10 15:53:18 FrozenShade (56 views) 2015-05-07 09:11:21 TheLopais (218 views) 2015-05-06 13:36:48 TheLopais (202 views) 2015-05-06 13:35:14 TheLopais (207 views) 2015-05-06 13:33:39 TheLopais (226 views) 2015-05-06 13:32:48
 Spasi 32x Riven 16x BurntPizza 16x ra4king 12x theagentd 11x Drenius 11x DavidBVal 11x Husk 11x EgonOlsen 11x KevinWorkman 9x princec 8x scanevaro 8x opiop65 7x Slyth2727 6x revers 6x KaiHH 6x
 List of Learning Resources2015-05-05 10:20:32How to: JGO Wikiby Mac702015-02-17 20:56:162D Dynamic Lighting2015-01-01 20:25:42How do I start Java Game Development?by gouessej2014-12-27 19:41:21Resources for WIP gamesby kpars2014-12-18 10:26:14Understanding relations between setOrigin, setScale and setPosition in libGdx2014-10-09 22:35:00Definite guide to supporting multiple device resolutions on Android (2014)2014-10-02 22:36:02List of Learning Resources2014-08-16 10:40:00
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org