Working Title: 'Orbital Sling Shots and Newton for dummies'

zillion42 · Post by **zillion42** » Mon Feb 09, 2009 11:34 am

HOBBY PROJECT FOR FUN AND SHARING...

Well I'm not so sure about Project Anouncement, because many people already know it and it's not too much altogether, but after finishing some other stuff and looking back into my small solar system I kind of got fascinated again and thought I'd post some updates...
By the way being placed N°6 is really ok considering it probably didn't even run smooth or at all on all systems (still doesn't) and it's quite spaghetti-code

I changed the scale again and everything is in real proportion to each other now. Before the planets were much larger in size than they normally would be. Finding them now, effectively became impossible, without guidance. But thats exactly what I tried to achieve. I wanted to make it a little more realistic... So I started with implementing real values not arbitrary game-play tuned values like the gravity constant and real mass values divided by the scale factor again to keep proportion... So if you manually feed the method handleG() with the distance of earth radius now you will get a value of 9.81m/s^2 and not some made up value like before, and especially earth radius is the first time not inside earth but really earth radius now.
Generally as we all may or may not know if we drop a feather in vacuum it falls as fast as a lead ball, which came to my mind again when looking at 2 nearly identical formulas with the only difference being one outputs force in Newton and the other one outputs acceleration in m/s^2.
Definition of one Newton:
1 Newton is equal to the amount of force required to give a mass of one kilogram an acceleration of one meter per second

Its:

1. Fn = (G*m1*m2)/r^2; and
2. Fa = (G*M)/r^2;

where
Fn = is Force in newton
Fa = a acceleration in m/s^2
G = gravitational constant which is 6.67 × 10-11 m^3kg^-1s^-2
m1 = mass of object 1 (in kilograms)
m2 = mass of object 2 (in kilograms)
M = mass of central celestial body
r = distance between objects' center of mass (in meters)
kilos and meters are a bliss

only the 2nd Formula is required for our purposes but that took me some time to realize. The mass of the satellite plays no role in its velocity or orbital period, not because it is so small just because it cancels each other out if you see the whole formula. To be honest, I'm terrible at math, and looking at most of that stuff for the 15th time in my life – do I understand it ? No ? Looking at it again and reading 5 more firefox tabs (Nothing worse than bad math teachers, oh I hate them), I get a little more and then, one fine more tab and the right way of explaining and suddenly -

I'm able to extract a usefull formula and to my suprise it works as expected...Seriously...

Basically, from what I comprehend so far in terms of astronomical terminology and orbital mechanics I can now calculate what is called an 'inertial frame of reference' for successfully launching satellites (my camera) into a completly circular or eccliptical orbit for all 9 planets/planetoids in an altitude of my choosing (apogee and perigee). I can also precisly calculate before how long the orbital period will be, the exact g-pull as accelleration in m/s^2 aswell as the exact speed in Km/s. All checked and verified. I am still using what is called an iterative approach for the 2 body problem.

The planets position is calculated based on a lot of data, precise for many centuries ahead. I ported the code from a Mr. Stephen R. Schmitt first from an odd scripting language called zeno to a, at this time still Alias Maya, Mel Script and now to irrlicht. It's also verified. The original zeno Programm calculated the position back translated to earth coordinates (including rotation) and just presented a screen with right ascension and declination of all 9 planets.

I am planning to integrate two game modes or two views, a planning & testing view and the normal camera view. Maybe scientific mode and freeflight mode ?
I want to be able to plan gravitational slingshots and orbital transfers between multiple planets using different burn phases to accelerate and using a guidance system to stay on flight plan of course with limited propulsion. <- wow 5 features in one sentence... well slowly... I also want to explain some concepts like escape velocity and so on... All should be kept as simple and interactive as possible because it should be made for guys like me who are not specialists in algebra but generally know how to add subtract multiply and divide. More visual than maths would be nice...

Well, long talk what I'm doing is more or less celebrating that the real values are working...

