Using OSM Vector Data in FlightGear
| Started in | 11/2013 |
|---|---|
| Description | Improved autogen support for FlightGear using OSM data |
| Contributor(s) | radi, vanosten, Soitanen, portreekid |
| Status | Under active development as of 02/2016 |
| Topic branches: | |
| $FG_SRC | https://gitlab.com/osm2city/osm2city/ |
| fgdata | https://gitlab.com/osm2city/osm2city-data/ |
| OpenStreetMap use in FlightGear |
|---|
Background
This is referring to procedural/autogen scenery generation/enrichment (buildings, cities, roads, bridges and power lines) via OSM data.
Actually, using OSM data isn't really conflicting with "autogen" at all - it just requires the built-in autogen component to expose an interface, so that the placement heuristics can be affected according to the OSM vector data.
After looking at the website, I do understand that the approach taken by OSM2XP is a little different, in that it creates the buildings externally and then provides precompiled scenery for use by XP (?) - obviously, that is because OSM2XP is an external tool, written in Java.
That's actually similar to how FlightGear uses precompiled scenery which is created using TerraGear. XPlane on the other hand, creates airports, runways and taxiways procedurally at runtime.
We previously talked about exposing the placement heuristics, so that a Nasal script could affect the placement algorithm in some way - once that is supported, a Nasal script could place buildings while honouring OSM vector data. The probem is that (as usual) people pull into different directions.
Actually, we've seen a number of related developments - such as IntelQube's "Instant City" addon, or the more recent effort by Rickbritto. So people are clearly interested in this. Like Thorsten also rightly pointed out, people are pulling into different directions, which are unfortunately somewhat conflicting. But overall, it's pretty obvious that people are interested in extending the scenery and populating it with buildings in particular.
Stuart has a 'random with certain moderately simple rules' algorithm with the aim to be as fast as possible without generating nonsense like overlapping or floating buildings. This probably means you can't have fancy night illumination, too much individual configuration or realistic arrangements beyond a point, and all placement info is encoded in the texture sheet (that's not a bad feature, because that means random buildings stay in sync with the underlying sheet!)
We've seen quite a few people working on this independently in 2013 and making very promising progress in different fields. Many of them being contributors able to build from source, and able to write C++ code. TorstenD mentioned a while ago, that he was also considering porting PixelCity to use Stuart's random buildings system (and thus, OSG) for these purposes. Now, we also have osgEarth as a secondary scenery engine, so it makes sense to coordinate things accordingly.
Besides, we also have guys working on improved generation of procedurally-created vegetation, road networks, bridges and buildings/cities, which are other areas that could greatly benefit from a little coordination with osgEarth support in FlightGear, to ensure that a generic approach is found over time and to avoid a "technology lock-in", like some people are complaining about related to Rembrandt.
Please see thee ongoing discussion at: http://wiki.flightgear.org/User_talk:F-JJTH#Implement_an_OSM_client_in_FG
The main point being that we should work out a way to expose the underlying APIs to FG, so that these can be used as the common back-end for OSM vector data access (probably via Tom's cppbind) - so that related efforts can benefit without having to duplicate work, and without having to use approaches that are not native to FG (such as python code).
As could be seen in 2013, we have an unprecedented number of people interested in this currently, who are able to contribute to the code - so if we could coordinate this a little, this could work out as well as the NavDisplay effort, which had a similar amount of people interested in related things.
We now have so many people doing work related to this, that the wiki is the only sane place to coordinate things - because some use the devel list, others only the forum - and others only IRC ... so better use the wiki for now.
Also, the wiki is the only future-safe method to organize things, in case we need to drop the effort for a "while" (weeks, months or years).
Objective
Any OSM-processing should ideally be exposed via FG APIs, so that OSM data can be processed by other subsystems (either via fgcommands, extension function or cppbind), to ensure that we cannot just visualize OSM data using the Canvas, but also use it affect the placement heuristics in Random Buildings according to Stuart's plans [1] or interface OSM with osgEarth.
Status (01/2015)
|
I've been working on a tool that combines all the static models within a .stg file into a single .osgb file using quadtrees, texture atlases etc. to make it as efficient as possible.
|
|
|
|
I've written a little tool that does the following: — Stuart Buchanan (2015-01-13). [Flightgear-devel] STG model merge tool.
(powered by Instant-Cquotes) |
|
|
|
The main benefit of this is that it would allow the output of osm2city to be uploaded into the scenery object database and distributed via Terrasync. At the moment this isn't possible because the database requires models to be uploaded individually, and the large number of individual models produced by osm2city (unless various combine options are enabled) has too much performance impact.
|
|
|
|
The idea is that this tool would be run on the scenery server itself so the data downloaded via terrasync would already be merged.
|
|
|
|
There's still a place for random buildings, but I think they would be generated offline and similarly placed in the scenery DB. PostGIS has the function available that would allow us to easily generate building locations based on the OSM street data. We'd probably move away from the shader-based instantiated buildings and instead just have big meshes. This has the advantage of allowing collision detection, helicopter landing etc. but obviously uses more memory.
|
|
|
|
I'd like to try to initiate a strategy discussion about how we should handle cities in the future. Right now, there's tools like osm2city.py, there's the urban shader, there are random buildings, there are static buildings (Paris...), there's streets painted on the texture, streets as part of the vector mesh and (experimental) streets draped onto the terrain....
Which is fine as long as these approaches aren't mutually exclusive, but unfortunately we left that state, so I think we should eventually have a strategy how to proceed. — Renk Thorsten (2014-11-19). [Flightgear-devel] Future city terrain strategy (see full posting).
(powered by Instant-Cquotes) |
|
|
|
Moving to ‘real’ OSM data for this seems the best plan - for all the reasons you list. It also have a very nice ‘user upgrade path’ - not enough buildings in your area? Submit them to OSM!
— James Turner (2014-11-19). Re: [Flightgear-devel] Future city terrain strategy (see full posting).
(powered by Instant-Cquotes) |
|
If you are interested in pre-processing and enriching vector data, you'll probably want to get in touch with some of the other folks who have done similar things, such as the osm2xp project.
Also, if that's definitely your main interest, you may also want to look at TerraGear, which is the "FG scenery compiler suite" to build scenery.
That said, a "pre-processor" could also be implemented as a native FG component, i.e. within the main fgfs executable - quite probably even as a fully threaded component, so that pre-processing could take place in a simple worker thread using exclusive read/write access.
I'm just saying this because "compiling" scenery from scratch is generally understood not to be a simple task for most people here. In other words, even if you should come up with such an OSM-pre-processor to enrich FG scenery, the resulting data may not be usable by most people - not without an official scenery rebuild at least.
Thus, having a component that would be running inside (or next to) FG would be easier from a deployment point of view.
Efforts
Random Buildings (Stuart)
Stuart is the developer of the random buildings code (and the random trees), so he's got plenty of experience with procedural creation of scenery elements. To understand the C++ side of things, you'll definitely also need to be familiar with OpenGL and preferably OSG, i.e. 3D graphics and 3D maths. But even if that's not your thing, reusing Stuart's code to the largest possible degree would definitely be a good idea, because he's already tackled many of the difficult issues - and creating an interface (scripting or property tree) is definitely simpler than writing such a system from scratch.
FlightGear's random building code is implemented as part of the SimGear library, in the tgdb folder: flightgear/simgear/next/simgear/scene/tgdb
The most important file is SGBuildingBin.cxx: flightgear/simgear/next/simgear/scene/tgdb/SGBuildingBin.cxx
Probably the best way to do this would be to separate the "random" from the "buildings" in the curent random buildings, and use the OSM data as an alternative data source for the latter.
However, before we do that I need to get the PageLOD working well enough that I can replace the (relatively) memory efficient instantiation approach with the original memory-heavy implementation of random buildings which allows better control over each individual building.
I'd suggest to get in touch with TheTom or Zakalawe and use TheTom's cppbind framework (see simgear/nasal/cppbind) to expose the building generation hooks to scripting space, that would then allow arbitrary input data to be used.
Random Buildings Scripting Interface (Hooray, Thorsten)
|
|
let's assume that downloading the footprint of an airport terminal building from OSM/overpass turbo is fast enough. Can Nasal create an object and put into the scenery in RAM/on the fly without writing an .ac file to the filesystem ? |
|
This would require some form of interface, so that stuart's random buildings can be aligned using networks of roads, rivers, railway tracks - like Gijs said, the randomness would be gone then
Hooray: we have had a fair share of discussions related to this. Stuart's work has certainly paved the way for even more improvements. Like I mentioned, I would be interested in exposing the creation of procedural scenery to scripting space (or even just the property tree) so that customizing this aspect of FG is no longer possible purely from C++ space.
it would be great to have a way to dynamically assemble buildings and blocks of buildings and then combine them into a single geometry, so that the performance hit is decreased. But that would obviously require exposing some more hooks to Nasal scripts.
Now, what Stuart has done already addresses the needs in C++ space. Adding a Nasal interface to existing C++ code is much easier that way, and certainly easier than creating the whole thing from scratch.
And have better access to the placement heuristics, or rather the underlying criteria would be great. That's not just related to "materials" anymore, but also access to "ground networks", such as roads, rivers, railways.
The good thing is, adding a Nasal interface to make existing C++ code accessible is fairly trivial and much simpler than writing the original backend code. And this is clearly not a task that needs to be done by the developer of the original C++ code, as can be seen by all the existing Nasal extension functions, most of which were added by people who didn't really write the corresponding backend code.
A Nasal script that may query a scenery tile and get detailed information on these properties, could come up with the heuristics to place models realistically. Coming up with the models procedurally would be a different matter. But it seems, Stuart has addressed this already in OSG space. So the really difficult work has probably already been done. Coming up with an interface to access his code from scripting space should be simpler than writing his code from scratch.
Hooray and Thorsten have some more involved dynamical city-building scheme in mind - finding an algorithm which dynamically generates a street pattern and places a plausible mockup of a city dependent on its knowledge of the underlying terrain. Much of the performance here depends on what models are placed - if models without an xml wrapper are used, it's going to be relatively fast, if not, then not. That's different from the situation with weather where we could never use models without xml wrapper, because the rotation effect needed to be declared there (merging the models to a whole block is also important though).
How about instead of texturing urban areas and towns, generating "fake roads" with modular blocks of buildings and trees?
For instance, in the western USA you could generate a grid pattern for cities and towns and populate the grids with buildings using a formula.
- it is possible to use various landclasses to distinguish parts of a city in custom scenery
- that a prototype for autogenerating a city based on these landclasses in Nasal is feasible
- that both myself and Hooray would help with the coding
- i.e. that there's a clear and well-defined path from a wish to reality here at the simple expense of doing it
In Nasal, one could:
- use random geodinfo(); calls across the terrain to find spots where the terrain is urban (or otherwise interesting
- call an autogeneration algorithm from that point to fill the whole urban region by
- first creating a street pattern by means of an algorithm (European cities are not much more difficult - you just take a grid and allow for random distortions of the intersections and curvature of the streets, that should be pretty good already)
- sample terrain while you do this - elevation and especially the presence of rivers alter the pattern
- then determine what kind of quarter you're trying to build
- then place buildings next to your streets, orienting them properly
- throw parks, gardens and so on for good measure
- do this till you hit the edge of the urban region
- then go looking for the next
- have a housekeeping routine in the background which deletes models which are too far away
Too large modular blocks are actually a problem, because they create floating buildings wherever the terrain isn't level. So ideally you'd design the autogeneration with just single buildings as blocks and put the information which buildings are typically adjacent and how they typically arrange into your algorithm (it's a lot like clouds actually - Local Weather could create you a slightly randomized m x n grid of buildings clipped where the urban terrain ends with a higher city center region and lower surroundings with less than 100 lines of additional code, provided you have the models - the real work would be to get it to do European placement patterns, but the functions to do that are probably not as complicated as credible undulatus patterns).
PixelCity (Hooray, TorstenD)
Once you do take a look, you'll also find a number of threads related to the open source PixelCity project, which uses a fixed rendering pipeline (i.e. no shaders) - but which is nonetheless extremely impressive. Like Torsten mentioned a while ago, this would need to be ported to OSG (and shaders) to be usable in FG, but this could probably be done by merging it with Stuart's code, because that's a very good (and working!) example of how the FlightGear/SimGear side of things works.
It really looks cool from the distance and close up. Implementing it into FlightGear requires porting the OpenGL calls to be OpenSceneGraph compatible, probably by implementing osgDrawable. The current implementation only shows night-time views, so this has to be tweaked, too. Another issue to take care of is interaction with existing scenery models, so the generated buildings do not interfere with our scenery models. The same is true for our landcover, roads and elevation data. Definitely worth some thinking. Probably as a google summer of code
Also see AutoGen Scenery for FlightGear.
osgEarth (poweroftwo & stuart)
stuart:Random object generation. osgEarth provides OSM building data, which it makes sense to leverage, but for other areas of the planet it would be good to be able to use our random buildings/objects, and I'd really like to be able to generate random trees.
OSM & Canvas (TheTom)
TheTom is also working on something to show tilemaps inside a canvas. I've now pushed a function to fgdata (gitorious/fg/fgdata/41b6c9c688ce78d8c907a07c42b9ea4d8290da0c) which allows building templates for the tile urls.
Also see Canvas & Tiled Maps Note that osgEarth will probably soon be linked into FG by default according to [2], which means that GDAL/OGR can be relied upon, i.e. supporting GeoTIFF processing would be another useful option for any mapping/charting needs implemented via Tom's Canvas system.
Procedural Airports (psadro_gm, zakalawe, papillon81)
As was said previously, X-Plane has been doing that for years - and meanwhile we may have the computing power (and idle cores!) to actually sonsider doing that in FG, too. So it would be a great addition and would quite certainly lower the entry barrier for people doing scenery development if airport changes became directly visible without having to go through the hassle of running TG tools.
fully dynamically created airports is another really long-standing scenery related idea, that's been discussed among core developer on and off for over a decade already, including David Megginson and Andy Ross
http://forum.flightgear.org/viewtopic.php?p=176132#p176151
What about a purely symbolic representation? Store just centerline and width for each taxiway, and keep the existing polygonal representation for "tarmac" areas. Throw out the "pre-cut" airport This means that the tile loader will be forced to do some computational geometry at load time to decide on the actual polygons to be rendered by OpenGL. But that's not likely to be too much -- even the biggest airpots have no more than 30 taxiways with no more than ~4 curves on each. Figure an individual curve has no more than 10 segments, with 6 polygons for each segment (two yellow paint, four pavement). So that's a few thousand polygons generated and intersect per airport loaded. Not so bad, really -- note that because it can happen in the loader thread, and therefore make good use of the multi-dispatch multi-core CPUs that are becoming so popular these days. The biggest advantage is that (if you do it with the runways too) it means that the airports can be generated at runtime and edited by the user without doing a terragear scenery regeneration.
we already have all the data to generate the ground polygons, inside FlightGear - that's exactly how the airfield chart / ground-radar work. And we can do it adaptively (more bezier interpolation on faster machines) and also get airports editable in mostly-realtime (unless the airport boundary changes).
The trick is to make an OSG 'loader' which creates the airport geometry from the apt.dat definitions, which of course is exactly what genapts does - this is why I was working with Chris to make it fast enough to run inside the loader thread, in FG. I'd love to fully generate the apts at runtime. LEMD is probably the most complex layout, and genapt currently takes about 2.5 seconds to generate. I imagine it could be generated in 2 stages for LOD. 1 for runways and taxiways, which are really quick, the 2nd stage for the line data which is slower.
psadro_gm:Although I haven't written a line of code in SimGear for draping, yet - I'm getting a pretty good idea on how it will work. I think we could speed up the OBJECT_STATIC_AGL using the envisioned draping code.
Currently, when a tile loads, it first gathers the type of objects in the tile. If there is a draped object, I plan on keeping raw btg data (nodes and triangles) around. I need the Geodetic nodes, unfortunately for proper draping, so I'm going to have to create a parallel node list Cartesian ->Geodetic. The triangles are all index based anyway, so we'll just refer to the Geodetic nodes when using these triangles.
A draped object's 2D bounding box will be used to quickly find the relevant triangles (using the geodetic nodes long/lat) that need to be considered, then I plan to use barycentric interpolation to find node heights at specific lat/long coordinates. This node will then be converted back to Cartesian space.
Procedural Buildings & Cities (radi & vanosten)
Also see Osm2city.py
Zakalawe:A thought occurs - this is much more blue-sky, could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sized (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread.
So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time.
Radi: focused on OSM buildings/bridges in the past, but is now interested in procedural city generation in general. OSM xml data for LOWI region alone is 50 MB. Might be a bit heavy a download for some users. Radi discussed this with James at FSweekend last year: we could pre-process OSM data, extract what's useful for us, and ship the outcome with our scenery. OSM buildings for LOWI would then add perhaps 1MB or so. OTOH, if this is generated at run-time (and then cached), users could decide themselves if/what OSM features they wish/can afford.
I like the idea of having this generated at run-time, and I'm quite sure a c++ version could be fast enough. Raw OSM input data is too big (50 MB for LOWI), but that a) includes *everything* and b) is xml.
But storing pre-processed data could be an option. A typical scene now easily contains 50k buildings. Reducing that to, say, 10k, should fit into well under 1MB. And of course I could modify the script to generate that outline data. Perhaps we can come up with a spec of the outline data at FSweekend.
I wrote a similar script recently, using python. Got Dresden (EDDC) area populated with some 20,000 buildings from OSM. There is some frame rate impact, but I still get ~20fps on an i5-2500k/GeForce 650TI/Ubuntu.
I put all buildings in one .ac file. Loading time is pretty quick, maybe some 5 seconds more than the default scenery. I pre-calculate the elevation: I extract the elevation on a rectangular grid (10m step size) from FG in the relevant area once using a slightly modified version of http://wiki.flightgear.org/Howto:Get_a_number_of_elevation_offsets_for_a_number_of_objects. Then the script loads the elevation data, and linearly interpolates elevation at the buildings positions.
Some facade texturing is also done. Roof geometry and texturing is still work in progress
vanosten:
So the idea would be to procedurally generate buildings based on OSM data (not uploading to OSM!) based on other OSM data like streets, area classifications, ... I thought of enriching offline OSM data with buildings - which could then in a later step be used to actually generate buildings in Flightgear (or X-Plane with http://osm2xp.com/). Due to differences in landuse patters between e.g. cnetral Europe and USA the algorithm would naturally have to be configurable - however somewhere we need to start.
Would that be a good idea? Has this already been attempted (I mean based on OSM data, not generic procedural cities)?
I first let bob.pl generate all *.ac files and *stg entries. Then I parse the *.stg files for lines starting with OBJECT_STATIC, get out the lat and long, set the properties, wait 1 second and then get /position/ground-elev-m, which I write back to the file (instead of -9999).
I understand there are advantages to do stuff on the fly - it might be even faster to do calculations than reading detailed info like ac-files from the file system. However I wonder whether it really is the same thing that people try to accomplish. Together with Radi I want with osm2city make a plausible world, which satisfies also someone on sightseeing with a helicopter, who knows the area. The other is generating a plausible world. The first one needs a lot of parametrization and logic on a per object level. If the first one can be satisfied with on-the-fly processing, then I would look into porting code to C++ and learning C++. If not, then potentially we should leave the initiatives apart?
I agree that we might have to go with less details and a few / couple of buildings - maybe even replacing existing OSM floorplans in place. It is not about matching reality - it is about making something that looks realistic. I have built some paper based algorithms and the next thing is to try the stuff in programming. I will most probably go for a Java based prototype using the JTS Topology Suite library. If the prototype prooves sucessful and estimates for the next step do not look too bad, then I need to take a decision with your input, whether to port it to C++ / GEOS or C++ / Simgear. However this would mean that i need to learn C++.
I finally got bob.pl working using a custom Java program, which also reads the height to place the buildings (I will share the java program once it works outside Eclipse without hassle). Basically I now have 9000 objects around LSZR at the lake of Constance in Switzerland. See following image (which looks good, but which I think still shows a case for intelligently generating all those buildings, which are not yet in OSM datasource).
9000 objects means 9000 *.ac files - a lot of which could be reduced to a few, if objects would be intelligently replaced by shared objects (e.g. for residential houses, not so much for other buildings). Which leads to the following questions:
- Right now startup is very slow due to scenery loading. Would the startup be significantly (linearily) be faster, if e.g. 60-70% of the buildings were shared buildings?
- At night all the buildings generated by bob.pl are without lights. Could that be changed or would that again be a case for using shared buildings?
- bob.pl is written in Perl FG is written in C++. Is there a policy against writing some of the scenery tools in e.g. Java, if one would like to contribute?
- A previous post by Soitanen in this thread used OBJECT_STATIC_AGL to dynamically get the height over sea level for the buildings. However I guess that precalculating during scenery generation is worth the hassle in order to reduce CPU?
cppbind & Nasal
I think C++ is not the problem, we have some really experienced C++ developers interested in working with OSM data, such as psadro_gm, zakalawe, papillon81 and TheTom. And these guys not only know C++ already, but are also familliar with SimGear ,FlightGear and TerraGear.
So the C++ part can be handled by them - these guys want to use the same data in FG for similar purposes. So it makes sense to let them handle the C++ side of things.
Now, what could be done instead of requiring use of Perl, Python or Java is this: We now have a new framework which is called "cppbind". This was added by TheTom, as part of the Canvas effort. This framework can be used to expose C++ code to Nasal, so that you can do the same things in Nasal that you would normally use Perl, Python or Java for.
A similar method is used by Thorsten's weather system: all the important (performance-critical stuff) is handled by C++ developers and code that they have written, and there are just some special, new, commands/classes added that can be called from Nasal, and which will directly call the C++ code, to speed up things.
This could be also done here - the C++ guys would handle the C++ side of things, and merely expose these functions and classes via Nasal scripting - in FG, we could then directly use Nasal code to access OSM vector data, and use it to procedurally modify and add to the scenery - no matter if it's buildings, cities, rivers, roads, powerlines or bridges.
So we really only need cppbind bindings to expose some OSM specific stuff to scripting space (Nasal) - to procedurally add/modify buildings and cities, we should probably reuse Stuart's existing code.
This would mean that people could directly focus on their domains (C++ vs. scripting - and procedural scenery generation)
Also, Nasal itself is actually designed to be thread-safe - so carefully-written Nasal code could in fact interact with the OSG pager thread, or even be running there directly, i.e. we could be running high-performance C++ code there, which is only parameterized via Nasal calls.
Populate FG world with OSM data (F-JJTH)
F-JJTH's idea here is to populate FG world with OSM data. OSM provides some API for HTTP request ( [3] ) Once data are downloaded we could be able to draw them on-the-fly in FG. In other words: it's similar to the osm2fg but in-live.
BTW, this feature is not at the top of my priority and I would wait the osgEarth integration before all.
Using the HTTP APIs is a bit overlapping with the recent work on HTTP bindings for Nasal via cppbind, but also with poweroftwo's osgEarth integration, which uses curl to provide fully threaded access to this kind of data. Also, Stuart repeatedly mentioned on the forums that he would be supportive of exposing the placement heuristics for his random buildings code-seconded by Zakalawe [4], so that these can be affected via corresponding APIs - we've had quite a bit of progress regarding procedural scenery generation in 2013, including buildings & cities (radi, Soitanen/osm2fg) [5] [6], roads, rivers - even railways (vivian) and procedural bridge generation (radi) [7], but also procedural power lines (vanosten) [8]. In other words, there's some serious -and unprecented manpower- to be leveraged and coordinated here, including quite a few folks who are able to build from source and able to write C++ code. So this deserves being coordinated among all interested parties. And it would clearly make sense not to just expose things to the Canvas system, but to expose the corresponding APIs so that other subsystems and users can access these and use these for the purposes outlined above.
Here is an example: [9]
OSM2FG (Soitanen)
This is script, which helps to automate convert landuse, lines, waterway etc data from OSM to FG. Git repository located here: [10] Also it needs to have custom materials for textured roads and railroads from Project Russia: [11] Currently, this converter works only for Russia and CIS countries.
Workflow: Converter must be run from commandline. No GUI is presented. In commandline bounding box for generation is set. Then it automatically download heights (from the same source, as World Scenery 2.0), automatically downloads freshest X-Plane airport base, downloads full world coastlines and regional shapes for different regions of Russia, depending on BBOX. So, if select to generate some terrain outside of Russia, then scenery will be generated as land with normal coastlines and airports. No roads, no landuse. In case of acceptable region it automatically makes textured roads and railroads. Mostly number of lines on roads will match real one (if presented in OSM data). Forests, water polygons, water lines - all will be converted good. Also, some simplification will be done for shapes to reduce number of polygons and generating time. If scenery tile is too complex and bugs are appearing, LOD level can be set for generating to reduce number of generated features (on low LOD levels roads with low majority level are not generated, the same for low majority landuse). And after all automatic preparations it just runs standard Terragear routine to generate final scenery.
In earlier version there was building generator, that generates each building as single object, but that was too bad for FPS. Better way to use osm2city from radi, but I can't automate it because of need to run FG and get elevations for the tile.
using OBJECT_STATIC_AGL gives big slowdown in FG working. So precalculation is much better. How you program gets elevation? Does it use the same data, as TerraGear use for terrain generation?
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38134.html
Power Lines (vanosten, owenpsmith, Soitanen, David.megginson)
vanosten:It is meant to be to support pylons from the shared objects library be placed based on OSM data in Python (extending osm2city).
f-ojac:Have a look at https://gitorious.org/fgscenery/tools?p=fgscenery:tools.git;a=summary too to avoid duplicate work. Power lines are showing in OSM, for instance http://osm.org/go/WJHUyw34- For mapserver, yes we'll have to wait a little as there are some prioritary works on. Automated power line object generation from OSM data has already been tested a few years ago. Right now we're trying to make this process rework, with other objects (windturbines, watertowers...) before going into more complicated stuff. Aligning the pylons is also doable, Jon wrote a script on that a few years ago. Now the webforms are done and terrain generation is quite finished, we'll focus on some other nice features.
Soitanen:data can be taken from OSM - if two power pylons are connected with line tagged power=line, that means there are wires in the air. I think wires can be modeled with one 3D model. It must be some kind of parabolic function, when viewing on it from side. But, if power line is turning, length of wires on one and other side will not be the same. So, script, that will place pylons, must compute attaching point for wires and place 3D model in needed place with needed scale.
Hooray:You can do that procedurally even without touching TerraGear or 3D modeling - e.g. by using a Nasal script that uses the OSM data to add those lines to the scenery - you would look up height/elevation, distance and connection points - and then use a technique like the one demonstrated in the glideslope tunnel script to add lines
owenpsmith:When flying VFR in the heavily forested areas of western Canada, it is never the power lines you look for, it is the clearing through the trees made for the power lines. They stick out like a sore thumb. Terrain and auto-generated trees are not my domain by any means, but I would think that it would be easier to make a script to omit trees under the lines that it would be to generate the lines themselves. If you could say draw a line between any two models in a set of models (various transmission tower models) that are closer than a certain distance apart, then omit the trees within a given distance of that line? Just my 2 bits. If we can clear the trees, this might come along as a bonus with winter ground textures
Johan G:Goes for Sweden as well. In the about 60% of Sweden's area covered by forest no other line features, except for rivers and highways, sticks out like a 25-50 m (80-160 ft) wide clear cut that stretches for mile after mile. It just struck me that the power line clearings is not really a problem related to the random tree placement algorithms, but rather a land classing problem. The area in the clearings are in essence a different land class than the surroundings.
Hooray:You would need to get in touch with Thorsten and/or Stuart to see if omitting trees based on heuristics is currently possible or not, I have no idea - otherwise I agree, that it would seem like a straightforward improvement.
owenpsmith:Setting the elevation offsets is a bit tricky and is done in several steps. First I add the towers on either side of the span if they do not already exist. Once they are uploaded and their terrain elevations have been set, I plug the lat/long/terrain elevation/tower height into a spreadsheet. Each spreadsheet is tweaked based on the number and layout of markers. The spreadsheet is set up to calculate the lat/long of each marker, and the absolute elevation based on a catenary curve. The coefficient of the curve is set for each span based on the length and adjusted until it "looks right". I then create all the objects locally and fire up the sim. I find the terrain elevation below each marker and subtract this from the absolute elevation to get the elevation offset. Once uploaded, I reload scenery in the sim and do a flypast to double check. This work is on hold right now because the mapserver site is acting up, and I can't access the object properties from the map. This is preventing me from getting the information for the towers on each end of the span. In the meantime I'm adding more towers so hopefully I can do a marker blitz once the mapserver is working properly again. On the subject of implementing the clearing through the trees, I've been thinking about this a bit. It occurred to me that the roads in FG use OSM line data and in the simulator, we get a grey line on the terrain, on which the trees have been omitted. So if we could implement a line type for power lines for which the trees will be omitted, but not draw the grey line, then we'd have the clearing we want. The line data could be derived from existing power pylon object positions. The line type may already be defined, we just need to set positions and process it appropriately in FG. Will dig into OSM when I get a chance. It would be nice to get automated power line object generation complete with tree clearing. Object heading might be a bit tricky. Adding power pylons is not that exciting but it is pretty quick work. I'd settle for OSM based tree clearing provided it aligns accurately with existing FG power pylons. It would seem that the power line data in OSM is just line data, similar to the roads for which we already clear the trees in FG. So if we can add the pylon objects based on this line data, can't we clear the trees the same way we currently do for roads? How is the line data (roads, power lines) defined? Are they not just a series of "waypoints" defined by lat/lon? If they are then couldn't the line data in the btg files, and the pylon positions in the stg files be based on the same set of lat/lon points? Then they would align in the rendered scenery? My development experience is in the C family (C, C++, C#), Perl, SQL databases, mostly "backend" development, very little GUI work. About 15 years ago I did some work on ATC systems, and ISS robotics using Ada :-/ Most of my career has been spent in aerospace/defence which grew out of my first career choice which was to be a commercial pilot. I got my commercial licence and my parents and a few other relatives have had various Cessna's over the years. So I pretty much grew up at small airports along the west coast of Canada. My favorite times in the cockpit have been on Cessna 180/185 floatplanes. So with this backwoods VFR experience, power lines have always been far more available than navaids for navigation. So is this how the roads are generated then? The road line data gets "baked" into the terrain files by giving these areas their own land class? So FG knows nothing about line data when it renders scenery at runtime? So if we have some power line line data, it would be similarly "baked" into the terrain using a land class which would ideally have the same terrain texture as the surrounding land classes with the exception that no trees would be generated. I see how it could get more complicated if you consider the impact on all terrain types, and the type of random objects on each (trees, buildings etc). Obviously for certain types of landclass the effects could be ignored, ie water, grassland, tundra, dessert etc. Others would require trees to be cleared. The urban effects are still a mystery to me but everything is slowly becoming less mysterious! I guess each landclass would have to be analyzed and grouped into categories based on impact of power lines. Then sibling/child land classes introduced based on that analysis, to be substituted for the base landclass.
psadro_gm:ow that World Scenery 2.0 is rolling out, we're looking for new ideas to sketch out a roadmap for scenery features that require changes to the terragear tools and the .btg file format. I think one of the largest requests is from shader developers to get more into the .btg file. I'm currently looking at adding vertex attributes, and alternate texture coordinates. The biggest concern is backwards compatibility. Any new additions to the .btg should (hopefully) be ignored by older simgear versions. This will be an exciting time for experimentation to see what sticks.. I am unsure what we could do to 'clear out' tree generation on existing landclasses, as I am unfamiliar with how the trees are positioned. If there's anything that could be done with added info for the shader, let me know.
Hooray:Having runtime access to certain vector data would be useful for a number of other subsystems in FlightGear. Time has shown, that the more data is available, the more people are going to use it come up with novel features. And then, being able to dynamically place/replace scenery textures easily has been requested several times (see the runway skid marks discussions for example). Also, it would be awesome if TG development could be closely coordinated with the ongoing random buildings/OSM efforts (by radi et al). These are two areas that are clearly overlapping in various ways - despite the fact, that FlightGear's random buildings are less static than TG scenery compilation historically is. But you guys once mentioned that you were looking into creating more and more stuff procedurally at runtime anways - so given that both efforts seem to be alive and kicking currently, it would be great to see some form of JV for the greater good (i.e. final outcome)regarding random trees/buildings, Stuart is the right person to talk to - he should be able to explain how everything works currently. But if I remember correctly, he announced a while that he was reworking the whole subsystem, and considering to decouple the "randomness" aspect a little more, so that other placement heuristics could be used, too.
david.megginson:As an Eastern Canadian pilot, I agree with @owenpsmith — unless you're flying very low level (e.g. landing, taking off, pipeline inspection, etc) it's mainly the clearing that you see, not the pylons and wires themselves. I'd suggest that we need a material for "DefaultClearing" that can vary by region: for example, it would be grass in wet, temperate parts of North America, but we wouldn't want a strip of lush grass running through the desert under a power line.