Menu
▾
▴
#2342 Project 3000
Is to possible to add Project 3000 to FGData or Terrasync for 2020 LTS (I remembered this as more scenery layer folders are probably? being added to GUI & Terrasync as a means of version control for OSM2City?). A lot more than 3000 Airports are covered in later versions IIRC.
Just 19 MB compressed. 4k files & 116MB uncompressed. As only one(?) airport is requested at a time, if the folder is added to FGData maybe it's better to be left as a solid tar or tar.gz file to be cleaner & avoid fragmentation of (non-ssd & hybrid SSD) HDDs when lots of parallel installs are present .
Kind regards
Probably a thing to bring up on the mailing list, it's hard for people to follow a discssion on a bug ticket.
I will read up on mailinglists, and using them. I had not signed up, just viewing using the sourceforge website. (There's a social barrier to overcome for people that are new & not programmers professionally etc., compared to forums: AIUI mails are sent to everyone who is still registered, from the entire history of FG. Forum posts are sorted into a tree of sections, and are seen only by those interested in the area so people feel more free to post potentially less correct things without feeling they are spamming.)
I have started to merge code into osm2city. The code is ported and works. However, it is a bit of a question, where it should go. there are some problematic pieces (e.g. cars) - and it is not on my list of priorities.
For 2020 LTS: If Project 3000 from OSM2City requires a complete rebuild then it will be likely not make 2020 LTS. Maybe the released Project 3000 scenery output can just be added to FGData or Terrasync.
2020 LTS is what about 80% of users will see for until the 2022+ LTS, going by sourceforge download stats. So it will not hurt to get it in - the current interest & downloads are despite most users not seeing the same FG people who follow forums/wiki as there are GPL craft and various other things that require finding/downloading.
Even if getting Project 3000 in any form is not practical for 2020, maybe implementing folders in GUI and Terrasync, could allow scenery to be added after a OSM2City rebuild in an year or so.
If possible, splitting (cosmetic) ground clutter into a seperate folder(s) may help older systems avoid that scenery layer. It might actually allow more clutter density in future for newer systems.
Performance shouldn't be a concern as scenery layers are optional. Any performance hit from repeated objects like cars etc. will likely come from lots of drawable objects like StuartB found [1] regarding random scenery objects - perhaps OSG scene traversal makes FG CPU bound, at least that was my impression after some testing and discussion [2] about FG being CPU bound. This type of performance issue could be avoided with instancing repeated scenery objects, in future years, if UBO support becomes available. AIUI this type of performance issue could be avoided with instancing in future years if UBO support becomes available.
Kind regards
Last edit: v s 2020-08-24
There is no progress in osm2city to do this. I doubt whether it should be done at all - given that osm2city can generate at least the buildings in the right place, given that WS.0 will make it much easier to contribute changes to Airports and given the rendering challenges with performance for some of the features.
Unless someone with either texturing or Python knowledge helps me, it will not be done in osm2city.
Closing this based on Rick's latest comment.