I believe changes submitted to the scenery website (except airports) will be picked up and added to TerraSync - I'm not sure if these will get pulled through into terraGit - Israel can advise us about this.
Read my long post above.
Only models can be changed/added via the scenery website. So in reality, many things that need development are locked under that paradigm.
TerraGIT updated from new objects from terrasync a week or so ago. I posted that somewhere here.
Updating the new models from terrasync into terraGIT is very easy to do. Simple add the models and git commit.
Well, unfortunately there are technical caveats, but nothing major. So yeah, for the guys that push a building to terrasync via the database, yup terraGIT will get them./
But terraGIT, at the same time is a git repository and anything can be git committed, and git pushed.
* Terrain
* Config files (jetways, groundnets, etc)
* Shared Models
* Static Models
Now, you would say:
We don't need to get static models, but we could get them from terrasync.
Unfortunately again, a big misconceptionFirstly,
Nothing prevents models to be added directly into terraGIT
Secondly,
OSM2City objects can so far ONLY be added to terraGIT (the database does not accept those)
[Note: Stuart with a moderator hat on just pushed core changes that include new scenery specification for OSM2City objects, but this does not mean that the scenery database is open now to accept those. So go figure why Radi never pushed HongKong to terrasync?]
Thirdly, but very importantlyWhomever designed the "rules" for objects to terrasync wasn't a visionary.
The rules:
https://scenery.flightgear.org/contribute.phpThings that are not just discouraged, but outright forbidden includes, per example: 1) Texture sharing between models. and 2) joined meshes for objects separated (thing 3 or 4 buildings that are close but are independent units); the database REQUIRES these to be one object at a time.
These to conditions are simply put: WRONG.
But also a big design error. From computational point of view. And from development point of view (one spends hours making changes that are otherwise unnecessary, while at the same time breaking appart computer performance)
I tested this already heavily a couple of times. And ultimately, my development on Edinburgh is a complete proof of concept of what I am talking here about
This is how it goes:
Drawables in the scenery are better kept at a minimun. That is: lets say we have a cargo area with 10 buildings 5 hangars, 1 tower.
We can have 16 buildings to draw. Or 1 object.
The computer preffers 1 object every single time. It does it faster, and it uses less graphics card everytime it tries to re=render.
So? Lump them togehter in 1 object. It takes a bit longer to draw it, but then the fps resulting is much better. (keeping vertex number minimun is still very very important, but this does not change with lumping)
Secondly, how many textures? Textures must be loaded into the Graphics card Ram (or any other accesible ram in lower specs machines).
its better to have the lower amount of textures possible.
So lets say you have 1 big texture per building and 1 big lightmap per building to comply with the scenery database: then you get 32 rather large textures. That way you arent doing any favor to your computer, nor to you as a developer: and we are talking here about only the cargo apron.
Much better, consider those buildings per textures. Imaging you have the texture of the roofs, or the roofs of the hangar. One texture for walls another for hangar tiles. That's about 5 or 6 textures that you can share along ALL of your cargo zone (and even your airport). Use tiling to texturize, and you can get amazing resolutions without the expense of texture per pixel.
And thus?
YOU Could not possible add this better method buildings on the database because you violated rules 1 and 2 together and VicMar is going to go ape-shit on you
(really. VicMar already BANNED me from pushing object to terrasync for "continually pestering him and pushing the boundaries")
So?
I recommend all authors to ignore the scenery database rules. Make buildings and models that better render, more efficiently tiled, with shared textures accross your airport, with lumped/grouped objects to reduce drawables and get amazingly busy well constructed airports at a fraction of a computational cost,
And instead of crying because these can't be pushed to the database in this improved condition, simply, push them to terraGIT
Proof of Concept:
Edinburgh.