Reaching for the stars

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.


Background

Cquote1.png Can we make a New planet in FG, call it FlightGearium, and start a simulation colony on it?
— MIG29pilot (Jan 21st, 2016). Now that we have a new planet....
(powered by Instant-Cquotes)
Cquote2.png

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]


Cquote1.png 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.
— jonsberndt (Aug 6th, 2011). Re: Vostok-1.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Thorsten (May 22nd, 2011). Re: New Flight Gear Terrain Engine.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
Cquote2.png
Cquote1.png 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.
— bugman (Dec 17th, 2015). Re: Implementing moonlight (or not).
(powered by Instant-Cquotes)
Cquote2.png

Prototyping

Cquote1.png 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
— Hooray (Dec 17th, 2015). Re: Implementing moonlight (or not).
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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 )
— Hooray (Dec 17th, 2015). Re: Implementing moonlight (or not).
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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)
— Hooray (Dec 17th, 2015). Re: Implementing moonlight (or not).
(powered by Instant-Cquotes)
Cquote2.png

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

Canvasmodel2.png Canvas-model-element-rotated.png

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
  1. Hooray  (Jul 7th, 2015).  Re: .
  2. Thorsten  (May 19th, 2016).  Re: Space Shuttle .
  3. Thorsten  (May 20th, 2016).  Re: Space Shuttle .
  4. Hooray  (May 21st, 2016).  Re: Space Shuttle .