Talk:TerraGear roadmap
Planets
|
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) |
|
|
|
As it stands, simgear's reference ellipsoid is earth. Terragear uses these functions (a lot) when generating scenery. We'd need to be able to plug in the parameters for each planet...
#define _EQURAD 6378137.0
#define _FLATTENING 298.257223563
#define _POLRAD 6356752.3142451794975639668
#define _SQUASH 0.9966471893352525192801545
#define _STRETCH 1.0033640898209764189003079
#define E2 fabs(1 - _SQUASH*_SQUASH)
|
|
|
|
this work isn't in conflict with using terragear tools to generate other planets. A robust toolchain should be considered a prerequisite for any scenery generation |
|
|
|
right, but if someone wanted to do this, those are preprocessor macros that could be easily exposed/overridden via CLI flags - I mean, it's the equivalent of running sed against the SG/TG source trees to replace any references to the corresponding macros to a std::map<std::string, double> lookup table that gets populated during initialiation (i.e. values being defaulted to what they are now).
Alternatively, we could have a planet.xml file using the existing propertyList xml file dialect and let people create/provide such files for whatever they want to do. Replacing those constants is relatively straightforward compared to all the data manipulation and DEM processing that TG can already handle, and I guess there are quite a few other hard-coded assumptions in various parts of SG/FG and TG, too Then again, this is a long-standing idea, and even some of the original TG authors (think Curt) were tossing with such ideas - to see for yourself, search the archives for "TerraGear mars" or "TerraGear planets" The main reference thread dating back to early 2002: Getting settled in my new "home" / Mars Scenery (look for answers from Curt, Jon, David Megginson So preparing SG/TG to make such things possible would definitely be a worthwhile thing according to quite a number of discussions in the archives (many of which being inspired by X-Plane's Mars mode) - and with JSBSim already supporting custom atmosphere models, and given the recent revamped interest supporting spaceflight, why not ? :D It's seems we're already well on our way ... |
|
Next WS
Note that this page is discussing a new terragear toolchain - The 'master' branch. It is where we are trying completely new ideas, and using new tools like CGAL, and GDAL2.0. We don't have any known date when a world will be built using the master branch, as it isn't at all stable yet, and the changes needed in Simgear are not final. Once what we need changed in Simgear is nailed down, we'll probably wait 2-4 releases before releasing new scenery utilizing the needed SimGear changes.
In the meantime, the ws2.0 branch is being used to generate new world scenery releases. No new features are being added to the toolchain, just bug fixes. Martin, on the other hand does have some big changes in store with regards to the data being used :) See http://forum.flightgear.org/viewtopic.php?f=5&t=24038&hilit=NLCD
We plan on making the scenery 'forward compatible' in that the new features will be ignored by current simgear.
As far as .SPT, this will require a new fgviewer.
—This unsigned comment was added by Psadro_gm (Talk | contribs) 14:42, 13 July 2015 (UTC)