Board index FlightGear Development Spaceflight

Earthview - an orbital terrain rendering engine [v2.0]

Discussion about development and usage of spacecraft

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby wlbragg » Tue Nov 15, 2016 8:10 pm

Assuming I have it all installed correctly, wow!

I could literally make earthview with the shuttle orbiting my screen-saver.

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: Earthview - an orbital terrain rendering engine [v2.0]

Postby chris_blues » Tue Nov 15, 2016 11:57 pm

Thorsten wrote in Tue Nov 15, 2016 10:46 am:you *must* supply some normal maps - get them from Chris or FGAddon


Have you uploaded the normalmaps for the clouds somewhere? Or have you cancelled that?

BTW, here are the normalmaps for earth: https://musicchris.de/public_pics/FGearthview/normalmaps_earth.7z (ca 130MB) or in FGAddon


wlbragg wrote in Tue Nov 15, 2016 8:10 pm:I could literally make earthview with the shuttle orbiting my screen-saver.

Amazing, isn't it? :o
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby wlbragg » Wed Nov 16, 2016 12:58 am

I don't have the cloud normal maps and I don't think the earth normal maps are working in my setup. I am seeing no change with the GUI switch.
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: Earthview - an orbital terrain rendering engine [v2.0]

Postby wlbragg » Wed Nov 16, 2016 1:42 am

On second observation, it appears that the earth normal map influence is very subtle, It only appears to be influencing the areas of light transition to dark and like I said very subtly. In full light I don't notice any change when switching it on.off. Does this sound correct?

EDIT:

OK, I think it is working correctly. I see quite a bit of relief when viewed in the right light and angle.
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: Earthview - an orbital terrain rendering engine [v2.0]

Postby Thorsten » Wed Nov 16, 2016 6:45 am

Have you uploaded the normalmaps for the clouds somewhere?


There are none - the normal map is derived from the cloud texture itself runtime by computing the alpha gradient along the light direction (and some post-processing). No need to add to memory occupancy.

Which is why FG is the only framework I am aware of that renders self-shading of clouds from orbit :mrgreen:

In full light I don't notice any change when switching it on.off.


Yes, that's correct - the normal maps only affect the twilight zone (mountains are on average not that sloped - barring steep rock faces which are too small to figure here, usually they're not steeper than 30 deg, so whenever the sun is higher the normal map doesn't really do much).

it may be as simple as using Canvas placements for the sphere (UV-mapped)


That's another one I admittedly didn't consider, but the catch is (as with livery or texture animation) that it actually does not switch the two other textures (normal and cloud map - not the cloud map used to draw clouds but the one doing the shadows...) In other words, while I think that a canvas could theoretically be used as a normal map, I have no idea how to declare the effect such that this actually works.
Thorsten
 
Posts: 10983
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby Thorsten » Wed Nov 16, 2016 7:28 am

Doing a quick test with the 8k textures. Starting on the US West coast in orbit needs two tiles loaded initially.

With having to load everything fresh from disc and png-textures, it takes some 29 seconds. Unloading and re-loading (aka textures still in cache) this reduces to 23 seconds. Using rgb textures instead, I get 19 and 14 seconds respectively (at the expense of having about twice the harddisk space taken). That's the last format everyone can use. Compressed dds is likely another factor 2-3 better, but that works only on proprietary drivers.

Basically this confirms my old test results.

Edit: Using the 16k dds for Earth, I get a fresh loading time of 24 sec. So - dds really rocks for that kind of job...

Edit2: And memory consumption seems quite manageable even with everything - with all 16k terrain and 8k normal and cloud textures, I was somewhere between 4,2 and 6.6 GB (dependent on how many tiles are shown).
Thorsten
 
Posts: 10983
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby Hooray » Wed Nov 16, 2016 4:02 pm

Thorsten wrote in Wed Nov 16, 2016 6:45 am:
it may be as simple as using Canvas placements for the sphere (UV-mapped)


That's another one I admittedly didn't consider, but the catch is (as with livery or texture animation) that it actually does not switch the two other textures (normal and cloud map - not the cloud map used to draw clouds but the one doing the shadows...) In other words, while I think that a canvas could theoretically be used as a normal map, I have no idea how to declare the effect such that this actually works.


I am not familiar with the implementation specifics or your requirements.
Also, I am not sure if you are even interested in exploring/pursuing this further in the light of your comments on the devel list ?
Anyway, for me to be able to make any meaningful comment, I would need to a layman's description of how Earthview texturing works and how the corresponding effects/shaders relate to it - i.e. if you are using procedural texturing or static textures.
Alternatively, you could also post links to the fgdata files so that I can take a look.