It's a hobby project more or less inspired and motivated by sheer curiosity of orbital mechanics and hopefully the abitlity for other people to learn something about it aswell by fiddling around with it. A bit of edutainment if you want. And because it's a hobby project it will probably sink into the depth of the forum soon (meaning back to the old unread threads) and there wont be too many updates, but it's here, use it however you like for your own purposes, and yes I will constantly continue working on it, probably again proportional to my unemployment minus curiosity for other things.

I have to change the soundtrack btw., a friend made a track called „cosmic mind stuff“ that kind of describes it aswell, and as much as I love bladerunner, I can't hear vangelis anymore.

I made 2 more youtube videos yesterday, before i had the exact inertial frame of reference figured but they show the real values for a nearly circular orbit and one slightly eccentric orbit with the new arrow mesh nodes pointing in direction of pull (red) and velocity (green) vector and being scaled accordingly...
YouTube - round http://www.youtube.com/watch?v=hXpt6wxsu9o

YouTube - eccentric http://www.youtube.com/watch?v=X2-GdGju5t0

irrSolarSystem - A solar system simulator

http://www.youtube.com/watch?v=uNUVpQqImOE

Ever wanted to play Hale-Bopp ?
I made a solar system that simulates newtons and keplers laws of motion using the irrlicht 3d engine... The planets position is calculated according to real data and the scales are proportional to each other...

D O W N L O A D S O U R C E & B I N A R Y

ps: change startplanet and startAlt top of declarations and camera or camera2 bottom of code to play around, you can also still accelerate in side view using left mouse and right mouse button to see more eccentric orbits... enjoy

rogerborg · Post by **rogerborg** » Mon Feb 09, 2009 3:32 pm

Ooooooh...

dawasw · Post by **dawasw** » Mon Feb 09, 2009 3:50 pm

Aaaaaah...

Pyritie · Post by **Pyritie** » Mon Feb 09, 2009 5:25 pm

Wooooow...

geckoman · Post by **geckoman** » Mon Feb 09, 2009 5:58 pm

Buuuuuuuuuuurp. Thats amazing.

zillion42 · Post by **zillion42** » Wed Feb 18, 2009 2:00 am

ok, I've been working like a madman again...
I think it's safe to say it looks a lot better now. Earth has a decent specular and when starting we are in a geosynchronous orbit with it... (as synchronous as precision allows it and only a few KM above the wiki value

).

I integrated 18 moons with correct orbital periods, but partially incorrect sideral rotation periods... Did you know btw. that our moon is one of the few moons whose sideral rotation period (how fast it spins) is synchronous to how fast it orbits. Thats the reason we keep seeing the same side of it.

I also integrated a pole locking free camera (which still sometimes rolls unintentionally).

Anyway a lot of work has been put into it again, and I hope you enjoy it. Like all developers, of course, I get quite EDIT3: VERY happy about feedback, any kind of feedback (call me funny names), even framerate reports and so on... so please, check it out... If anyone knows anyone who might be interested in it for educational purposes, please forward. Orbital mechanics are in fact more realistic than I ever dreamed they would be. After working for hours I sometimes go to bed and feel like I spent the whole day on giant swing, those acceleration in perigee and decelleration is apogee ARE REAL ! In fact it's the other way round but that would be like saying summer starts at winter solistice.

I am currently working on integrating a sensible way to make the user do Hohmann transfer orbits and an autopilot. Also right now

precise and stable orbits are not possible when planets are actually moving... That is to say, all planets stand still (unless planetsMove = true) for a precise orbital velocity calculation. The only explaination I have for its failing is precision of numbers, but please prove me wrong ! To make myself more clear... when googling about orbital velocities you can find anything from the average speed of satellites (around 7Km/s) to wrong formulas but, NO one ever considers that earth itself moves at 29.79 km/s. So how on earth, if eath moves around the sun in a near-circle can that motion of for example a polar orbit velocity + earths velocity get pulled around a circle when it started as a straight motion

