 |
Author |
Topic: Making the jump to 3D (Read 2542 times) |
|
flight404
 
|
Making the jump to 3D
« on: Apr 25th, 2004, 9:24pm » |
|
After much procrastination and whining, I was finally able to wrap my head around 2D vector based movement. In case my lingo is a little off, I mean that instead of independently moving something along the x and y axes indiscriminantly, I now determine the angle of movement and speed of movement and use that to find the velocity along the x axis and y axis. Pat on the back. 
BUT... and here is the crux of the matter at hand, I want to know how to do this for a z axis as well.
I did some spherical movement experiments a while back, but did it using latitude and longitude. This worked relatively well but found that there was some bunching up along the poles.
Can someone point me down the right path? And preferably, that path would be ripe with examples.
r
|
|
|
|
|
mflux
|
Re: Making the jump to 3D
« Reply #1 on: Apr 26th, 2004, 12:05am » |
|
Ohhh I'm interested too!
I'm on the same boat with you Flight. I wrapped my head around 2d and vectors (angle/magnitude) stuff, but 3d is both scary and well... alien!
z-phobia...
-mike
|
|
|
|
|
justo
|
Re: Making the jump to 3D
« Reply #2 on: Apr 26th, 2004, 8:33pm » |
|
hmm, could you maybe explain your trepidation a bit more? maybe i dont understand exactly.
if i do understand you, i dont think its as difficult as you may think. think of it this way: 2D movement is just a special case of 3D movement...you are moving in the x and y directions, but staying at a constant z = 0. all you have to do is to start keeping track of movement in that direction and youre set.
so now your vectors will have 3 components instead of 2, but other than that the mechanics are all pretty similar...you just have to figure out the new processing (if thats the platform you want to use) syntax for displaying your work.
|
|
|
|
|
justo
|
Re: Making the jump to 3D
« Reply #3 on: Apr 26th, 2004, 8:44pm » |
|
hmm, but looking at your post, i might not have understood...you sound like you are using a polar coordinate-like system for your movement (ie a direction angle and a vector length).
since vector operations can be broken down into their constituent parts, like adding first the x values, then the y values, and then the z, i would suggest keeping them seperate. dont think of it as "independently moving" things along the seperate axes...youll find that it is exactly equivalent to calculating the angle and then calculating the new (x,y,z) position based on that.
the reason i say this is not because it doesnt work, it obviously does and can be useful for things like "vehicles" that need a direction even if they arent moving, it just gets problematic in 3D.
you have two options to extend it, cylindrical coordinates, where you use an xy angle and a xy vector length, but also a z value (so its like a polar coordinate/vector hybrid), or spherical coordinates, where you have two angles and a vector length. neither are very elegant for 3d movement, since youll have to do a lot of converting back and forth.
so i would suggest just using 3 component vectors...but again, i could be completely misinterpreting what you are writing.
|
|
|
|
|
narain
|
Re: Making the jump to 3D
« Reply #4 on: Apr 27th, 2004, 5:22am » |
|
Indeed. There's actually no way to extend polar coordinates (distances and angles) to three dimensions that avoids "bunching up" somewhere.
That's because you can't draw a grid on the sphere with the gridlines uniformly spaced. If you draw latitudes and longitudes on a sphere, you'll notice all the longitudes bunch up at the poles, so anything you generate using this system will do that too.
So in 3D, you usually have no alternative but to keep xyz coordinates.
But, as justo said, there's nothing wrong with that!
In general, this is actually easier and more efficient than polar-style coordinates, even in 2D. Of course, there are cases where you really want to keep distance and heading separate. These don't really come up very often, but they can be handled. Since there isn't any general solution, there are different techniques for different purposes.
What exactly do you want to do with the directions and angles? There should be a good way to do it directly in xyz coordinates without any bunching-up problems.
|
| « Last Edit: Apr 27th, 2004, 5:23am by narain » |
|
|
|
|
flight404
|
Re: Making the jump to 3D
« Reply #5 on: Apr 27th, 2004, 7:02am » |
|
Okay, this is gonna be tough. Bear with me.
If I am only dealing with 2 dimensions, and I use angle and velocity to control the movement of an object, then I would do the following to get the movement along the x and y axis.
Code:
angle = 50;
velocity = 10;
theta = radians(angle);
xVelocity = cos(theta) * velocity;
yVelocity = sin(theta) * velocity;
object.x += xVelocity;
object.y += yVelocity;
|
|
But if I include the z axis, I cannot rely on a single angle measure to represent the direction of movement in 3 dimensions. The reason this bothers me so much is that I know I figured this out a while ago and came up with a working example, but alas, I cannot locate this file and I cannot remember how I did it.
I assume I use the XY angle measure to represent one side of the right triangle that would allow me to get the YZ angle... or something like that.
I realize this is a bit puzzling to decipher, but to simplify the problem as much as possible, what is the best way to find the angles needed in order to control an object's movement in 3 dimensions.
Does that clear up the question a bit?
Argh, pisses me off that I once knew the answer to this. That is what I get for going to art school and neglecting my math classes... none were required. 
|
|
|
|
|
JohnG
|
Re: Making the jump to 3D
« Reply #6 on: Apr 27th, 2004, 11:47am » |
|
On problem with using angles to describe direction in 3D, is that if you apply them in different orders, you can end up with different results, depending on how you interpret them.
if you take heading pitch and bank (like most 3D modelers/renderes use) thy do heading, then pitch, then bank, so you rotate right 20', then up 10', then twist by a few degrees.
However, if you wanted to pitch up 20', and then rotate 180' right, but as if the current direction was level, you have to mess around with the angles. with the 3d modeller way, you'll end up 20'up in the opposite direction, but if you wanted to do it in the order you thought, you'd assume you'd actually end up pointing 20' below the original "horizontal".
Hard to describe in text really, but it means that if you're pointing 80' upwards, then slowly rotate 360' of heading, you'll just be wobbling around the vertical axis, which may cause the "bunching" you mentioned in your first post.
However, it makes the maths a lot easier.
If you have angle omega and gamma (heading and pitch), and velocity V, the movement vector is:
y=V * sin(gamma); (assuming y is "up")
x=V * cos(gamma) * sin(omega);
z=V * cos(gamma) * cos(omega);
You can see from the formula, that altering the heading (omega) doesn't affect the y component of the movement vector.
X and Z may need to be swapped, depending on which direction you think "forwards" should be.
The other method uses "Quaternions" but I have no idea how the matsh works, but google might help.
|
|
|
|
|
flight404
|
Re: Making the jump to 3D
« Reply #7 on: May 4th, 2004, 6:51pm » |
|
Okay, here is a simple visualization.
If anyone is up for filling the role of professor, why does the black line in this sketch not terminate at the center of the second cube?
http://www.flight404.com/p5/threeDeeTest
UPDATE...
Quick note... I realize I could simple connect the cubes using...
line(cube1x, cube1y, cube1z, cube2x, cube2y, cube2z);
The point of this sketch is to find x,y,and z vector information and use that to get the black line to the second cube's center.
line(cube1x, cube1y, cube1z, cube1x + xv, cube1y + yv, cube1z + zv);
|
| « Last Edit: May 4th, 2004, 6:54pm by flight404 » |
|
|
|
|
justo
|
Re: Making the jump to 3D
« Reply #8 on: May 4th, 2004, 10:28pm » |
|
went through your code (that // at the end was evil... took me a while to figure out. some kind of copy protection?) and found the error:
Code:zAngle = findAngle(particle[0].x, particle[0].y, dist, particle[1].z);
totalDist = findDistance(particle[0].x, particle[0].y, dist, particle[1].z); |
|
what this is doing is finding the distance and angle between two points ([0].x, [0].y) and (dist, [1].z) ...basically putting dist and z in the xy plane and finding the angle and distance between them. the only reason that it almost lines up with the top of the cube is a happenstance of the numbers you used...use different numbers for one of the cube's z coordinate and youll see (though maybe you already knew this).
what you want to do is find the zAngle and totalDistance in a plane with the z axis as one of its axes, and an arbitrary one aligned with the xy vector between the two. lets see if i can do some ascii art:
Code:
......... /|
......... / |
......... / |
.totalDist/ | [0].z - [1].z
........./ |
......../_____|
........ dist
|
|
(the periods are meaningless...just couldnt get it to line up correctly) where you are trying to solve for totalDist and the angle on the bottom left. with it visualized, its pretty easy to solve:
Code:zAngle = findAngle(0, particle[0].z, dist, particle[1].z);
totalDist = findDistance(0, particle[0].z, dist, particle[1].z);
|
|
here you are finding the angle and length between (0, [0].z) and (dist, [1].z) or, to put it another way
Code:totalDist = sqrt(dist^2 + ([0].z - [1].z)^2)
which is equivalent to the pythagorean theorem in 3d:
totalDist = sqrt(x^2 + y^2 + z^2)
and
zAngle = atan2(([0].z - [1].z), dist)
which is the way you calculate the angle phi in spherical coordinates from cylindrical, basically a nice
zAngle = atan(z / dist)
(sort of...phi is really (PI/2 - zAngle...but thats just convention)
|
|
now that this is all done, it should be noted you could have just used the zv you had already calculated. and thats the essence of what we were talking about in the previous posts...if the components of the vector are correct, all the angle and distance info is correct. the easiest way of doing this is just to treat each dimension seperately. you kind of hit on it with your edit, but to go in a more vectorized route, you could have used:
Code:
xv = particle[0].x - particle[0].x;
yv = particle[0].y - particle[0].z;
zv = particle[0].z - particle[0].z;
line(particle[0].x, particle[0].y, particle[0].z, particle[0].x + xv, particle[0].y + yv, particle[0].z + zv);
|
|
and avoided a whole lot of trig. hope that helps...cool visualization by the way.
|
|
|
|
|
miked
|
Re: Making the jump to 3D
« Reply #9 on: May 4th, 2004, 10:57pm » |
|
Ok, well justo beat me to the explanation, but you are calculating vectors in a far more complicated and inefficient manner than necessary. As you alluded to in your original post, operating on the x, y, and z axes independently is exactly how you work with vectors (that is, unless you're working in some other coordinate system, like spherical or cylindrical). By converting everything to angles and then back in to cartesian components, you're doing a bunch of extra steps for no reason.
What you're doing would make sense if, say, all you had to begin with was an angle and a distance, and you wanted to decompose that in to cartesian components. But you have the cartesian components to begin with, and then you're converting them to an angle and a distance just to then convert them BACK to cartesian again. Not necessary!
Anyways, here is a "corrected" version of your applet. I commented out the unnecessary stuff and replaced it with the "easy" way.
http://web.mit.edu/mdanzig/www/threeDeeVectors.html
Hope this makes sense,
-mike
|
|
|
|
|
flight404
|
Re: Making the jump to 3D
« Reply #10 on: May 4th, 2004, 11:03pm » |
|
Thank you. That helped a great bit. I appreciate the time it took to post that. BTW, the // at the bottom was a relic from working with the bad actionscript editor in Flash... Got used to adding extra returns at the bottom in order to make the bottom-most lines easier to edit.
rock.
r
UPDATE...
Doh. Now I am really perplexed. After all this mess, I cannot remember why I felt the need to use all that trig. If I remember, I will repost, but for now, let it be suffice to say I feel like quite the dolt.
Thanks all... more to come I am certain.
r
|
| « Last Edit: May 4th, 2004, 11:05pm by flight404 » |
|
|
|
|
flight404
|
Re: Making the jump to 3D
« Reply #11 on: May 4th, 2004, 11:29pm » |
|
Okay, let me try again.
Say I want to drop an object into a gravitational field with a center of 0,0,0. If I place my object at 3,4,5, I could simply make the objects xpos, ypos, and zpos accelerate towards xgrav, ygrav, and zgrav. But if my object is already moving in a specific direction (hopefully represented by a 3D vector), wouldnt I need to do something more complex than just using the difference between the object's current position and the gravity's current center?
Ugh, that was a horrible explanation. Let me just paste some code.
This...
Code:
gxv = x - xGrav;
gyv = y - yGrav;
gzv = z - zGrav;
xv -= gxv * .1;
yv -= gyv * .1;
zv -= gzv * .1;
|
|
creates an entirely different effect than this...
Code:
gAngle = findAngle(xGrav,yGrav,x,y);
gDist = findDistance(xGrav,yGrav,x,y);
gZAngle = findAngle(xGrav,yGrav,gDist,z);
gxv = cos(gAngle) * gravity;
gyv = sin(gAngle) * gravity;
gzv = sin(gZAngle) * gravity;
xv += gxv;
yv += gyv;
zv += gzv;
|
|
... right?
Note, this code doesn't take into account the Justo solution, but hopefully this is enough to help explain my problem.
I feel like Nell must have felt, from the movie of the same name. I speak my own Jodie Foster language that nobody else speaks but yet I want to explain to Ralph Fienes that I love him or some such crap. Argh.
r
UPDATE!!!!!!
after plugging in the justo correction, Everything seems to work as I expected. I will upload the result in a bit so as to better clarify what the original problem was in the first place.
Thanks all
UPDATE-------------------
here is the initial working version.
http://www.flight404.com/p5/magnets2_3D/
Single click without drag creates a new particle. Click and drag creates many. I recommend single clicks until you have about 20 or more particles. Space bar toggles axis lines
This is an attempt to place positively charged particles into a gravitational field. The particles move towards the center of the field but are repelled by other particles. platonic solids tend to form if there are the requisite number of particles present. I still need to modify the damper to keep the shapes from undulating so wildly.
Warning, the source code is free of comments generally is a huge mess. Plus, havent yet added the kudos for the assistance.
thx
|
| « Last Edit: May 4th, 2004, 11:45pm by flight404 » |
|
|
|
|
mflux
|
Re: Making the jump to 3D
« Reply #12 on: May 5th, 2004, 10:36am » |
|
Congrats flight!!  You've given me inspiration to make the dive myself That gravity field looks real good. Freeing yourself into the z-axis must feel great huh..!
|
| « Last Edit: May 5th, 2004, 10:36am by mflux » |
|
|
|
|
Charles Hinshaw
|
Re: Making the jump to 3D
« Reply #13 on: May 6th, 2004, 4:15am » |
|
I know that this isn't the direction this thread was going, but when it starts off this way, maybe this question is valid here --
Do you (flight404) or anybody else here, have any good, clean (ie. not a bunch of other un-related stuff), and document 2d vector-based movement examples in Processing?
|
Charles Hinshaw
PHAERSE
http://www.phaerse.com
|
|
|
flight404
|
Re: Making the jump to 3D
« Reply #14 on: May 6th, 2004, 5:08am » |
|
Good, clean, and well documented isn't really my m.o. But I am working on it. Eventually, I want to be able to put all my source code up on flight404.com, but that will certainly take some work.
I am certain, however, that there are probably some really good vector classes out there. Lets see if anyone chimes in.
r
|
|
|
|
|
|
