Reaching for the stars: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 20: Line 20:
{{FGCquote
{{FGCquote
|1= 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
|1= 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
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=269035#p269035
  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Dec 17th, 2015
  | added  = Dec 17th, 2015
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= an "architecture astronaut" might end up wondering what would be required to support arbitrary [http://www.orbiterwiki.org/wiki/Category:Celestial_bodies 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 &amp; 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 http://www.orbiterwiki.org/wiki/Category:Add-ons] )
|2= {{cite web
|2= {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=269035#p269035
   | url    = http://forum.flightgear.org/viewtopic.php?p=269035#p269035

Revision as of 20:50, 12 January 2016

This article is a stub. You can help the wiki by expanding it.


Background

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