wow, another example of learnig while phrasing the question, because of the sun of course... no, well, feel free to set planetsMove = true, but it's not the same fun as having it simpliefied but precise...

Code: Select all

core::vector3df calcEllipticalOrbVelocity(int type, int i, f64 Perigee, f64 Apogee)
{
	core::vector3df velocity;
	f64 distPerigee;
	f64 distApogee;
	f64 pMassS;

	if(type == 1){
		distPerigee = (mSize[i]+Perigee)*1000;
		distApogee = (mSize[i]+Apogee)*1000;
		pMassS = mMass[i];
	}
	if(type == 0){
		distPerigee = (pSize[i]+Perigee)*1000;
		distApogee = (pSize[i]+Apogee)*1000;
		pMassS = pMass[i];
	}
	
	f64 semiMajorAxisM = ((distPerigee+distApogee)/2);
	f64 pConst = Gconst*pMassS;
	
	//Calculate elliptical OrbitVelocity
	//Velocity at Perigee  	=      sqrt( GM * ( (2*distApogee) / ( distPerigee * (distPerigee+distApogee) ) ) )
	f64 ellipticOrbVelocity = sqrt(pConst* ( (2*distApogee) / ( distPerigee * (distPerigee+distApogee) ) ) );
	ellipticOrbVelocity /= 1000;
	ellipticOrbVelocity /= scaleF;
	
	//calculate planet movement
	if(planetsMove){
		core::array<core::vector3df> Pos1 = mySolarSystem->calculateAtDay(Day,startplanet);
		core::array<core::vector3df> Pos2 = mySolarSystem->calculateAtDay(Day+(incrementF*timescale),startplanet);
		core::vector3df movement = (Pos2[0]/scaleF)-(Pos1[0]/scaleF);
		f64 planetSpeed = movement.getLength()/timescale;
		movement.normalize();
		velocity = movement.crossProduct(core::vector3df(0,0,1));
		velocity.setLength(ellipticOrbVelocity);
		movement.setLength(planetSpeed);
		velocity += movement;
	}
	if(!planetsMove){
		core::vector3df planInc = planetsR[startplanet]->getRotation();
		velocity = planInc.rotationToDirection(core::vector3df(1,0,0));
		velocity.setLength(ellipticOrbVelocity);
		velocity *= -1;
		//velocity = core::vector3df(-1*ellipticOrbVelocity,0,0);
	}
	
	//calculate orbital period in seconds, the formula for an ellipse is 
	//p = 2PI*sqrt(semi-major axis^3/GM) where p is in seconds and semi-major axis in meters
	f64 oPeriod = (2*core::PI*sqrt(pow(semiMajorAxisM,3)/pConst))/60.0f;
	printf("Period in minutes%f",oPeriod);
	f64 temp = pConst*pow(1440.0f*60/(2.0*core::PI),2);
	f64 altitude = (pow(temp,f64(1.0f/3.0f))/1000)-pSize[i];
	return velocity;

	
}

