Page 1 of 2
New approach to scenery generation
Posted: Mon May 30, 2016 5:23 pm
by D-ECHO
Cross-posted from the official forum, what do you think?
D-ECHO wrote:Hi,
I have an idea about scenery making and would like to ask you what you think of it. Please, don't feel offended in any way as I know that scenery generation already caused a lot of flamewars.
After our faithful mapserver went down some time ago, we have no more host of landclasses and height data what makes short-time scenery development much more difficult and I know there are alternatives like v0-data hosted on FGMEMBERS but that way you have to always download the full world (please correct me if I'm wrong). On the other hand, we have terrasync and the world scenery. The problem with world scenery is the time it is generated. It isn't much encouraging to develop in scenery which will only be visible in a year or even more. But custom sceneries aren't also the solutions as there are problems like visible boundaries and incompatibility.
Now, the idea is to have a server with a full set of v0 and corine landclasses or so and a kind of stream from the gateway and osm as well as SRTM. Via an interface or a git(svn)-like application, new data created by developers (e.g. pretty new landclasses
) could be uploaded. Then, on the server there would be a terragear program which nightly (or so) generates the data uploaded the day ago and adds it to a full scenery set generated once at the beginning. This set could be linked (or could be) terrasync, downloadable in-program.
Advantages of this concept are that contributed work would be much faster online without having difficult-to-download third-party solutions and flamewars between people being more for fast solutions and ones that are more interested in long-term solutions.
Please tell me what you think of this.
Regards
D-ECHO
Regards
D-ECHO
Re: New approach to scenery generation
Posted: Mon May 30, 2016 6:06 pm
by IAHM-COL
Can you tell me how does this solve tile boundaries problem? I'll be interested in implement this for terragit, but I think the boundary issue still prevails
Re: New approach to scenery generation
Posted: Mon May 30, 2016 6:14 pm
by D-ECHO
Doesn't the tiling Problem come from different elevations which would be solved if everything would usw the same pre-generated data?
Re: New approach to scenery generation
Posted: Mon May 30, 2016 6:15 pm
by IAHM-COL
Short answer. Not at all. You can run same elevation data (hgtchp only once) and the tile boundary still there.
The approach would work if you build a large enough area to be fully surrounded by oceans. Most places on earth (except isolated Islands, this means refitting a prohibitive amount of terrain daily)
Time; more than a week worth of computing power nightly.
Size: Huge. Specially if you build whole continents to prevent tiling problem. Your repo or repos will bloat faster than you could ever use
Re: New approach to scenery generation
Posted: Mon May 30, 2016 6:29 pm
by IAHM-COL
For Terra git thou we could implement some python script to obviate time and size, and just ignore the tile issue as we have done so far. That would be really cool, yet it needs some resources.
With the tile problem latent, I don't see this coming to terrasync. It would not be any different than just update terrasync downstream terragit content
Re: New approach to scenery generation
Posted: Tue May 31, 2016 2:48 am
by jwocky
Just that I get this right ...
- you need a freaking exorbitant big hard disk and some cores? Then you can cook a continent, break it back into tiles which "coincidentally" fit and feed those tiles back to TerraGit?
- you need a "something" loading ten x ten tiles kind of TerrySync style because not everybody can just keep the whole world on hard disks?
is that the situation?
Re: New approach to scenery generation
Posted: Tue May 31, 2016 3:21 am
by IAHM-COL
good summary
Now, one point is that it will be cool to cook a way to have (not necessarily nightly) but lets say more frequent updates from apt.dats that are new in the database to become available.
this is a longer plan idea because, first come first, we need to update what's missing.
But on the other end, I am sure D-ECHO is just foreseeing possibilities without fully cooking the details.
I think, the easiest thing to do is to host all terraGIT on an apache server.
FG 2016.3 reads http servers and fetch them terrasync-like
That'll make terraGIT simply an alternative to terrasync via server redirections. Something way easier to implement, and way easier to tell users to get.
Re: New approach to scenery generation
Posted: Tue May 31, 2016 3:23 am
by IAHM-COL
Now, my other point is:
If we dont' care too much about the tile boundaries (and honestly I dont), then you dont need to reconstruct more than patches for the updates of the world (instead of the whole world nightly, which is, just not gonna be happening).
but still some good programming is needed, I asume python gets the job done, to really queue what needs to be build to add every airport needed.
Right now, as I add more and more new layouts manually, I become increasingly aware of the rough edges such python needs to be kept aware of.
IH-cOL
Re: New approach to scenery generation
Posted: Tue May 31, 2016 12:39 pm
by D-ECHO
It depends on how prominent the tile boundaries are, I'll do some tests now to see how bad they look.
Re: New approach to scenery generation
Posted: Tue May 31, 2016 12:59 pm
by D-ECHO
Okay, I tested it in the Azores Custom Scenery and you don't really see it if you don't really look for it:
It mainly comes from the fact that the textures are starting at 0 in the new landclass and there are also some strange height-problems (which aren't that prominent, too).