20,741
edits
Using OSM Vector Data in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Using OSM Vector Data in FlightGear (view source)
Revision as of 06:25, 1 February 2014
, 1 February 2014→Procedural Buildings & Cities (radi & vanosten)
m (→Powerlines (owenpsmith): http://forum.flightgear.org/viewtopic.php?f=5&t=20665&hilit=power+lines) |
|||
| Line 221: | Line 221: | ||
* 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? | * 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? | * 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) === | ===Populate FG world with OSM data (F-JJTH) === | ||