With all that said, I assume that the the shadow-map you mentioned is "hard-coded" in the form of a texture referenced by the corresponding effect/shader ?
Overall, it seems that the best way to deal with these situations really is to extend the material manager so that it can use a Canvas as its input and output - at that point, we'd have all the flexibility that we need, including support for effects and shaders.
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: Earthview - an orbital terrain rendering engine [v2.0]

Postby Thorsten » Wed Nov 16, 2016 5:36 pm

Anyway, for me to be able to make any meaningful comment, I would need to a layman's description of how Earthview texturing works and how the corresponding effects/shaders relate to it - i.e. if you are using procedural texturing or static textures.


The question at hand is that I can use the effect framework to declare up to 7 additional textures (being assigned to texture units) and pass sampler2d structures to the shaders which reference these textures. A canvas obviously is accessible by a sampler2d, so it will return a color value when queried with a coordinate vector.

The first texture is always special, because we don't explicitly assign it in the effect framework, FG does that in a hard-coded way. The same way is used to pass a canvas I assume. Currently the effect framework takes 'path/to/texture.png' as argument to assign a texture. So the effect framework needs to be rigged to take 'pointer-to-canvas' instead.

What the shader does with the pixel color value returned by using the sampler is no concern for canvas - whether that is procedurally used or not makes no difference. Technically a normal map is no different from a texture or a lightmap - it's all in what's done with the pixel color after it has been called.

For the issue itself, the problem is changing texture size (not content) runtime. I assume you'd have to delete current canvas, create a new one and assign a new texture to do it, I don't think one can re-size canvas easily.
Thorsten
 
Posts: 10983
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby Hooray » Wed Nov 16, 2016 6:59 pm

I am not sure if that's the whole picture - e.g. because a Canvas is looked up using its index, which is dynamic - i.e. instance/session specific, e.g. depending on how many MFDs you are using, the next free slot may be index [0] or [7] (or even higher than that).

Thus, we cannot simply make it look up a hard-coded Canvas using the index as the identifier - which is why Nasal code tends to use the canvas.getPath() API to look up the full property location of the corresponding Canvas.

Given what you have posted above, it may seem more intuitive to assign an effect to a Canvas than doing the opposite, what do you think ?

Under the hood, getting a handle to the texture used by the Canvas is a single line (i.e. a no-brainer) - the real issue is addressing it properly in a reliable fashion, because both frameworks were never integrated/designed with eachother in mind.

And even if we had unique identifiers ("names"), things would still be fairly fragile.

However, Tom has posted screenshots where he used effects in conjunction with Canvas MFDs IIRC (EICAS?).

I think you are right in that dynamically resizing a Canvas is not supported currently - I do remember some talks about that a while ago (years), and the general idea was to simply destroy and recreate the Canvas using the new dimensions (like you basically say). However, there is the notion of the "view" of the Canvas, i.e. we cannot only resize an image node, but also simply change the view properties to "resize" a Canvas - I am using that to make the ND fit into the PUI dialog shown in the screenshot below (the Canvas being 2048x2048 IIRC and it being shown as 256x256):

Image

It should only take a few minutes to check what's happening when the Canvas is resized or how difficult it would be to add support for your use-case.
However, I do think that everything goes through SimGear's OSG cache anyway
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: Earthview - an orbital terrain rendering engine [v2.0]

Postby Thorsten » Thu Nov 17, 2016 5:56 pm

Earthview 2.0 is now on the FGData next branch.
Thorsten
 
Posts: 10983
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby Thorsten » Fri Nov 18, 2016 4:31 pm

And got a homepage with some background on what it does and screenshots that will make you want to launch into orbit.

Image
Thorsten
 
Posts: 10983
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby wlbragg » Fri Nov 18, 2016 4:52 pm

That is really stunning! Great work guys!
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: Earthview - an orbital terrain rendering engine [v2.0]

Postby rominet » Fri Nov 18, 2016 7:32 pm

Screenshot of the month!

Cooling down... if I understood correctly, the best texture, in DDS format, can only be used with NVidia proprietary drivers, right? Not with AMD/Radeon free drivers?

Edit: adding a big "Thanks!" for all this work.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Earthview - an orbital terrain rendering engine [v2.0]

Postby Johan G » Fri Nov 18, 2016 7:34 pm

wlbragg wrote in Fri Nov 18, 2016 4:52 pm:That is really stunning! Great work guys!

+1 Indeed stunning! :D 8)
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: Earthview - an orbital terrain rendering engine [v2.0]

Postby chris_blues » Sat Nov 19, 2016 3:50 am

+1 on screenshot of the month!!!! In credible results! Earth rocks!!!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 7 guests