Orbital Rendering light blue space instead of dark

[wlbragg]

A few images to wet your appetite.

[Thorsten]

Ain't that pretty - wherever did the ISS model come from?

In case you missed the pointer

http://visibleearth.nasa.gov/

has terrific textures at highest resolution - I derived a set of dds sheets from that at almost full resolution (it's *cough* 172 MB per texture sheet and more than a GB in total, so there's no way to ship that easily). The optimized earthsphere has uv-mapping for making everything seamless and textures for it have to be processes by adding a margin, but there's a second sphere for which it's easy to stick your own textures on.

[Johan G]

Interesting, never expected to see a space station. I guess Vostok can not dock with it. Good thing there is a UFO.

Jokes aside, is there an FDM of sorts involved?

[zlsa]

Thorsten, is it feasible to add detail (not resolution) to the earth images so it's noisier?

[Hooray]

@Thorsten: do you actually need the built-in scenery/terrain engine running here, I mean are using it at all ?

[Thorsten]

Yeah, that's just a call to the noise lib - I'm just not convinced that it's a good idea, because unlike the terrain shader, the planet shader has zero idea what the terrain it is trying to render actually is.

If you have even a modest graphics card, increasing resolution is in fact quite feasible - given that you render nothing else, you can fill the GPU memory to the brim with textures, performance is just a non-issue for this.

Edit: No, there's no terrain arriving at the GPU (I doubt there's any loaded given the altitude, but you sure can't see it because it's way beyond far clipping distance ).

[Hooray]

ok, then this would seem like another valid use-case for making more subsystems entirely optional, so that they can be disabled at run-time on demand.

I derived a set of dds sheets from that at almost full resolution (it's *cough* 172 MB per texture sheet and more than a GB in total, so there's no way to ship that easily).

