Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[cooldude234]

Should I mention that these points are in 3d space.
I was just just calculating 2 triangles one for the x and z (yaw), and one for the x and y (pitch).
Would that cause some issue with this equation?

[Raxx]

It seems like it'd work but I don't have much experience with 3D/vector math and such, at least not yet.

I'd assume that there are several libraries out there with functions that automatically calculate these kinds of things, and websites with info on this kind of math.

[cooldude234]

Yea, I don't have much experience with 3d vectors.
I've done what I'm trying to do now with 2d along time ago and got it to work flawlessly.
I only recently started programming with 3D only at the start of summer. So I'm assuming that it must be something either that I'm doing, or something to do with the fact that it is 3D, or both.

[cooldude234]

Well I solved one issue, still getting weird results, but however it seems that when I used the atan funtion (arctan), with the distances between two points etc etc. It was actually returning the value in radians, so I multiplied by 180 and divided by pi to convert it into degrees and now I'm getting the correct angle that the mouse is pointing.
Though my issue now I believe is just a matter of my programming, cause the ray is being projected correctly on the angles Yaw 0.

[Water Music]

I've studied 3d calc and 3d physics a few years back, so I can probably dig up an answer for you, but I think I will need to know more details about what you are trying to do and what numbers you want to end up with.  The problem could be a few things.  Are you using lines or vectors?  Is distance important or just relative orientation?  The world, the camera, and the objects all have their own coordinate system, so which angle is being compared to which?  E.G. "line between camera and its focal point in relation to the world's z-axis."  And of course, a Google search for "angle between two 3d lines/vectors"  will tell you more than I ever could on the subject.

[cooldude234]

3d calculus, I probably could never sit through a course of that (even though I probably really need it)

