User:Laserman/ideas
Ideas for future projects
Too many objects have a negative effect on the frame rate. It would be nice to have a slider/property to set the density (number) of shared objects in the scenery, very much like we have it already for random vegetation and cloud density.
0.0 = show no shared scenery objects, 1.0 = show all shared scenery objects
OSM buildings at every airport
write a script that does this for every airport that has no 3D objects in FlightGear:
- read lat/lon of tower viewpoint or center of a runway from apt.dat or nav.dat
- make a 10x10km box around that
- run osm2city.py on that area
- bonus: run a modified roads.py for service roads - (disable hot)
Project3000 - convert more content from gateway packages
Status update 25.10.2015
I now have working (python) code and made a collection of 66 new shared models. you can use it to populate a single airport or put it in a bash loop to populate 2257 airports in one run. have a look at the forum: https://forum.flightgear.org/viewtopic.php?f=5&t=27688&p=261630#p261630
download: https://github.com/mherweg/d-laser-fgtools
generated scenery package: http://media.lug-marl.de/flightgear/project3000.tgz
Background Info
In this video Jan Vogel shows 2 of the airports that he made and talks about the many hours he invested to make GPL gateway scenery packages. https://www.youtube.com/watch?v=F7CNQzprkkg
At the moment we are using only the "apt.dat" part of each package, but the whole airport scenery package is GPL! In the future we can use locations of shared objects like jetways, lightpoles, cars, pavement markings, ... -> dsf2stg.py does the job!
We can also use "facade" buildings. outline might be equally good as footprints from OSM but we can expect better building height information from gateway packages. -> dsf2aptdat + osm2city do the job!
In many cases we have similar models in FG. We just need a conversion table:
- X-Plane file path -> FlightGear file path DONE
- x,y offset (DONE in the .ac file of the new shared models)
- heading conversion (DONE)
Where do we get the data?
From the DSF file of the scenery pack. DSF format is binary but can be converted to plan text with DSFTool. DSFTool --dsf2text input.dsf output.txt Thomas Albrecht (Radi) made a nice python program that uses DSFTool & fgelev and writes stg files with correct paths and stg-numbers:
When using gateway_pull.py and the gateway api there is no need for DSFTool because the "masterZipBlob" contains the dsf as plaintext ICAO.txt for every 3D airport.
TODO:
- organize the library.txt into chapters so that we can easily enable or disable a class of objects(all light, all cars, all jetways..)
- maybe trigger svn ("terrasync") to make sure we have terrain before starting fgelev
- choose similar models from http://scenemodels.flightgear.org/ -> 181 models can be converted, some are still missing
- make a conversion table (see above) -> library.txt can still be improved or extended.
- auto-generate .ac models as a replacement for X-Plane's facade" buildings, -> osm2city does the job, but roof texture needs to be fixed.
The creation of the conversion table can be done manually:
- first convert .obj to 3ds
- look at both models in blender
or:
- convert from ac3d to .obj
- look at both models in WED
what I did was:
- look at the .obj in WED
- edit the .ac in blender
Everybody is invited to join this FlightGear scenery project. If you want to have a look at X-Plane's shared models you can download demo version of X-Plane and use WED or ObjView.
Open in Blender:
- convert to 3ds
./ObjConverter --meters --polygon_ccw --axis_y --obj8 --obj23ds Cargo_Trailer_5.obj Cargo_Trailer_5.3ds
- then in blender: import 3ds
- number of models in x-plane/Resources/default scenery/airport scenery: 277
- number of models in flightgear/Models/Airport/: 289
source code of x-plane scenery tools
how non-programmers can help
Open WED(world editor) and have a look at the models in Library->lib->g10->US
look only at .obj and groups (.agp), ignore facades(.fac)
find or make Flightgear models which are similar in look, size and shape
Example:
- X-Plane DSF: lib/cars/car_static.obj
- flightgear STG: Models/Transport/hatchback_red.ac
see: Project3000
terragear for everyone
Many people don't want to wait years for updates of the terrain & airport layout. With scripts like this one:
https://gitlab.com/fg-scenery-build-script/fg-scenery-build-script/tree/master
it is easy to use terragear to make the airport or area that you like. But the installation of terragear and dependencies is complicated.
Idea: make terrager avialible as...
- a web service (we need money for this, or a sponsor for the server & bandwith)
- a linux live system (like knoppix) to boot from USB or Virtual machine
- a docker container ?
- statically linked binaries ?
- image for VirtualBox/vmware/
no more static models
It is really difficult to place non-shared models with the ufo and upload them one-by-one to terrasync. I'm sure many do not know that it is possible at all.
HerbyW's idea was to put everythin in shared models - with more categories than now.
pro:
- easy choose & place with ufo
- easy submit to terrasync
- all models in the Models tree(1.3GB). Only stg files in the Object tree
- no more duplicate ac and texture files in the Object tree
con:
- user has to sync all models (like with shared models now)
- a lot of work to do this change of infrastructure
I did run finddups on our Global Objects and found: Total bytes duplicated : 171 028 591 -> 171MB out of 1,1GB are duplicates
shared models folder: Total bytes duplicated : 22 477 591 -> 22MB out of 261MB are duplicates
sharing of texture files between scenery models
The existing rule "2 models shall not share a texture" leads to waste of
- internet bandwith
- disk space
- RAM
- texture memory of the GPU
FlightGear and the GPU do not know that 2 texture files with different names are identical, so the same texture is loaded and stored 2 or even more times.
Why do we have that rule ?
- to safely remove a model with it's textures ... that happens very rarely.
- to easily see which textures belong to a model ... that's also easy to read from the ac plain text file.
It is very easy to read from the ac file which textures it needs. It is possible to store that information in the database, so that a texture gets only deleted when there is no model left that needs it.
It would be nice to have a collection of wall, facade, roof, vehicle... textures that every modeler can use. We have so many GPL textures in FG but it is very hard to find what you need when you need it.