Reaching for the stars: Difference between revisions
No edit summary |
|||
Line 49: | Line 49: | ||
|1= 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). | |1= 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#|Earthview]] | 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#|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. | 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) | 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) |
Revision as of 20:51, 12 January 2016
This article is a stub. You can help the wiki by expanding it. |
Space flight |
---|
in FlightGear |
Space Shuttle |
Vostok-1 |
Background
Prototyping
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) |