Board index FlightGear Support Graphics

Orbital Rendering light blue space instead of dark  Topic is solved

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Re: Orbital Rendering light blue space instead of dark

Postby wlbragg » Thu Sep 18, 2014 6:46 am

A few images to wet your appetite.

Image

Image

Image

Image

Image
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4889
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Orbital Rendering light blue space instead of dark

Postby Thorsten » Thu Sep 18, 2014 7:28 am

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.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Rendering light blue space instead of dark

Postby Johan G » Thu Sep 18, 2014 12:01 pm

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?
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5513
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Orbital Rendering light blue space instead of dark

Postby zlsa » Thu Sep 18, 2014 4:56 pm

Thorsten, is it feasible to add detail (not resolution) to the earth images so it's noisier?
zlsa
 
Posts: 145
Joined: Fri Feb 14, 2014 2:29 am
Callsign: N275A
Version: 3.5 git
OS: Linux

Re: Orbital Rendering light blue space instead of dark

Postby Hooray » Thu Sep 18, 2014 5:28 pm

@Thorsten: do you actually need the built-in scenery/terrain engine running here, I mean are using it at all ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Orbital Rendering light blue space instead of dark

Postby Thorsten » Thu Sep 18, 2014 5:30 pm

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 ).
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Rendering light blue space instead of dark

Postby Hooray » Thu Sep 18, 2014 5:36 pm

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.

Thorsten wrote in Thu Sep 18, 2014 7:28 am: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
Hooray wrote: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
Image

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Orbital Rendering light blue space instead of dark

Postby Thorsten » Fri Sep 19, 2014 7:00 am

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.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Rendering light blue space instead of dark

Postby Hooray » Fri Sep 19, 2014 7:22 am

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 :mrgreen:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Orbital Rendering light blue space instead of dark

Postby Gijs » Fri Sep 19, 2014 10:13 am

Thorsten wrote in Fri Sep 19, 2014 7:00 am: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.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9364
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Orbital Rendering light blue space instead of dark

Postby Thorsten » Fri Sep 19, 2014 11:42 am

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.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Rendering light blue space instead of dark

Postby Gijs » Fri Sep 19, 2014 11:54 am

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.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9364
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Orbital Rendering light blue space instead of dark

Postby wlbragg » Fri Sep 19, 2014 2:52 pm

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.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4889
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Previous

Return to Graphics

Who is online

Users browsing this forum: No registered users and 8 guests