Have you seen Orbiter ? It's a spaceship simulator. Best and probably only one available. Unfortunately it's developed by one man and the source is closed (not for public eyes). Adding to that, it uses DirectX 7 for rendering (platform specific - Windows) witch is quite old by now.
Official website of Orbiter: http://www.celestiaproject.net/celestia/
A good video of Orbiter: http://mustard27.free.fr/orbiter2004.wmv .. you must see it. See http://mustard27.free.fr/ for more.
If I'd be a (good) programmer and knew anything about astrophysics, I would take Celestia as a base and start building a spaceship simulator on it while taking out everything of today's hardware. Anyone up to it ?
Orbiter like addon/project - anyone up to it ?
-
ElPelado
- Posts: 862
- Joined: 07.04.2003
- With us: 21 years 11 months
- Location: Born in Argentina
- Contact:
The official website is Orbiter
---------X---------
EL XENTENARIO
1905-2005
My page:
http://www.urielpelado.com.ar
My Gallery:
http://www.celestiaproject.net/gallery/view_al ... y-Universe
EL XENTENARIO
1905-2005
My page:
http://www.urielpelado.com.ar
My Gallery:
http://www.celestiaproject.net/gallery/view_al ... y-Universe
I had an idea which might go in a similar direction. My idea was to bug the author of Celestia long enough 
that he provides some sort of 'plug-in interface' to Celestia.
This interface would allow a plug-in to take control of certain apsects of Celestia, and maybe read data from Celestia.
A bit more detailed:
1. The 'controlling part' of the plug-in can control the (simulated) time/date in Celestia and maybe also viewpoint/direction. It can also provide new 'dynamic objects' to Celestia, giving name/type/mesh/texture/position/orientation to Celestia for each of the new objects. Just the same as if these objects. Just the same as if these objects were defined in an ssc-file. With the only difference, that objects in an ssc-file have a 'static' behavior while objects which are defined (and repeatedly re-defined) on-the-fly by the plug-in can react to external stimuli. For example, a plug-in might have it's own GUI where the user could choose to apply thrust, rotate the spaceship, whatever.
A plug-in might chose to advance the time at 1x speed (or faster) in forward direction only, in case of a spaceship simulation (as it does not want to keep all past positions of the spaceship, which would be required for reverse time or arbitray time settings).
Celestia would ask the plug-in for new object data each frame. All dynamic object data may change at any time, including disappearance of objects and appearance of new ones (for example, if a spaceship decides to interfere with an asteroid).
2. The data-reading part might allow the plug-in to find all 'built-in' space objects in a certain radius around a certain point. 'Built-in' space objects are the things which are read from ssc-files. Like the Sun, the Moon, Earth, and the asteroid which interfered with the spaceship in the example above. A spaceship simulation plug-in may choose to ask for all objects in a radius of, lets's say 50 AUs, around the current position of teh simulated spaceship. In order to estimate if the spaceship has to replaced by space debris (because of that darn asteroid), or to calculate gravity pull. Now, I know that Celestia does not hold mass data for objects. Perhaps this could be added to the scc files. Or the plug-in could take the namse of the objects and provide it's own mass data if it want to. If the system in question is the solar system, the plug-in programmer would have to set up an internal table with all masses for the different space objects.
3. If the data-reading interface part is omitted, the plug-in would need to generate it's own solar system. No big deal, i think, but why do things twice if there might be a possiblity to get all data (or most of it) from Celestia? Of course, the plug-in cannot only provide spaceship objects to Celestia, it could also provide complete star systems. So one could simulate the funny behavior of a planet in a multi-star system, for example.
that he provides some sort of 'plug-in interface' to Celestia.
This interface would allow a plug-in to take control of certain apsects of Celestia, and maybe read data from Celestia.
A bit more detailed:
1. The 'controlling part' of the plug-in can control the (simulated) time/date in Celestia and maybe also viewpoint/direction. It can also provide new 'dynamic objects' to Celestia, giving name/type/mesh/texture/position/orientation to Celestia for each of the new objects. Just the same as if these objects. Just the same as if these objects were defined in an ssc-file. With the only difference, that objects in an ssc-file have a 'static' behavior while objects which are defined (and repeatedly re-defined) on-the-fly by the plug-in can react to external stimuli. For example, a plug-in might have it's own GUI where the user could choose to apply thrust, rotate the spaceship, whatever.
A plug-in might chose to advance the time at 1x speed (or faster) in forward direction only, in case of a spaceship simulation (as it does not want to keep all past positions of the spaceship, which would be required for reverse time or arbitray time settings).
Celestia would ask the plug-in for new object data each frame. All dynamic object data may change at any time, including disappearance of objects and appearance of new ones (for example, if a spaceship decides to interfere with an asteroid).
2. The data-reading part might allow the plug-in to find all 'built-in' space objects in a certain radius around a certain point. 'Built-in' space objects are the things which are read from ssc-files. Like the Sun, the Moon, Earth, and the asteroid which interfered with the spaceship in the example above. A spaceship simulation plug-in may choose to ask for all objects in a radius of, lets's say 50 AUs, around the current position of teh simulated spaceship. In order to estimate if the spaceship has to replaced by space debris (because of that darn asteroid), or to calculate gravity pull. Now, I know that Celestia does not hold mass data for objects. Perhaps this could be added to the scc files. Or the plug-in could take the namse of the objects and provide it's own mass data if it want to. If the system in question is the solar system, the plug-in programmer would have to set up an internal table with all masses for the different space objects.
3. If the data-reading interface part is omitted, the plug-in would need to generate it's own solar system. No big deal, i think, but why do things twice if there might be a possiblity to get all data (or most of it) from Celestia? Of course, the plug-in cannot only provide spaceship objects to Celestia, it could also provide complete star systems. So one could simulate the funny behavior of a planet in a multi-star system, for example.
The "plugin interface" is called "the Lua programming language" which is used in CELX scripts.
Harald (Celestia Forum Member ID "Harry") is the person to persuade to implement more features in the Lua/Celestia interface. Of course, he then has to persuade the rest of the developers that those features are useful. I suspect that well thought out features that are relatively straight forward to add are the most likely to be accepted.
Many of the features in Celestia are developed by consensus, with Chris Laurel having the final approval.
Harald (Celestia Forum Member ID "Harry") is the person to persuade to implement more features in the Lua/Celestia interface. Of course, he then has to persuade the rest of the developers that those features are useful. I suspect that well thought out features that are relatively straight forward to add are the most likely to be accepted.
Many of the features in Celestia are developed by consensus, with Chris Laurel having the final approval.
Selden