Reaching for the stars
| This article is a stub. You can help the wiki by expanding it. |
| Space flight |
|---|
| in FlightGear |
| Space Shuttle |
| Vostok-1 |
Background
|
Can we make a New planet in FG, call it FlightGearium, and start a simulation colony on it? |
|
Thorsten's approach for implementing the EarthView addon is sufficiently generic to also implement other celestial bodies like this - scenery itself is a different matter though, but the TerraGear tool chain will process pretty much any elevation data you throw at it and try to turn it into scenery (DEM for Mars being freely available)[1]
|
|
We do pretty well within the Earth atmosphere, and appear to be able to do orbital flight around Earth very nicely, too. Mars and the Moon will be future projects - it shouldn't take too much work to do that. Red Canyon Software has already made a Mars airplane simulator using JSBSim some years ago. |
|
|
|
I'm not sure about Moon or Mars - but I am fairly certain we have all we need to render a hires Earth model below a spacecraft in a low Earth orbit. |
|
|
|
rendering stuff in space is really easy the Celestia way - we can add as many textured spheres as we like. Planetary positions are tabulated, we can simply use these tables to look where to put them at any given time. I suppose even using our default engine to define moon landing sites is not a substantial issue, I am fairly sure once we can get into a Moon orbit that people can be persuaded to allow to re-center the default terrain and to use Moon textured landclasses.
As far as I have been told, Mathias is working on a more sophisticated low orbit rendering engine. Let's focus on getting stuff into Earth orbits, see if we can't do any docking maneuvers there, get an ISS 'static' (?) carrier (?) model into orbit and iron out all the glitches, and then see how to go to Moon. — Thorsten (Mar 24th, 2012). Re: Earthview - an orbital terrain rendering engine [v0.1].
(powered by Instant-Cquotes) |
|
|
|
The code I'm looking at is a few of the key parts of what needs to be adapted for landing on the moon! The ephemeris code, the lighting code, and the osg scene set up in the FG renderer. I was thinking of exactly what needs to be done for a moon landing (or orbit) as I was looking at all of this. |
|
Prototyping
|
|
given that there is so much interest in spacefllight recently, it would be cool to work out what else may end up being useful sooner or later if exposed at the property tree level, i.e. to support earthview-like approaches, without having to re-implement/work around rendering logic that already resides elsewhere - even if that just means making things better configurable (or entirely optional using dedicated draw masks), while providing for a seamless transition between the corresponding approaches |
|
|
|
an "architecture astronaut" might end up wondering what would be required to support arbitrary celestial bodies (think Moon, Mars) by exposing those using a property-configurable texture and corresponding parameters for an osg::Shape based array of LOD-enabled spheres :D )
For instance, imagine a custom PropertyList-XML dialect for instantiating celestial bodies by specifying a position, sie, and 3D models/texture sheets for different LODs. And yes, I would be willing to help work out the SGSubsystem/C++ and OSG magic/patches to make that happen in a generic fashion. We already have support for adding models procedurally via /models, we can dynamically load/create/modify textures using Canvas, and we do support effects & shaders - so it would mainly seem like a matter of reviewing those features to come up with an interface so that arbitrary celestial bodies can be supported using these existing features. (note that this seems to be how celestial bodies in Orbiter are structured: http://www.orbiterwiki.org/wiki/Category:Add-ons ) |
|
|
|
Note that regardless of recent interest in supporting this, this is a really long-standing idea (just search the archives for "moon" or "mars" to see for yourelf).
In my opinion it would be a terrific idea to review the corresponding code and see if/what and how things could be adapted to become increasingly configurable - if breakage/backward compatibility should turn out to be problematic, we could introduce a dedicated subsystem - pretty much based on the approach/features that Thorsten is using in Earthview The basic idea being to encapsulate a light source, and LOD nodes for different ranges/visibility and texture sheets, in conjunction with effects/shaders that are to be applied. This would be in line with how many other features in FlightGear started out being hard-coded, were then moved to become property-configurable, and finally become fully instantiable/modifiable at run-time (AI traffic, models, Canvas, camera views) |
|
Canvas
the Shuttle avionics is definitely the wrong place to learn the basics of orbital mechanics... it's all not very visual[2]
Ideally you would visualize it in 3d space, with the orbits as lines projected around Earth and the ability to turn and zoom.
Otherwise the two most useful projections are groundtrack (for inclination, node crossing and what you should see looking out of the window) and the projection orthogonal to the orbital plane (basically the plot you show).
There's no technical issue preventing me from doing the projections at least (Orbiter uses a series of similar generic MFDs), but my priority with the Shuttle really is to re-create the original avionics. I was more commenting on the fact that the avionics makes it hard to really know your orbital state - there's no moving map, inclination isn't displayed at all, node crossing time is on a different display than apoapsis and periapsis - the Shuttle doesn't seem to have a single summary display 'this is my orbit'.
Of course, it doesn't also have any real capability to change orbit, so your orbit is always the one you launched into modulo small corrections.
So from a pedagogical POV the Shuttle is a poor vehicle to learn the basics of orbital mechanics, and the Orbiter Delta Glider with it's vastly higher Delta v reserves is much better for learning (Vostok is even less suitable, it hardly has any maneuvering capability).[3]
We do have experimental code that also allows Canvas to be used on conjunction with arbitrary 3D models. Basically, what it will do is add a new Canvas "element type", called "model", where you can specify a filename of a 3D model, and then it will add the whole thing under a osg::PositionAttitudeTransformMatrix, so that you can freely position/scale and tranform the whole 3D model arbitrarily by accessing a few properties (that are then mapped to the osg::PAT methods to rotate, scale etc) - several elements can be added to the same "scene" Howto:Extending Canvas to support rendering 3D models
it may make sense to keep this in mind, especially given bugman's "directional moonlight" effort, i.e. conceptually you could even load your EarthView models/textures into the same scene, and "animate" it using a handful of properties (obviously, there are not the conventional FG light sources (sun) or the skydome etc)[4]
References
References
|