Rocket Simulator Feasiblity Discussion
by Jack Stone · in General Discussion · 03/25/2013 (11:14 pm) · 22 replies
Good Evening!
I am considering creating a Rocket Simulation program using real-world mathematical equations for delta V, Specific Impulsee, Exhaust Velocity, etc. It wouldn't be a game per se, but it could have game-like elements to it. It would be more realistic than, say Kerbal Space Program, and a lot more user friendly than a pure "calculator" or number-crunching program.
Since I am far more familiar with T3D than any other engine, my first thought was to use it, but there are a couple of issues that make me somewhat reluctant.
I intend to create a new class of object and use it as the subject of a simulation, making sure it is susceptable only to the physics equations I am modelling. I will not need collision, gravity, or any of the usual things, since the equations themselves account for that.
The first issue I forsee is torques infamous "jitter" when travelling more than 10,000 units from the Origin. I know that one torque unit is one Meter, and 10,000 Meters, and 10,000 meters in't nearly enough for even a simulation of Earth Orbit.
I know that this issue is caused by the 32-bit floating point numbers used to store object transforms in T3D, to properly fix it, you would need to convert to 64-bit numbers, which would be exceedingly complex.
Would using custom physics calculations help alleviate this jitter problem? Or at least reduce it to acceptable levels?
The second issue would be simulation a sphere the size of the earth. Can an object of this size simply be created in a modelling package? Detail is not important, I would be happy with just a flat plane, but if a rocket is orbiting the earth, the earth itself should be round.
Thirdly, can an object moving at the speed of a rocket be modelled realistically in T3d? The actual movement will be controlled by the physics simulation I am writing, not by torques own system, but will the raw speed itself cause an issue?
Any thoughts, ideas?
I am considering creating a Rocket Simulation program using real-world mathematical equations for delta V, Specific Impulsee, Exhaust Velocity, etc. It wouldn't be a game per se, but it could have game-like elements to it. It would be more realistic than, say Kerbal Space Program, and a lot more user friendly than a pure "calculator" or number-crunching program.
Since I am far more familiar with T3D than any other engine, my first thought was to use it, but there are a couple of issues that make me somewhat reluctant.
I intend to create a new class of object and use it as the subject of a simulation, making sure it is susceptable only to the physics equations I am modelling. I will not need collision, gravity, or any of the usual things, since the equations themselves account for that.
The first issue I forsee is torques infamous "jitter" when travelling more than 10,000 units from the Origin. I know that one torque unit is one Meter, and 10,000 Meters, and 10,000 meters in't nearly enough for even a simulation of Earth Orbit.
I know that this issue is caused by the 32-bit floating point numbers used to store object transforms in T3D, to properly fix it, you would need to convert to 64-bit numbers, which would be exceedingly complex.
Would using custom physics calculations help alleviate this jitter problem? Or at least reduce it to acceptable levels?
The second issue would be simulation a sphere the size of the earth. Can an object of this size simply be created in a modelling package? Detail is not important, I would be happy with just a flat plane, but if a rocket is orbiting the earth, the earth itself should be round.
Thirdly, can an object moving at the speed of a rocket be modelled realistically in T3d? The actual movement will be controlled by the physics simulation I am writing, not by torques own system, but will the raw speed itself cause an issue?
Any thoughts, ideas?
#2
OR
Like Ron said, change the units. The units only matter in your interpretation of the units. 1 unit could be 100 meters rather than 1:1. So 10,000 units becomes 1,000,000 meters. That would give 621 miles to work with. You won't need objects except as dressing. Your object could be SceneObject based so you know none of the physics or collision would affect it.
What do units mean to a computer anyway? Nothing.
For moving away from the Earth you will need to change objects progressively as you move away. Terrain to start, then possibly a different terrain object, then a sphere. There are probably articles on doing this surface to orbit transition. It is not trivial from what I understand.
03/26/2013 (12:01 am)
Then don't move the rocket inside the 3D engine. Just move everything around the rocket. When the Earth gets a distance away pop in a smaller object that is closer so it never gets more than 10,000 units away. OR
Like Ron said, change the units. The units only matter in your interpretation of the units. 1 unit could be 100 meters rather than 1:1. So 10,000 units becomes 1,000,000 meters. That would give 621 miles to work with. You won't need objects except as dressing. Your object could be SceneObject based so you know none of the physics or collision would affect it.
What do units mean to a computer anyway? Nothing.
For moving away from the Earth you will need to change objects progressively as you move away. Terrain to start, then possibly a different terrain object, then a sphere. There are probably articles on doing this surface to orbit transition. It is not trivial from what I understand.
#3
03/26/2013 (4:29 am)
If you have AFX you can do this easily by simulating the launch and control the outcome and make it more like a movie.
#4
I think a SceneObject based object is definitely the way forward, I can then model only the physics I need without trying to integrate T3D's system with it.
The problem with changing objects as you move further from the earth is how do you cover up the change? There would no doubt be a visual "pop" when changing objects. For a physics "game" this could maybe be forgiven, since the numbers are really what matter, but it would still be something to be avoided. With most games you could cover the "pop" with something like distance fog or environment art, but you couldn't really do that in this case.
Without completly ripping out the terrain system, it's probably the only way of doing it though.
03/26/2013 (12:29 pm)
I could indeed do the "scaling" trick. The important part is that the "readout" is correct, ie, the maximum height of the rocket's flight should be realistic. The visual representation of that height in the engine isn't as importat as the raw data itself. That's probably the easiest way forward.I think a SceneObject based object is definitely the way forward, I can then model only the physics I need without trying to integrate T3D's system with it.
The problem with changing objects as you move further from the earth is how do you cover up the change? There would no doubt be a visual "pop" when changing objects. For a physics "game" this could maybe be forgiven, since the numbers are really what matter, but it would still be something to be avoided. With most games you could cover the "pop" with something like distance fog or environment art, but you couldn't really do that in this case.
Without completly ripping out the terrain system, it's probably the only way of doing it though.
#5
03/26/2013 (3:59 pm)
Fade the new near object in and then fade the old one out - as long as they look alike it should be almost impossible to notice....
#6
I am thinking thought that if something is a "simulation" it should be a simulation, and should not contain any "trickery", like swapping out objects.
What I'm about to try is to decide on the limits to my world, and scale everything down to fit into that "box" without going over the 10,000 unit limit.
Then, just create my objects as normal. The only problem is that I don't know how torque will handle extremely large objects (like the earth) and relatively small objects, like a rocket. I suppose I will have to investigate this and see for myself. I am particularly worried about the texturing, an object the size of a planet, even scaled down and textured with a very high res image, is going to look awful.
I haven't found any data on "surface to orbit" transitions that would help me here, but NASA have released some vey high res phosot of the Earth. What is the max texture size of a T3D Object?
04/05/2013 (7:41 pm)
I'm about ready to try this technique now, thanks Richard! I am thinking thought that if something is a "simulation" it should be a simulation, and should not contain any "trickery", like swapping out objects.
What I'm about to try is to decide on the limits to my world, and scale everything down to fit into that "box" without going over the 10,000 unit limit.
Then, just create my objects as normal. The only problem is that I don't know how torque will handle extremely large objects (like the earth) and relatively small objects, like a rocket. I suppose I will have to investigate this and see for myself. I am particularly worried about the texturing, an object the size of a planet, even scaled down and textured with a very high res image, is going to look awful.
I haven't found any data on "surface to orbit" transitions that would help me here, but NASA have released some vey high res phosot of the Earth. What is the max texture size of a T3D Object?
#7
Frank's idea of keeping the rocket at the origin is a good one. If you are serious about simulating huge distances, I recommend absorbing this article. This is the third in a series of articles about generating a procedural universe, and it's where he starts to talk about scale. The first page where he talks about errors in adding small numbers like velocity to large numbers like position are relevant.
04/07/2013 (4:27 am)
Noooooooooo. Every time someone asks about floating point precision, people bring up the idea of scaling everything down. It does not work. Please do not do it. By scaling down your world, you scale up the visual errors, so they will start appearing at the same relative distance. It's like saying you can make your display better by moving your head closer to it - it appears larger, but now you can see the pixels.Frank's idea of keeping the rocket at the origin is a good one. If you are serious about simulating huge distances, I recommend absorbing this article. This is the third in a series of articles about generating a procedural universe, and it's where he starts to talk about scale. The first page where he talks about errors in adding small numbers like velocity to large numbers like position are relevant.
#8
The only problem I have of course is implementing these ideas in T3D. Modifying the low-level rendering of the engine isn't going to be easy, and I have limited time for this project.
The other thing that's maybe slightly different about this is that all of my "numbers" are essentially, done. I have code that takes a variety of parameters and uses real world rocket equations to produce data based on them, and then sends, very simply, a transform to indicate where the rocket should be, to torquescript.
All of the physics calculations, the velocity, the position, orbital mechanics, etc, are, or will be, handled from my own code in C++ (in F64's). I just need T3D to render a representation of the world.
Does this affect the precision issues, I doubt that it does? What I had intended to do is, for example, output a position of: "0 0 6378159.0"
and then scale that by whatever scaling factor works, and render everything at that scale. So far it seems to be working pretty well, I haven't noticed any strange issues, but all I have in the game is an object to represent the rocket, and a planet Earth with a high res texture.
04/07/2013 (11:20 am)
Daniel, thank you for that information! I read that article you posted, it's excellent. I expecially like the idea of scaling down the object in size in proportion to it's distance, to make it look like the object is further away than it is, very clever!The only problem I have of course is implementing these ideas in T3D. Modifying the low-level rendering of the engine isn't going to be easy, and I have limited time for this project.
The other thing that's maybe slightly different about this is that all of my "numbers" are essentially, done. I have code that takes a variety of parameters and uses real world rocket equations to produce data based on them, and then sends, very simply, a transform to indicate where the rocket should be, to torquescript.
All of the physics calculations, the velocity, the position, orbital mechanics, etc, are, or will be, handled from my own code in C++ (in F64's). I just need T3D to render a representation of the world.
Does this affect the precision issues, I doubt that it does? What I had intended to do is, for example, output a position of: "0 0 6378159.0"
and then scale that by whatever scaling factor works, and render everything at that scale. So far it seems to be working pretty well, I haven't noticed any strange issues, but all I have in the game is an object to represent the rocket, and a planet Earth with a high res texture.
#9
Also, sorry for being a bit hysterical last night. I was up at 1am working on an assignment... it was not going well :P. I should say that before trying anything crazy, have a go at doing things the way that makes sense; if you don't notice the issues, you're all good. When problems start to show up then you can start to solve them.
EDIT: I just realised you're doing basically what the guy suggested as his final solution - using doubles to calculate object positions. Then in the rendering stage (T3D) you convert these doubles to relative floats. So I reckon you should be all right.
04/07/2013 (4:06 pm)
I think in that case you'll just want to find a way to make that all relative to the rocket (or camera) before using it in T3D. From what that article was suggesting, the floating point errors are less noticeable if your camera is at the origin.Also, sorry for being a bit hysterical last night. I was up at 1am working on an assignment... it was not going well :P. I should say that before trying anything crazy, have a go at doing things the way that makes sense; if you don't notice the issues, you're all good. When problems start to show up then you can start to solve them.
EDIT: I just realised you're doing basically what the guy suggested as his final solution - using doubles to calculate object positions. Then in the rendering stage (T3D) you convert these doubles to relative floats. So I reckon you should be all right.
#10
04/08/2013 (1:48 pm)
Quote:I am thinking thought that if something is a "simulation" it should be a simulation, and should not contain any "trickery", like swapping out objects.The only way you will NOT be resorting to trickery is to build the rocket itself outside. A computer simulation is a just a more sophisticated and more accurate set of smoke and mirrors than a game. I used to get hung up about doing things the "real" way until I realized I was looking at pixels in a fake environment. I do agree with trying to make things scientifically as accurate as possible, but your representation will always be limited to the hardware capabilities. That is why we mention swapping objects. It helps you stay within the limits of the equipment.
#11
I have done some more testing, and things seem fine out to my chosen world limit, 100,000 torque units. There is some jitter on the camera, but not enough to be a problem. It only starts to be really noticeable around 200 - 250 thousand torque units from the origin, based on my very simple world.
I think having the calculation as F64's is making things easier, so I hope that approach will continue to work. I hope your assignement is going better by the way!
Demolishun, That's a good point, certainly! I think though that there is a certain line that you draw the distinguishes a project as a "game" or a "simulation". Technically, I could just write a C++ program to display a list of numbers, but I wanted to have some 3D simulation work going on as well. I suppose, for the project I'm working on, as long as it's "close enough" to the numbers to make sense, that should work.
04/09/2013 (11:51 am)
Daniel, No apologies neccesary at all, I think we've all been there! I know I have! I have done some more testing, and things seem fine out to my chosen world limit, 100,000 torque units. There is some jitter on the camera, but not enough to be a problem. It only starts to be really noticeable around 200 - 250 thousand torque units from the origin, based on my very simple world.
I think having the calculation as F64's is making things easier, so I hope that approach will continue to work. I hope your assignement is going better by the way!
Demolishun, That's a good point, certainly! I think though that there is a certain line that you draw the distinguishes a project as a "game" or a "simulation". Technically, I could just write a C++ program to display a list of numbers, but I wanted to have some 3D simulation work going on as well. I suppose, for the project I'm working on, as long as it's "close enough" to the numbers to make sense, that should work.
#12
What will be cool about this project is you can go to town on the visuals. The reason is that there is going to be very few objects in the scene. So you can add a lot of detail. Like lots of particle emitters.
Keep us posted and certainly show us a video of the result! :)
04/09/2013 (4:28 pm)
@Jack,What will be cool about this project is you can go to town on the visuals. The reason is that there is going to be very few objects in the scene. So you can add a lot of detail. Like lots of particle emitters.
Keep us posted and certainly show us a video of the result! :)
#13
I had a 4096 X 4096 texture for the sky and the Earth, but I am now having memory problems, I may have to reduce those.
I'll definitely show a video or some pics when it's done, thanks for your interest!
04/10/2013 (11:34 am)
Yeah, I realise that. I am using some NASA high res textures for the Milky Way Skybox, the Earth, and the other planets. That's one thing I love about NASA, all of their images are hugely detailed and have no licence!I had a 4096 X 4096 texture for the sky and the Earth, but I am now having memory problems, I may have to reduce those.
I'll definitely show a video or some pics when it's done, thanks for your interest!
#14
Jack: Definitely interested in seeing how this goes. Good luck with it! I've sort of always wanted to do a space game... anyway. Oh, and the assignment went fine in the end.
(Demolishun: Not sure if you're much of a MATLAB fan, but I am resoundingly not. And what did I use instead for this assignment? Python, SciPy and Matplotlib :D.)
04/11/2013 (3:20 pm)
Demolishun (I think calling you Frank is more confusing at this point ;P): I had the same realisation a while ago. Probably while arguing with Twisted Jenius about AI :P. Once you learn to accept the illusion, you can be far more productive, I found!Jack: Definitely interested in seeing how this goes. Good luck with it! I've sort of always wanted to do a space game... anyway. Oh, and the assignment went fine in the end.
(Demolishun: Not sure if you're much of a MATLAB fan, but I am resoundingly not. And what did I use instead for this assignment? Python, SciPy and Matplotlib :D.)
#15
I really like SciPy and Matplotlib. I have a partially working fractal explorer built with that. Eventually I will release that for people to play with. It is a nice example of using OpenCL with numpy.
04/11/2013 (6:09 pm)
I never did mess with MATLAB. I know a lot of engineers loved it. Just never got into it. I did play with Labviews a bit and did some work with it to simulate different things. I really like SciPy and Matplotlib. I have a partially working fractal explorer built with that. Eventually I will release that for people to play with. It is a nice example of using OpenCL with numpy.
#16
Here is a possibility:
-As suggested by others, move the world, not the rocket.
-Remove from simulation objects that are too far away, KSP for instance remove ships that are further away than a couple kilometers from the ship you do control.
-I'm not sure how you can do this in torque, but a system of 3D skyboxes/render to texture could be handy here, because all the celestial bodies you are seeing from your point of view don't need to actually exist in the game world.
04/15/2013 (6:20 am)
You cited KSP as your example, i think you might wanna look into how "they" achieve it, because you can be sure that unity doesn't have any kind of "magic" bullet to tackle the issue of stellar distances.Here is a possibility:
-As suggested by others, move the world, not the rocket.
-Remove from simulation objects that are too far away, KSP for instance remove ships that are further away than a couple kilometers from the ship you do control.
-I'm not sure how you can do this in torque, but a system of 3D skyboxes/render to texture could be handy here, because all the celestial bodies you are seeing from your point of view don't need to actually exist in the game world.
#17
@Kyrah - I like the dynamic skybox idea but I think you could actually fake "near" bodies as particles or billboards until you are close enough. That way bodies that are far away but still close enough to notice motion relative to your movement could be rendered cheaply and wouldn't actually require rendering to texture.
And NASA always has huge piles of data lying around - it's great!
I have to agree with the sentiment expressed in the original post - real physics make for a very frustrating game when it comes to space flight. There was a game called Mantis a good fifteen years or so ago that tried that - combat was extremely difficult and I never did manage to successfully dock after that first mission. So, perhaps make docking an automated process, or at least give the option. I can't see wanting to spend the time matching velocities and rotations and then easing in for the lock more than once, personally.
04/15/2013 (8:02 am)
@Daniel - AI is an area where "real" is currently impossible so I'm sure TJ had some interesting things to say there! AI is literally all smoke and mirrors right now - your job is to make your agents seem smart, not necessarily be smart.@Kyrah - I like the dynamic skybox idea but I think you could actually fake "near" bodies as particles or billboards until you are close enough. That way bodies that are far away but still close enough to notice motion relative to your movement could be rendered cheaply and wouldn't actually require rendering to texture.
And NASA always has huge piles of data lying around - it's great!
I have to agree with the sentiment expressed in the original post - real physics make for a very frustrating game when it comes to space flight. There was a game called Mantis a good fifteen years or so ago that tried that - combat was extremely difficult and I never did manage to successfully dock after that first mission. So, perhaps make docking an automated process, or at least give the option. I can't see wanting to spend the time matching velocities and rotations and then easing in for the lock more than once, personally.
#18
I can probably post a few screens soon enough, once I get the orbital mechanics, Keplers laws, etc working. It's difficult to see if an orbit is working properly when you are talking about such vast distances, you can't really see the object.
@Kyrah: Was KSP Made with unity? I didn't realise that, I thought they used their own engine for it. That does make things a lot more attainable at least!
I am jealous of their fancy spherical terrain, but I won't start *another* "Can I do this with T3d...." discussion on that!
I like the idea of moving the world, not the rocket, I think I might end up using that. I intend to have a very small world, basically just the planetary bodies and the rocket, so moving a handful of objects would be trivial.
I have experimented with render to texture in T3D before (for another space game actually) and got it working, but it was a bit of a hack cobbled together from a few different resources.
I am currently using the technique suggested in the excellent article Daniel posted to handle "distant" objects by positioning them closer, but scaling them down in proportion to the distance. It's working very well!
@Richard - For some reason your description of Mantis's docking system reminds me of the Angry Video Game Nerds review of landing the plane on Top Gun! But yeah, realistic physics will appeal to a small subset of the gaming community, but they are loyal followers. I enjoy submarine simulation games, and there are still people playing games that have been out 10 years or more! Your average "shooter" has a shelf life of maybe six months?
04/15/2013 (10:35 am)
Thanks for all the replies! I can probably post a few screens soon enough, once I get the orbital mechanics, Keplers laws, etc working. It's difficult to see if an orbit is working properly when you are talking about such vast distances, you can't really see the object.
@Kyrah: Was KSP Made with unity? I didn't realise that, I thought they used their own engine for it. That does make things a lot more attainable at least!
I am jealous of their fancy spherical terrain, but I won't start *another* "Can I do this with T3d...." discussion on that!
I like the idea of moving the world, not the rocket, I think I might end up using that. I intend to have a very small world, basically just the planetary bodies and the rocket, so moving a handful of objects would be trivial.
I have experimented with render to texture in T3D before (for another space game actually) and got it working, but it was a bit of a hack cobbled together from a few different resources.
I am currently using the technique suggested in the excellent article Daniel posted to handle "distant" objects by positioning them closer, but scaling them down in proportion to the distance. It's working very well!
@Richard - For some reason your description of Mantis's docking system reminds me of the Angry Video Game Nerds review of landing the plane on Top Gun! But yeah, realistic physics will appeal to a small subset of the gaming community, but they are loyal followers. I enjoy submarine simulation games, and there are still people playing games that have been out 10 years or more! Your average "shooter" has a shelf life of maybe six months?
#19
I also play old games! Unreal Tournament 2k4 is still one of my favorites. And parts of T3D are older than that. I have been watching for a good remake of System Shock - the one piece of modern gaming that they really needed for it was control mapping! It's almost unplayable as it is, though you can get it to run under DOSBox.
And the old Wing Commander games - along with the first Privateer - were great, too. Though Privateer 2 smelled strongly of caviar left under the front seat of a car for the month of July in Las Vegas....
04/15/2013 (1:04 pm)
Spherical terrain has been done in T3D - the guy said it was a pain in the butt to get it working right, though.I also play old games! Unreal Tournament 2k4 is still one of my favorites. And parts of T3D are older than that. I have been watching for a good remake of System Shock - the one piece of modern gaming that they really needed for it was control mapping! It's almost unplayable as it is, though you can get it to run under DOSBox.
And the old Wing Commander games - along with the first Privateer - were great, too. Though Privateer 2 smelled strongly of caviar left under the front seat of a car for the month of July in Las Vegas....
#20
04/15/2013 (2:08 pm)
I seem to remember a Star Wars game that had planetary landing/take off. I don't remember the name. I did a quick search and found this: www.infinity-universe.com/Infinity/index.php?option=com_content&task=view&am.... You might contact them and let them know you are doing a scientific program and ask if they have any pointers on doing seamless takeoff and landing on planets. 
Associate Ron Kapaun
3tdstudios.com
Since you are talking about a 'simulation' why worry about 'real world' numbers? Use a scale model and scale distances.
Unless of course, you are not interested in a sim, but an actual real world model.
Just a thought.
Ron