People who have the corresponding bandwidth at home (which I understand you don't) can get such imagery using Canvas - it can be downloaded transparently in the background using 3 lines of Nasal code, simply by setting a property to contain the URL of the corresponding image: http://wiki.flightgear.org/Canvas_Image#src

By default, this could be saved in $FG_HOME for future use.
This would work very much like osgEarth - i.e. is downloaded in the background, progress can be seen in the property tree IIRC.

To apply such a downloaded-texture on your sphere, you'd use a placement to replace the texture with a canvas texture, which is how this works using 5 lines of Nasal:
Subject: Two Images to a Texture

ok, I've added a snippet of Nasal/Canvas code demonstrating how to modify the livery at run-time:

http://wiki.flightgear.org/Howto:Dynami ... via_Canvas


We can extend this over time - I just added the map to have some "dynamic" content - this could be just as well raster images, SVG files, maps, paths or any combination thereof - it's really rather flexible and only needs ~10 lines of code. Obviously, texture mapping of the 3D model is still applied, so needs to be taken into account.

Tom is hoping to add built-in caching support for persistent canvas textures sooner or later.

[Thorsten]

ok, then this would seem like another valid use-case for making more subsystems entirely optional, so that they can be disabled at run-time on demand.

Well, actually not - you want the terrain to be there upon re-entry. Which means you want to evaluate a distance measure whether the terrain is to be loaded - which is what we do anyway.

People who have the corresponding bandwidth at home (which I understand you don't) can get such imagery using Canvas - it can be downloaded transparently in the background using 3 lines of Nasal code, simply by setting a property to contain the URL of the corresponding image

You do realize that the original images can't be easily used directy? They're 21600x21600 png images of ~240 MB size each, i.e. not mipmapped or scaled to powers of two, and if I ask my GPU to texture anything with the raw images, FG freezes for a few minutes.

Also, this is not like OSGEarth, where you never can download the full database and take what you need 'on the fly' - this is a global coverage of Earth, you're all going to see it during one orbit (i.e. within 90 minutes), I'm getting the images delivered server-side with on average 200k/s, which means downloading the whole set takes 160 minutes and your orbit is long over. Well, maybe the freezes upon mipmapping are long enough that the download works out.

I understand the enthusiasm for canvas, but even sitting on a really fast internet connection, this makes no sense to me. I suggest you actually try to work with the max. resolution textures - even opening them in gimp is a challenge for an 8 GB memory system.

Full resolution is a hog - but everything gets better by a factor 4 for every resolution level down, so it quickly becomes quite feasible.

[Hooray]

it isn't so much enthusiasm as it is trying to find a solution for the deployment problem you mentioned - Canvas is internally using http bindings to fetch data, which are also used to transparently download aircraft >= 50 mb (think 777) - you've got a point about the pre-processing required though, because Canvas inevitably runs in the main loop for the time being so is clearly not an option for doing this kind of thing directly - all that said, setting up a php script that serves a down-stripped image set using GDLib/Imagemagick would be under 200 lines of code probably - and the amount of data would become manageable like you say.

So the idea was not about to implement this directly but to look at what can be done and where workarounds/intermediate steps are needed - unlike osgEarth, I've never run your addon (yet), which is why I am asking - besides, while this isn't cannot exposed by Canvas, OSG itself can manipulate/reduce images "on the fly".

However, even regardless of canvas, there's obviously an increasing trend to use live/online-deployment for such downloads, no matter if it's package/OS updates - or more recently, scenery and aircraft that can be downloaded in the background automatically. In my eyes, this isn't much different from using Canvas for animating/changing liveries - it certainly wasn't designed for it, but it's mainly a matter to determine its boundaries/design limitations and see what can be done about those.
Back when we were talking about photo-scenery, I started playing with the SG patch to see if it can be turned into a canvas placement - which basically means that arbitrary textures can be draped over terrain at run-time, and things were pretty promising - so this is more about seeing the R&D side of this, you know

[Gijs]

Also, this is not like OSGEarth, where you never can download the full database and take what you need 'on the fly'

That's not entirely true. With the osgearth_package utility, you can pre-pack data to be used from cache (ie offline). You can have a global, low LOD level package for orbital rendering and then more "local" packages for normal flying, similar to the scenery packages that we currently offer for download. Next to that, OSGEarth can load shapefiles, apply textures based on landclassing etc. (see examples here and here). It's not just a photoscenery tool.

[Thorsten]

That's not entirely true.

Whatever...

Also, this is not like OSGEarth, where you never can download the full database and take what you need 'on the fly'

vs

With the osgearth_package utility, you can pre-pack data to be used from cache (ie offline). You can have a global, low LOD level package for orbital rendering and then more "local" packages for normal flying, similar to the scenery packages that we currently offer for download.

What I said is you can't download a full aerial image database - it doesn't fit on a normal harddisk. So - just where is the contradiction? I didn't say anything about making scenery packages from osgearth, neither can I see any relevance to the topic of the thread.

Next to that, OSGEarth can load shapefiles, apply textures based on landclassing etc. (see examples here and here). It's not just a photoscenery tool.

I didn't claim that either.

Okay - I sincerely regret trying to do the constructive thing and answering this thread, I did break my resolution to be done with the forum it because I have always appreciated wlbragg's work here - it seems to get me into completely pointless side issue discussions of which I can't see any discernible relevance to how EarthView works, so I will remove myself from the forum again.

[Gijs]

I was just indicating that with OSGEarth you can get an offline, full Earth orbital rendering textureset at the same resolution as EarthView provides. What is used at lower altitudes is independent of that. You don't need all the detailed low altitude stuff to get a nice looking Earth from up high, unlike our current BTG terrain. In that way OSGEarth and EarthView tackle the same issue. Whether you use OSGEearth or EarthView at high altitudes, the download size of the textures will be similar. Downloading the whole world in high detail is indeed not feasible, but that's not what you need for orbital rendering.

If your statement was related to low-level flight, which is indeed off topic, then I apologise for misinterpreting it.

[wlbragg]

but you sure can't see it because it's way beyond far clipping distance

Speaking of, I lost the ISS for awhile until I realized you have to change lod to see if from any distance.