Advanced Question get_progradedir + vectors stuff + fisheye scope

[Moach]

Sorry for bumping this, but I'm now trying to do this: http://www.orbiter-forum.com/showthread.php?t=18272
So I'm asking here: how to actually change cartesian to spherical?
Is this the right way to obtain that fish eye scope?

or, if you want, i can just give you the source for that... it's pretty simple actually

you might be overcomplicating... when i wrote that, i just used the flightpath vector as "prograde" - no need to convert too much stuff...

and the "fisheye" effect is as simple as normalize, zero out Z, then multiply X and Y over the radius of the scope....

i'll get you the source for that, don't sweat it :thumbup:
and of you wanna finish it up and release as an addon - by all means! do it! i'm pretty low on free time right now to do so myself.... you know how it is...:facepalm:

the math is all there... i'll post the code up when i get to work tomorrow morning, i left it on my computer there.....

or, search and see in the "TroposcopeMFD" thread of i haven't uploaded it already - i really think i did :hmm:


cheers!

---------- Post added at 09:49 PM ---------- Previous post was at 09:46 PM ----------

aha! i knew i had it here somewhere!

There ya go! :thumbup:

 

[Goth]

@orb: Ok, got it better now.

If you only want a half of it, limit it to PI/2 - I think this is what you mean.

What I was trying to do.

@Moach: hi, it seems I missed the second topic about your MFD idea. I thought it was more of a rough draf, instead you already wrote code about it. :lol:
Sorry for that.

i'll get you the source for that, don't sweat it.

I actually choose to try to do this to understand something about vectors and stuff but I'm actually far from understanding something.:facepalm:

Since you already wrote down code of it I think I can leave you finishing it unless you really want me to go on with it lol.

EDIT:
I've checked the source and it's actually very basic. But it isn't useful to me because I see that you have encountered the acceleration problem too. I was actually trying to correct this problem with this topic, because losing 10° on the "edges" of the sphere is a pity.

 

[Moach]

aha, now you're getting where i was when left this off....

the "accelerating near center, slow around edge" problem :hmm:


it's not a problem per se - you know... it's the natural behaviour of things when done this way...

what you see when the marker rolls from one side to the other of the scope, is a logarithmic-ish motion, (the inverse of "exponential")...

it's embedded in the very nature of all normalized vectors.... when "flattened" into 2d form, they behave like this... and it looks like things move "slower" when close to the borders....


right now, i'm trying to figure out a way to compensate for this...

a naive approach was to calculate the angles of the vectors x and y from in polar coordinates and crudely interpret them as cartesian x/y for drawing on the scope....

didn't work...
what i got was a a vector that behaved in a square-ish fashion... not quite what i had in mind...


but then - i figured it out! :banana:

or i think i did... well, it works!!