the beers again... anyway IF someone feels like helping me out (I prefer small teams, actually I'm searching for about 1 dedicated individual) feel free to PM me.
EDIT2:
individual with serious fascination for orbital mechanics

Edit:
cursor (arrow) keys change rotation of mini map
shift and arrow up down change zoom of min map
left MB accelerates in forward view direction
right MB decelerates
W-A-S-D moves respectively
Q & E tilt, bank, roll (however you wanna call it)

http://www.tobi.houfek.de/irrSolarSystem.zip

zillion42 · Post by **zillion42** » Mon Jun 15, 2009 2:22 pm

I cleaned up... It's always hard to realize that things that should have worked already actually never did. The bool 'planetsMove', which decided whether planets and their moons travel about the sun or not has been removed, all spins as it should now.

Also I realized that putting an emptySceneNode in the planets centre as a child of the planet called MoonNode and using an offset Moon as a child of the MoonNode to rotate the Moon around the planets center has serious implications on the moons sideral rotation period. The result is a moon that always shows the same side to the planet, which shouldn't really be the default behaviour since that would be a sideral rotation period synchronous to its orbital period. I now have a MoonNode that never spins only positions the Moon, which in turn spins.

The camera trail puts its trail billboards as a child of the closest celestial body now (including moons) to reflect the relative movement and draw ellipses rather than pirouettes.

Now, that is as far as I thought I was, but actually never was.

I began to work on the whole thing again for another reason though, which was getting a little more precision into the HUGE camera space. The point is that if the camera moves far out, beyond reasonable unit measures, there simply aren't enough digits behind the dot for smooth movement. The solution, discussed elsewhere, would be to reset the whole world to something more close to 0,0,0 and moving the camera about the same offset. I'm not quite sure if that is the end of story yet, since placing everything inside a sceneNode with gigantic dimensions would result in inprecision again. I might have to loosly move everything seperatly to achieve what I need. I'll report back on how that went.

Edit:
Ok, I uploaded the updated version. Lots is uncommented and lots is probably just pure stupidity. Just in case anyone wants to take a look.
http://tobi.houfek.de/irrSolarSystem.zip

Edit2:

cursor (arrow) keys change rotation of mini map
shift and arrow up down change zoom of min map
ctrl and arrow left right tilt mini map

left MB accelerates in forward view direction
right MB decelerates
shift-left MB accelerates tangential to orbit
shift-right MB decelerates tangential to orbit
W-A-S-D thrusts respectively
Q & E tilt, bank, roll (however you wanna call it)

Numer keys 1-9 jump to other planets

Edit3:
Normal maps, or normals, or sphereMesh is broken again, dunno, kind of gave it up to have working normalmaps in irrlicht under GL at the moment.... which is sad.

Midnight · Post by **Midnight** » Mon Jun 15, 2009 4:05 pm

so where is the space trader I buy my space weed from?

what you don't have that?

this game sucks then.

TROLL DISCLAIMER: Due to most of the world having knee jerk reaction based intellect ATTENTION this is only a joke. no space weed was harmed in the making of this joke.

zillion42 · Post by **zillion42** » Fri Jul 17, 2009 12:56 am

its' aliiiive, It'S AAALIIIIIIVE !!!

I've implemented a model of earths magnetosphere using fortran subroutines from geopack for the internal field model (main magnetic field) and T96 as the external field model (induced by the interaction of solar wind and earths ionosphere). Because they are data based models I can download all kinds of datafiles, but right now I just used some simple settings.

The fotran routines were translated to c with f2c. It's all littlebit forced until now, I traced the points of the field lines into one huge core::array<core::array<core::vector3df>> which is probably a bad idea, also I just put billboards at the positions. I will try to batch them as bitplane suggested here and maybe take a look at the line list again. Not Sure... I want fast splines someone... would be better anyway. Some fieldlines (close to the equator) are only 3 points long, so they really could use some interpolation.
Performance is very bad to say the least. 2 fps per second is makeable with 9000 billboards and realtime updates, without updates maybe 10, but that should increase if I batch the billboards guess. Also I would like to change the color of the billboards, or better the EMF_POINTCLOUD colour, is that possible ? Otherwise, I could whine about splines again.

Anyway I'm speechless... fun stuff

P.S: Midnight, I'm fine and nothing against Spaceweed...

UPDATE:
I used setHardwareMappingHint(scene::EHM_STATIC) and turned off updates, gives me quite acceptable frames, even at high resolutions...

hybrid · Post by **hybrid** » Fri Jul 17, 2009 9:22 am

You should probably put all positions into one array and render that using EPT_POINTS. That would allow for color changes via SMaterial, and adjusting the size via Thickness. EHM_STATIC should still work then, but it would reduce the recalculation stuff for billboard adjustments. Another thing is EPT_POINTSPRITE, but so far no one ever tested this enough, and as long as you don't need textures it is not really necessary.
Anyway, looks really impressive.

zillion42 · Post by **zillion42** » Fri Jul 17, 2009 5:13 pm

I uploaded an updated version, including source and windows binary...
http://www.tobi.houfek.de/irrSolarSystem.zip

sio2 · Post by **sio2** » Fri Jul 17, 2009 6:02 pm

I'm in the middle of two Irrlicht projects: Cal3D hardware skinning and Quake3scene node with full vis. Since you've supplied code, when I get chance I'll look at some performance enhancements.

This app looks really interesting.

fennec · Post by **fennec** » Mon Jul 27, 2009 11:41 pm

I don't know if this is the intent, but I would love to see this as a game. Even in this state it's kind of fun to navigate around.

You'd just have to shrink the solar system some more to make interplanetary travel more quick, and give the player objectives to complete (like fly to Mars with X amount of fuel, or hurl a garbage ball into the sun, etc). Some missions would have you in a space craft, able to make in-flight corrections. Other missions might involve pre-programmed directions and burns for an unmanned spacecraft (like some physics puzzle game).

Time compression, and a more robust flight predictor would be cool too.

zillion42 · Post by **zillion42** » Wed Jul 29, 2009 4:15 pm

ooops didn't really notice that post...
Well, actually my objective is quite like that. I had mail exchange with this guy from france (Manawenuz) who studies engineering and would like to help and develop it to something like orbiter... long way to go... but the direction is quite my taste aswell.
If you don't know orbiter, here's a linkand a brief description. It's freeware...

ORBITER is a free flight simulator that goes beyond the confines of Earth's atmosphere. Launch the Space Shuttle from Kennedy Space Center to deploy a satellite, rendezvous with the International Space Station or take the futuristic Delta-glider for a tour through the solar system - the choice is yours.
But make no mistake - ORBITER is not a space shooter. The emphasis is firmly on realism, and the learning curve can be steep. Be prepared to invest some time and effort to brush up on your orbital mechanics background. Good starting points are JPL's Basics of Space Flight, and R. Braeunig's Rocket & Space Technology.

EDIT:
The first thing I have to do is solve the precision issue.
After that, once I can start working constructively again I guess should make a proper GUI to control timestep (which is already implemented), stop the simulation and let the user enter into something like planning phase where time (launch) windows, flightplans and planet positions could be evaluated to enter a guided flight or maybe also have an autopilot function. Would be cool if you could just demonstrate an interplanetary flight with timestep of your choosing and simply do nothing. What I would really need is backround information on rocket flight like thruster forces and so on. I read a lot on tranfer orbits (Hohmann), so I think I grasp that principle. But then again in orbiter and generally space flight you'll get confronted with a whole new set of variables I never even heard of. Guess I'll start reading JPL's Basics of Space Flight. Which I just did a bit... no, not really into propellants and stuff, all I need is the force in newton for the different burn phases. Manawenuz can hand fill the arrays for other models and formulas later if he wishes...

He also came up with orbital drag which I completly forgot (again) but after a quick glance I guess at least the friction model should be makeable with some simulated solar wind and Manawenuz help.
In the end possibly later than sooner I can model satellites and Carrier Rockets and someone else can build some cockpits if they wish. But then again it's all just something that grows like this
W = ( U * M ) - Co - uP
where
W = Work done
U = unemployment
M = motivation
Co = curiosity for other things in life
uP = unexpected problems
Really happy about the positve feedback btw. thx all.

zillion42 · Post by **zillion42** » Wed Aug 05, 2009 4:51 pm

I got new colorful orbits and the fieldlines with some fancy colors...
Also new is a mac osX xcode project and a mac binary.

ﾟ+｡☆*゜+。.。:.*.ﾟﾟ¨ﾟﾟ･*:..｡o○☆ﾟ+｡DOWNLOADﾟ+｡☆*゜+。.。:.*.ﾟﾟ¨ﾟﾟ･*:..｡o○☆ﾟ+｡