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 20:39, 30 January 2014
, 30 January 2014→Random Buildings Scripting Interface (Hooray, Thorsten): http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=random+nail+hit#p155781
m (→Random Buildings Scripting Interface (Hooray, Thorsten): http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=random+nail+hit#p155781) |
m (→Random Buildings Scripting Interface (Hooray, Thorsten): http://forum.flightgear.org/viewtopic.php?f=5&t=16083&hilit=random+nail+hit#p155781) |
||
| Line 49: | Line 49: | ||
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. | 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. | |||
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). | 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). | ||