Posted: Fri Feb 12, 2010 10:36 pm
I have worked like a madman again, slowly getting somewhere...
http://orbiter-forum.com/showthread.php ... post152537
http://orbiter-forum.com/showthread.php ... post152537
The source is still full of stupid ways to do things and littered with debug prinf's and old code, most variables are defined globally and using pointers slowly works better but still gives me headaches from time to time, well basically I just started c++ a little bit more than a year ago and never really read much about it, that is clearly reflected in my code.
But enough pessimism, it can only get better if you know about the flaws, it's a lot more going on now.
Not really sure where to start, well maybe with the new kepler solver which I got from Fundamentals of astrodynamics and applications by David Vallado which again comes with the Companion code for Fundamentals of Astrodyanmics and Applications which is available in fortran, c++, pascal and matlab. So far I only use the kepler function, but the whole source is full of useful stuff from orbital plane changes to what not else, I'm certain it will provide me with heap loads of more usefull stuff, once its needed and understood. The Kepler function takes as input the satellites relative position vector from the central body and its velocity vector (orbital state vectors), the Gravitational constant times the mass of the body, a time in seconds to propagate the orbit and calculates the resulting new state vectors... Which comes in very handy since now I can step the timescale right up/down to any value without loosing to much precision. Stepping the timescale can be done by pressing .(dot) and ,(comma) on the keyboard. The algo I used and wrote myself before, did work, it did subscribe to kepler and newtons laws, but it really lacked realism and basically worked by adding all g-pull vectors of all planets to the velocity vector of the satellite, which is just wrong unfortunately. Now I have a defined Sphere of Influence around every body and if I'm not within this or that sphere of influence I'm in the SOI of the sun, which is an approximation known as "patched conic approximation" and there's really nothing wrong with it.
Another thing I really got figured is an understanding of what the keplerian elements actually geometrically mean, after nearly a year
but well, I can now generate ellipses and rotate them until they match the orbital plane (incliation and longitude of ascending node) and then locally rotate on that plane around Y until the argument of periapsis matches. Since these values change over time, I can now update them. As a result all orbit ellipses now always match the actual path of the planets around the sun.Also new is a relatively low precision but working lunar positioning algo, which I found on the net, it's written by Keith Burnett and based on the lesser known Meeus Ch45 series, which themselve are truncations of the more popular ELP-2000 series. They take into account orbital pertubations of our moon due to the other planets influence on it, something I really didnt know, but that is complex stuff and not an easy task to predict the position of our moon. Well it's included now, for our (earth) moon only and it allows you to pretty exactly find the current lunar phase, and I checked with a calendar, it works pretty well.
Also, finally I managed to reset the coordinate system in a good way, earlier I always reset in a way that would put the closest planet in the origin of the coordinate system, now, wherever I am the camera is in the origin, all positions are stored as doubles and bye bye to the precision problems I used to fight with. I can now smoothly orbit Pluto.
Another new thing is the render order. Now I first render the background with a huge far clipping plane, then reset the zBuffer and render the closest planet with an optimized far clipping plane, which allows me to go right down to less than 100 km close to the surface, maybe even lower without Z-buffer problems, also, no more flickering (Ok, a little) when I'm to far.
Also new is a projection mode which you can enter by pressing 'P' on the keyboard. This is still unfinished buggy and ugly, I'm really not a big fan of the GUI in irrlicht. Also it's still heavily under development because I'm only using it to mess with my lambert solver for interplanetary transfers, trying to efficiently fly to mars for the last few months now. The lambert problem can be described as
which basically means that it accepts as input the position vector for departure, the position vector for arrival and a time of flight between those 2 points and calculates the velocity vectors for a transfer orbit between the 2 points. It works very well when the transfer angle is not to close to 180° or Pi, which is a basic flaw in the method and from my current understanding kind of normal. Well the most efficent way however would be a transfer angle of close to 180°, but the resulting orbit my lambert solver gives me is nearly 90° inclined to the eccliptic (an orbit passing over the poles of the sun) which does not at all use the energy the departure planet already has, because it's initial velocity vector is perpendicular to the velocity vector of the departure planet, of course for an efficient transfer the two vectors should be as closely alligned to the each other as possible.The geometrical problem to find all ellipses that go through the points P1 and and P2 and have a focus at the point F1
In a classical Hohmann transfer, the transfer angle is exactly 180°, and the transfer orbit (ellipse) is exactly tangential to departure and arrival orbit, which means that the transfer ellipse can be rotated around the semi-major axis and still hits the the desired arrival and departure points. You can try that in any 3d app, by making 2 concentric circles, make a third one and scale it until it is an ellipse that touches both the inner and outer circle, you can now rotate this ellipse around its longer side and verify it will always touch at both departure and arrival position. However the Hohmann transfer is not really easy to get right in the case the orbits are not perfectly circular and coplanar, which is why I chose to use the lambert solver, and to repeat myself, that fails in the case of a transfer angle close to 180° and it cant be rotated since the transfer ellipse is not perfectly tangential to the arrival planets orbit, so I'm still struggeling with the interplanetary transfers, let alone I still have to think about departure parking orbits and arrival injections.
Alltogether anyway, lightyears ahead from my previous versions and slowly slowly trying to clean up the code. I already started a new class called satellite which I plan to instantiate a couple of thousand times for all comets and asteroids around the sun and all artificial satellites around earth, which will provide me with some very decent screenshots. Obtaining that data, is easy actually and quite fun. Open a command window and type:
Code: Select all
telnet horizons.jpl.nasa.gov 6775A < 30.; IN < 90.; EC < 1.; OM < 360.; W < 360.; MA < 360.;
which will list you all small bodies and their orbital elemets within a range of 30 AU's that have an elliptical orbit.
