Scenery V3: Progressing the conversation

[IAHM-COL]

Hi All

psadro recently released the first preview of the World Scenery V3.
It is great to start seeing more concise work, that is not so much in the realm of the ideas

I'll be testing Hawaii (the demo), and adding it to a topic branch to terraGIT for those willing to try it out.

http://wiki.flightgear.org/Experimental_terrain_engine

So far, I am rather desilusioned with some of the execution and/or conception of where is best to go for the next scenery. I understand well some central motivations behind, but again, the way this is being done concerns me somehow more than a tiny bit.

I'll bring some of my concerns specifically

Ground Texture

It seems to me, much of this work really is a crude and poor implementation of OSGearth where power of two tried to wrap a google-earth sat view on a terrain mesh, to give terrain texturizing. As opposed to shapefiles decoding.
Now, psadro said:

http://wiki.flightgear.org/Experimental_terrain_engine

the texture is just 1 4096x4096 sheet for the whole planet.

This is just sad! What kind of texture resolution are we objectively looking at here? several km/pixel resolution? The world, like this will only look nice for a space shuttle flight. At FL400 it will already look blurry and with terrible lack of granularity! Let aside, what is going to happen to VFR flights?

Some work with shapefiles had demostrated how far we can go with shapefiles. Think some of the CORINE decoding in Europe, or the amazing work in Kansas and Ohio by Wllbragg.
Are we gonna let that go away and compromise to a 4096x4096 global resolution? Why? exactly?

It seems a good compromise for PFD level map displays for creating very novel glass instruments, but to fly VFR, it sounds a terrible regression from what can be achieved using QGis edited shapefiles.

*brain exploding*

http://wiki.flightgear.org/Experimental_terrain_engine

The actual DEM is a collection of levels (independent of the LOD level) Multiple DEM levels are not required, but highly advised. The ViewFinderPanorama DEM is ~50GB. The entire planet is always loaded, so terrasync would need to download all 60 GB the first time to be able to model the whole world.

Say what!?
OK. This would be fine for terraGIT. Kinda
(I mean, currently, it is possible to download only a tile of 10x10 degrees from terraGIT, which can be as large as 2GB data, as small as a few Kb. Thinking of forcing a Full world download before you can even launch Flightgear seems quite an overkill, and a rather abrupt separation to the central idea behind terrasync of "download on the fly" and "just download what's needed to get your flight done"

I really hope he is not being serious about this one.

Anyhow., yes, we can get to download the whole world via terraGIT as well, but it seems an strange direction to go.

Could you maybe rethink this one thru?

[OPFOR77]

Umm, he said that the video had just the one texture sheet, not the final product. The final product will still have land classes with textures like we have now, but the textures will be able to blend at the seams together.

He also says that the level 1 LOD is uncompressed and the final product will be ~20gb for the highest resolution. The whole world at the lowest resolution is 6mb, and you won't need to download it all to fly.

He's also including a property that will let you switch between his way of rendering and the current tiled way, so if you don't like it you can go back to Scenery 2.0.

[IAHM-COL]

@pinto
I read again
http://wiki.flightgear.org/Experimental_terrain_engine

The ViewFinderPanorama DEM is ~50GB. The entire planet is always loaded, so terrasync would need to download all 60 GB the first time to be able to model the whole world.

Note: the texture is just 1 4096x4096 sheet for the whole planet. It'll be nice to see what we can do with procedural texturing

The first quote clearly says, that you need the whole planet scenery at once, since the entire planet is always loaded.
The second quote clearly says that the texture is one only at that resolution, and that "he" is not targetting implementing the shapefiles, instead he wants to see how far can we go with procedural texturing.

[KL-666]

"The entire planet is always loaded" can not be true, it must be a language issue. I am quite sure he does not want me to load 60 Gig in my 12 Gig memory. Probably my swap is not even that big. He must have meant "downloaded to disk" or so.

Kind regards, Vincent

[IAHM-COL]

Short answer: I have no idea what psadro intents. Or whether that is a language error. But if the software is not loading all the content at once, why would one need "download all to disk"?
Again, if that is the case, I found that to be a rather abrupt departure from the terrasync's moto of download on the fly.
With my current internet speed, I aint going to be downloading 60G of content on the fly. I can tell you that one.

Now, you could possibly make the "need" of having all content and "loading" all content, without throwing all of that into your RAM or GRAM. Again, I dont know the inner workings of psadro's V3 engine, but, per example, you could implement pointers to files in disk, and then have your code tells which file must be rendered based upon your location and your current LOD. Now loading a couple thousand of pointers can be done as cheaply as with an array and the &Address of the beginning of the array, and data on the array size in bytes.
If this is the methodology used, in my wild imagination...., then maybe you wont get pointers to files unexistent at the moment of address creation (possibly at software launching), so you would not be able to get anywhere that you did not already have during launch time. In other words, your World is what you've got before starting to fly out.

In such circumstances, then, off course, it would be easy to drop to terraGIT's model of "pre-download as needed". But not the terrasync's model of "download on the fly"