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
|
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) |
|