TerraGear roadmap: Difference between revisions
No edit summary |
No edit summary |
||
(14 intermediate revisions by 4 users not shown) | |||
Line 5: | Line 5: | ||
{{Template:Non-stable|version= | {{Template:Non-stable|version=4.x|progress=10}} | ||
{{Scenery Core Development}} | |||
World Scenery 2.0 has been released. After 2 1/2 years of development, the tool-chain is considered stable. Although WS2.0 will continue to receive updates, and bug fixes, I'd like to start planning for the next major overhaul. | World Scenery 2.0 has been released. After 2 1/2 years of development, the tool-chain is considered stable. Although WS2.0 will continue to receive updates, and bug fixes, I'd like to start planning for the next major overhaul. | ||
Line 30: | Line 32: | ||
It would be nice to have all landclass images and this single per tile image to all have the same resolution, so we could use a texture array. This allows us to draw an entire tile (other than linear road / rail / stream ) in one openGL draw call. | It would be nice to have all landclass images and this single per tile image to all have the same resolution, so we could use a texture array. This allows us to draw an entire tile (other than linear road / rail / stream ) in one openGL draw call. | ||
== Status == | |||
{{FGCquote | |||
|1= A brief status update on what I am currently doing on the master branch: | |||
# It's been a year since I started working on LOD ( using Mathias' .SPT directory hierarchy ). This exposed a major weakness in the toolchain used for ws2.0 - It triangulated landclass polys individually instead of whole tile at a time. This was necessary, as triangulating the whole tile with OSM roads cut-in was very unstable. I couldn't get any library to succeed for more than a few hundred tiles. But when trying to simplify these tiles, large holes get generated as the mesh is non manifold. | |||
# I 'started from scratch' with a couple assumptions: | |||
* all vector data will be draped over the terrain - although we may still cut in some smoothing polys * airports will be draped over a smoothed terrain within the airport boundaries ( changing airport layout will not require new tg-construct run unless boundary is changed ) | |||
* tile mesh must be manifold | |||
* all intermediate files can be visualied with GIS tools ( request from martin ) | |||
I estimate I'm about 1 month away from having tg-construct generating a base mesh. | |||
Having a mesh to work with ( in CGAL ) gives me a couple feature for 'free'. | |||
* face and point normals can be generated from CGAL | |||
* local differentials can also be generated ( request from Thorsten Renk - terrain curvature ) | |||
I have a large 12x10 degree section of Europe shapefiles from mapserver. Once I have a scenery, I'll put chunks of it on dropbox to experiment with. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=280092#p280092 | |||
| title = <nowiki>Re: Is the Scenery Workflow broken?</nowiki> | |||
| author = <nowiki>psadro_gm</nowiki> | |||
| date = Mar 21st, 2016 | |||
| added = Mar 21st, 2016 | |||
| script_version = 0.25 | |||
}} | |||
}} | |||
== Progress == | == Progress == | ||
Line 41: | Line 67: | ||
| simgear || btg file vertex attribute support || {{Progressbar|60}} | | simgear || btg file vertex attribute support || {{Progressbar|60}} | ||
|- | |- | ||
| genapts || elevation source || {{ | | genapts || elevation source || {{Progressbar|100}} | ||
|- | |- | ||
| genapts || runway relative texture coordinates || {{pending}} | | genapts || runway relative texture coordinates || {{pending}} | ||
Line 57: | Line 83: | ||
|-genapts || support no bezier - low level detail for pavements || {{pending}} | |-genapts || support no bezier - low level detail for pavements || {{pending}} | ||
|- | |- | ||
| genapts || airport as landclass || {{ | | genapts || airport as landclass || {{Progressbar|90}} | ||
|- | |- | ||
| | | genapts || support intersecting linear features instead of clipping || {{Progressbar|90}} | ||
|- | |||
| gdalchop || support arbitrary tile sizes / directory structure || {{Progressbar|10}} | |||
|- | |- | ||
| imgchop || new tool to support per tile raster images based on a global image. Could be used to chop i4dnf's ocean depth image || {{pending}} | | imgchop || new tool to support per tile raster images based on a global image. Could be used to chop i4dnf's ocean depth image || {{pending}} | ||
Line 67: | Line 95: | ||
| hgtfit || port from terra to CGAL mesh simplification (optional / cleanup) || {{pending}} | | hgtfit || port from terra to CGAL mesh simplification (optional / cleanup) || {{pending}} | ||
|- | |- | ||
| ogrdecode || support arbitrary tile sizes / directory structure || {{ | | <s>ogrdecode</s> || <s>support arbitrary tile sizes / directory structure</s> || {{not done}} | ||
|- | |- | ||
| tgconstruct || generate per tile raster image of landclass data || {{pending}} | | tgconstruct || generate per tile raster image of landclass data || {{pending}} | ||
Line 77: | Line 103: | ||
| tgconstruct || generate landclass triangles with geodetic texture coordinates and per tile origin coordinates || {{pending}} | | tgconstruct || generate landclass triangles with geodetic texture coordinates and per tile origin coordinates || {{pending}} | ||
|- | |- | ||
| tgconstruct || arbitrary tile sizes / directory structure || {{ | | <s>tgconstruct</s> || <s>arbitrary tile sizes / directory structure</s> || {{not done}} | ||
|- | |- | ||
| | | tg-lod || .spt directory heiarchy generation || {{Progressbar|50}} | ||
|- | |||
| tg-lod || add tile skirts to hide LOD gaps || {{pending}} | |||
|} | |} | ||
arbitrary tile sizes for ogrdecode and tgconstruct is no longer needed. Going forward, we will try to simplify generated BTGs instead of creating new ones based on simplified scenery. | |||
== Development Notes == | == Development Notes == | ||
A fairly large snag while developing secondary texture coordinates : tc scaling is done per material, and the scaling needs to be looked up by material name. | *A fairly large snag while developing secondary texture coordinates : tc scaling is done per material, and the scaling needs to be looked up by material name. Currently, the btg file stores lists of triangles/strips/fans under a common material name. A draped material may lie on multiple underlying materials. In the short term, my plan is to ignore texture coordinate scaling. The main use case for this is the linear features over airport pavements and runways. A quick check shows that these materials do not use tc scaling, so we should be ok. If we get to the point where we drape roadways over general terrain, however, we will need a real solution. | ||
Currently, the btg file stores lists of triangles/strips/fans under a common material name. A draped material may lie on multiple underlying materials. | |||
*Linear feature intersections are working, and committed to terragear/master. I'll post screenshots, and details of the algorithm shortly. | |||
*I want to refactor simgear/scene/tgdb/obj.cxx. Currently, it is saving most of the .btg in an inefficient format, along side the scenegraph equivelent, before building trees, lights, and random buildings. I am creating a new page here for discussion among interested parties: [[NewBTGLoader]] | |||
== preview == | == preview == | ||
Line 99: | Line 127: | ||
== Runtime Airport Generation == | == Runtime Airport Generation == | ||
{{WIP}} | <!-- {{WIP}} --> | ||
For now, please see the following discussions to learn more about plans to procedurally build airports at run-time: | |||
* [http://forum.flightgear.org/viewtopic.php?f=5&t=18985&p=176132&hilit=#p176151 Scenery Draping] | |||
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5331A2EC.8010701%40mindcontract.com/#msg32142890 Airport Runtime Generation-1] | * [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5331A2EC.8010701%40mindcontract.com/#msg32142890 Airport Runtime Generation-1] | ||
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAPi24C0700ezXOU5GQ8A9h8udiwOWa5xXG02kcYaftZS-yuq-Q%40mail.gmail.com/#msg32143720 Airport Runtime Generation-2] | * [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAPi24C0700ezXOU5GQ8A9h8udiwOWa5xXG02kcYaftZS-yuq-Q%40mail.gmail.com/#msg32143720 Airport Runtime Generation-2] | ||
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/0A90AC72-7461-4CC4-A5A7-6FD36AD48394%40mac.com/#msg32143737 Airport Runtime Generation-3] | * [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/0A90AC72-7461-4CC4-A5A7-6FD36AD48394%40mac.com/#msg32143737 Airport Runtime Generation-3] | ||
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5332EB0C.9060906%40mindcontract.com/#msg32147247 Airport Runtime Generation-4] | * [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5332EB0C.9060906%40mindcontract.com/#msg32147247 Airport Runtime Generation-4] | ||
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/537CBB58.2000707%40mindcontract.com/#msg32364995 Airport Runtime Generation-5] | |||
<!-- | |||
== Update as of Pre-3.6 == | |||
Martin Spott appears to be generating the world right now, We hope to have a new WS release before the end of 2015. | |||
--> | |||
{{Terra}} | {{Terra}} | ||
[[Category:Core development projects]] | [[Category:Core development projects]] |
Revision as of 14:49, 9 October 2016
Note:
This project is currently under active development. And we're looking for volunteers interested in contributing.
Mentors: psadro_gm (get in touch to learn more) |
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3). You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .This feature is scheduled for FlightGear 4.x. If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear. |
Scenery Core Development |
---|
Misc |
Misc |
World Scenery 2.0 has been released. After 2 1/2 years of development, the tool-chain is considered stable. Although WS2.0 will continue to receive updates, and bug fixes, I'd like to start planning for the next major overhaul.
For World Scenery 3.0, flightgear will have a LOD system for the underlying mesh. The good news is, this new system is already in simgear (thanks to Mathias), and has been tested with 'hand stitched' .btg files. So our job, is to update the tools to be able to generate the scenery automatically.
Ideally, we would like to have at least 4 levels of detail.
The highest detail level being identical to WS2.0.
The second level of detail maintains the same elevation mesh, but removes line data from both airports and terrain. Airports are still smoothed, and cut in to the terrain.
The third level of detail is a simplified mesh, with simplified airports (no bezier interpolation) created as landclass polys (runway, taxiway, and grass). To be determined, is how to simplify the landclass polygons. possibly combining a small area landclass with it's neighbor.
Optional fourth level and more LODs would be refinements to the third - lower res mesh, and more landclass combining)
The lowest detail level being a sphere with a global texture.
In the terragear toolchain, there are 3 main directories: Data, Work, and Output. The Work directory structure will be overhauled to handle arbitrary tile sizes. The output directory needs to match what simgear .SPT files expect.
After conversing with i4dnf, some extra ideas have come up to fix some of the long standing scenery issues. As we move to a new scenery structure, that may not be 100% backward compatible, we should be able to add some additional capabilities to the .btg file format. NOTE: the .btg file format is extensible, so this may not require major changes and 'could' be backward compatible. Experimentation needed:
The first idea is separating the runway markings from the pavement. We have this somewhat working now, but the pavement shader is completely clueless about the marking shader. and bump mapping / dirtying effects cannot be normalized between the line and pavement - leading to visual artifacts. The marking shader needs to know the underlying pavement origin. To do this, the .BTG file needs to support multiple texture coordinates. 1 primary set to look up the line texture in the texture atlas, and another set relative to the origin of the pavement. i4dnf would also like to add dirty / tire marks to the runways. To do this, he needs to know where in the runway polygon, the thresholds are. In openGL, a vertex attribute would be passed to the shader to relay the information. The btg format should be expanded to allow vertex indices (of a triagle) to have attributes.
The second idea is to use multiple tcs to allow landclass shaders to know where in a tile they are located. If we have a per tile raster image with the landclasses encoded, then the borders between landclasses can be smoothed / modified by the shaders. We could also encode regional definitions into the same raster image to support irregular shaped region encoding. probably 8 bits for landclass, and 8 bits for region is enough.
It would be nice to have all landclass images and this single per tile image to all have the same resolution, so we could use a texture array. This allows us to draw an entire tile (other than linear road / rail / stream ) in one openGL draw call.
Status
Progress
The below table is my first attempt at a work item breakdown. I imagine we'll need to add / remove entries as work progresses.
arbitrary tile sizes for ogrdecode and tgconstruct is no longer needed. Going forward, we will try to simplify generated BTGs instead of creating new ones based on simplified scenery.
Development Notes
- A fairly large snag while developing secondary texture coordinates : tc scaling is done per material, and the scaling needs to be looked up by material name. Currently, the btg file stores lists of triangles/strips/fans under a common material name. A draped material may lie on multiple underlying materials. In the short term, my plan is to ignore texture coordinate scaling. The main use case for this is the linear features over airport pavements and runways. A quick check shows that these materials do not use tc scaling, so we should be ok. If we get to the point where we drape roadways over general terrain, however, we will need a real solution.
- Linear feature intersections are working, and committed to terragear/master. I'll post screenshots, and details of the algorithm shortly.
- I want to refactor simgear/scene/tgdb/obj.cxx. Currently, it is saving most of the .btg in an inefficient format, along side the scenegraph equivelent, before building trees, lights, and random buildings. I am creating a new page here for discussion among interested parties: NewBTGLoader
preview
I'm getting close to a merge request for simgear changes so we can add bump maps and 'dirty maps' (i.e. skid marks) to the runways and taxiways that allow the same map to be used on both the draped details, and the pavement.
Runtime Airport Generation
For now, please see the following discussions to learn more about plans to procedurally build airports at run-time:
- Scenery Draping
- Airport Runtime Generation-1
- Airport Runtime Generation-2
- Airport Runtime Generation-3
- Airport Runtime Generation-4
- Airport Runtime Generation-5
|