i found that by factoring the Z axis back in, i could (don't ask me how) invert the velocity curve - making the vectors move slower around the center, and faster on the edge!

that, i achieved by multiplying the deviation X and Y axes with the inverted (one minus) Z


although this is still not correct - now i have the inverse wrong result :huh:


so by averaging out the two - surprise! - the correct one! :woohoo:


the formula for positioning the marker on the scope looks like this:

int x = mW + (vDvt.x + (vDvt.x * (1-vDvt.z))) * .5 * mW;
int y = mH - (vDvt.y + (vDvt.y * (1-vDvt.z))) * .5 * mH;

where mH and mW are the half witdh and height of the scope MFD... well you know that from the source code already, right?


well... that sorted out the "fisheye" effect - now, as the ship rotates, you see the little ball move around the scope at a constant velocity :thumbup:


yet, i can't help to think that there's an easier, more correct way of doing this... is there?


my math continues to elude me, as always....



the new build is attached, feel free to go through it as you please

 

[Goth]

aha, now you're getting where i was when left this off...

:lol: Actually this busied me for while.
In the meanwhile I coded other stuff. It's almost complete, apart user defined vectors and minor issues.

yet, i can't help to think that there's an easier, more correct way of doing this... is there?

Sure, orb in this topic itself gave me the formulae, althought I still have that 360° problem.

 

[Moach]

ah, right-o!

i see that Orb gave us the formula for doing it the most mathematically-correct way... but my alternative appears to be more computation friendly, as it skips the atan2 angle check as well as the sin and cos function calls...

anyways - for the 360 degree problem, in my code, i just check the sign of the Z axis, if it's negative, then the signs in the formulas are inverted, and i switch the little ball with a little "x", representing the retrograde vector


does that help?

 

[Goth]

but my alternative appears to be more computation friendly, as it skips the sin and cos function calls...

I actually agree.

anyways - for the 360 degree problem, in my code, i just check the sign of the Z axis, if it's negative, then the signs in the formulas are inverted, and i switch the little ball with a little "x", representing the retrograde vector

Of course, this is what I already did, but with his formulae you cannot use this solution because of what I wrote in the post #19.
I'll try now your code.

 

[martins]

Currently the two of you are simply projecting a point on a sphere (the tip of the normalised vector) onto a circle. This projection gives you a cosine scale in the radial direction, i.e. the radial distance is compressed towards the edge of the circle. It also isn't unique because it maps a forward or backward pointing vector onto the same point.

If you want to be more flexible in terms of the projection you use, you have to follow orb's advice:

• map the cartesian vector coordinates into spherical polar coordinates
• project to 2D by using the polar angle for radius from centre, and the azimuth angle for direction
• apply any additional transformation on the radius variable if desired
• map back from 2D polar coordinates to 2D cartesian coordinates
• plot the point
• this gives you a full 180 deg polar view, with 0 in the centre and 180 at the edge, but of course you can cut the polar angle at any value you like.

Can't get easier than that!

 

[Moach]

after a brief lunch break, i returned to look at the formula i devised this morning... it really is that simple! amazing how those things seem easy after they're all sorted out - yet, it took me all morning to think of that....

int x = mW + (vDvt.x + (vDvt.x * (1-vDvt.z))) * .5 * mW;
int y = mH - (vDvt.y + (vDvt.y * (1-vDvt.z))) * .5 * mH;

this little lump of trial-and-error bred code seems to cut a lot of corners on doing what the good dr. so accuretely listed out...

it has the same effect as figuring the angle and radial distance, then plotting it's cos and sin to convert back to cartesian coords for drawing... except, all it takes is a normalized vector... eliminating a lot of additional complex calculations as well as turning the cosine radial scale into a linear range

then, when Z goes negative, the part of it that goes "1-vDvt.z" should become "1+vDvt.z" and the plus and minus operations at the left should be swapped - this forces the vector to be displayed "backwards" switching from prograde to retrograde

so you have:

//prograde (positive Z)
int x = mW + (vDvt.x + (vDvt.x * (1-vDvt.z))) * .5 * mW;
int y = mH - (vDvt.y + (vDvt.y * (1-vDvt.z))) * .5 * mH;


//retrograde (negative Z)
int x = mW - (vDvt.x + (vDvt.x * (1+vDvt.z))) * .5 * mW;
int y = mH + (vDvt.y + (vDvt.y * (1+vDvt.z))) * .5 * mH;

thus, for all effects, this implementation has a 90° range to either side, with zero in the middle and +90/-90 on the edge... i'm not sure still how one could increase that to 180 at the edge like Martin said with this method...

but i'm pretty satisfyied with it right now - i was dwelling on this for quite some time already


now i can finish up my Gyro-MFD, in case Goth hasn't already... (have you?)


anyways, i was planning to add a little button to the MFD to switch from linear (the code above) to cosine (as it was before)...

cosine mode has more precision in the center, which is good for fine alignment before a burn... and linear is well, linear.... so things move in constant velocity...

so, as both modes have their pro's and con's... why not have both? :hmm:

 

[Goth]

now i can finish up my Gyro-MFD, in case Goth hasn't already... (have you?)

Basically; :lol: I've done target locking and stuff, I'll give you the code via PM.

 

[Moach]

alright! cheers!