Using OSM Vector Data in FlightGear: Difference between revisions

Jump to navigation Jump to search
→‎Random Buildings Scripting Interface (Hooray, Thorsten): http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=#p155723
m (→‎Background: http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=random+nail+hit#p155723)
(→‎Random Buildings Scripting Interface (Hooray, Thorsten): http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=#p155723)
Line 46: Line 46:
'''Hooray:''' we have had a fair share of discussions related to this. Stuart's work has certainly paved the way for even more improvements.
'''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.
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.
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).


=== PixelCity (Hooray, TorstenD) ===
=== PixelCity (Hooray, TorstenD) ===

Navigation menu