Well for starters, I'm using OpenGL so everything is computed through matrices. The world has one matrix, and the objects have a matrix so there are matrices in matrices.
Though what I'm doing is just getting the angles of things and letting OpenGL display it in a matrix (I say where to put it, OpenGL puts it there). I'm using a function (gluUnProject) that gets the 2D coordinates of the mouses position and reverses the main matrix to get its position as a 3D vector. I can define on how far back I want to "unproject" the mouses position (I can define a mouses depth). So I unproject the mouse twice, once close to the camera, once far from the camera (NOTE: OpenGL computes the angles of the screen, so when I say depth I do not mean the worlds z coordinates, I mean its the depth relevant to the area that the screen is viewing). Then I get the angle from those two points (as I have solved with Raxx's help above).

Now what I'm doing with this angle is...
I have a for loop (a type of loop in computer programming for those who do not know), that goes through for a number of times (which is the "life" of the ray), and moves a certain distance (which I can define as any amount I want, for now its just moving a distance of one tenth (0.1)).
So I'm trying to figure out how to use sine and cosine to compute the yaw and pitch of the ray and the distance to move by and put in a 3D vector coordinate (so compute yaw and pitch, to get the amount of x y and z to move by).



There are multiple ways to make rays, I want to implement at least these two ways...
The way I have above
and an intersecting point, which contains two points, and finds the intersection of objects and whatever in the line formed by those two points.

The reasons why I want the one above, is because then you could cast the ray to infinite space (for as long as the application is running you could have the ray moving). The reason why I want the other way, is to have accurate and quick results.
Also I'm planing to combine the two ways, cast a ray that moves a distance then checks if there was an intersection between that position of the ray and the last. So I could have the infinite ray and accurate results together. Basically I'm making it so that you could use rays to the max.

[cooldude234]

Oh, AND OF COURSE I'VE CHECKED GOOGLE...
That was the first thing I did.

[cooldude234]

OHHHHHHHHHHHHHHHH YEAAAAAAAAAAAAAAAAAA!!!
Says the koolaid man

Great news!
I have just got mipmapping to work! As well as I am using gltexture2d now, which is more compatible, and yet on top of that! I still have non power of two textures working!!!! BAM! Imma in a goood mood now (:
I mean, it only took 7 months to find out the solution

So for those less techy out there, mipmapping (in 3d graphics) is the process of making copies of the texture, but each copy is a downsized-smoothed version of the texture usually dividing it by two each time (first texture actual size, second half, the third half the the second and so forth), and using the texture(s) according to the distance from the view point so that the further the texture is, the more downsized it is. This makes the system run much much faster as well as making the scene look much better as it gets rid of great pixelizing distortion. In fact anim8or uses the mipmapping process, you can see it in the textures when you zoom out far enough, or got on a certain angle from the face.

EDIT: and happy 10 hours late new years

[cooldude234]

I just tried it out on the intel graphics (netbook), and it works 100%
This pretty much mean that any lower end pc's are now compatible (which is well over probably 50% of the users estimating)

[cooldude234]

Back to the ray casting issue, still haven't solved it, though a better name to give what I'm trying to do, is convert a 3D a yaw and pitch into a normal vector (or a directional vector). Just in case that helps to spread some light on this problem.

[Water Music]

Sorry I never got back to you on that, but my idea of a vacation is to lock myself away in a workshop for 2 weeks doing metalwork.

Quick stolen answer:

"If we define pitch=0 as horizontal (z=0) and yaw as counter-clockwise from the x axis, then the direction vector will be

x = cos(yaw)*cos(pitch)
y = sin(yaw)*cos(pitch)
z = sin(pitch)"

And I'll add to that that in 3d math the length of your vector will be L^2=x^2+y^2+z^2 - the 2d equivalent is a^2=b^2+c^2 for right-angle triangles.  So you can use that to convert your vector to a normal vector of length 1 and then multiply for the speed of your object.

If you want to add gravity or wind, etc. then it is a simple matter of adding an acceleration vector to your velocity vector in gradual increments (for example, if you wanted to add a simple gravity vector you would add a vector of 0(x) -9.8m(y) 0(z) every second - breaking it into fractions, of course).

Just keep in mind to keep the speed of your object separate from the frequency of your game loops.  Which is to say that if I am playing 60fps and my friend is playing at 30fps the I shouldn't see rockets flying twice as fast as my friend does - relativistic physics notwithstanding.

I hope this helps

PS  Quick correction: I've verified that the stolen formula, above, gives you a vector of length 1 so you won't need correct the length to get a normal vector

[cooldude234]

Cool, what kind of metal work do you do?

radx = ((Yaw)+90)*3.14/180;
rady = ((Pitch)+90)*3.14/180;
rady2 = ((Pitch) / 180 * 3.141592654f);
Note that this is just converting to radians... or degrees, I cant remember


rayx -= sin (radx)*(sin(rady)*2.5);
rayz += cos (radx)*(sin(rady)*2.5);
rayy -= sin(rady2)*2.5;
And this is the closest (by closest, I mean the best result I could come up with that still does not work) I got to getting the ray to work, but when the yaw gets closer to being 0 the pitch of the ray is multiplied more and more.
Thus meaning if you are slightly looking up and the more you look to the 0 of the yaw, then more the ray looks up
(NOTE: it is multiplying the pitch and not adding, cause it is not noticeable until you are near the 0 of the yaw)
I tried the one you gave, it still doesn't work.

About the gravity and wind, I already know all that, although I do not store my velocity variables in a vector, though I should under the objects name, box.xvel etc etc. and I probably will do that, but not right now. And gravity is the most simplest (unless if you want to planetary gravity were its just not pulling you "down", which I have also done, just in 2d)

And for you last thingy, I know what you mean, first off you have to limit the fps (frame rates per second, not first person shooter) and also you could make a dynamic fps limiter which depending on your fps count, depends on how fast the world objects move (really tedious to implement but cool once again, also have done it in the past), But usually those factors are usually only done with, when you use networking and the host is usually the machine that doesn't lag.
*phew* that's a lot of writing, I got to learn to summarize

[Water Music]

Without going into too much trig, I can say that your second formula works out to be the same as the one I quoted - with the obvious exceptions that you've scaled it from a normal vector to a vector of length 2.5 and you are using a different base orientation.  That one is just fine and shouldn't be causing you any problems.

In your first set, where you are converting to radians, your rady2 formula is ambiguously parsed.  Depending on how your code is being assembled the value could be (pitch/180)*pi or pitch/(180*pi), so I'd recommend a pair of brackets to be sure - with the first one being correct.  That difference can affect your vector length, so maybe start there and see if it helps.

ps  currently I'm working on a Mongolian helmet, a Lithuanian helmet, and a pair of gauntlets.

[cooldude234]

absolutely nothing changed.
So if your saying the that the second half is correct  (which is where I thought the problem was), then I guess there's a lot of work to be done. Cause I have no clue whats going on anymore.

On the bright side, I fixed my billboarding issue. It turns out that y axis while rotating the quad was inverted, so there is now officially billboarding implemented. So I can now continue with making the particle systems structure.

So, what else do you think could be causing this issue music waters (the ray tracing one, I know I just bounced back between two different things )?

[TheRetroZombie]

Thanks, even though I couldn't get that silly box man game to work, hopefully I'll get a second try.