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 cgdae » Fri Mar 06, 2020 11:30 pm

For details about the changes to views, please see: http://wiki.flightgear.org/Changelog_2019.2#Views
cgdae
 
Posts: 117
Joined: Tue May 31, 2016 8:35 pm

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

Postby GinGin » Sat Mar 07, 2020 4:08 am

cgdae wrote in Fri Mar 06, 2020 11:30 pm:For details about the changes to views, please see: http://wiki.flightgear.org/Changelog_2019.2#Views



The old "Model View" interface is disabled by default, but can be reinstated by going to menu "View/View Options" and selecting "Legacy multiplayer view selector".


Thank you.
So no bug Chris :D
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

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

Postby eatdirt » Sun Mar 22, 2020 3:15 pm

Hi there,
@Thorsten, James pushed my additions in geo.nas (next-branch).

I wanted to also propose a merge request for fixing the issues in earth_N3.xml and clouds_N3.xml that are currently affecting earthview.
See previous posts, the last <animation> section of earth_N3.xml is missing, in fact it ended up in clouds_N3.xml. Due to this, earth N3 tiles is hiding earth S1, which can only be spotted by flying high enough. Let me know if you're ok with this.

Then, I let you have a closer look to the spherical tiles loading (https://github.com/eatdust/sphtiles/blo ... thview.nas) and do whatever you think is relevant with it?

Cheers,
Chris.

PS: If you miss my post on the forum, yes, nasal-gc-threaded=true is breaking the Shuttle calculations.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby Thorsten » Sun Mar 22, 2020 3:34 pm

If you have a merge request on SF, I can have a look and merge it (that works quickly via web interface). If it involves me pulling/compiling/installling stuff locally, I have to postpone this unfortunately, I'm rather occupied with the home schooling project and FG has been bumped waaay down on my priority list.

I don't have any conceptual objections against either merge request, if anything I guess style of the spherical stuff.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby eatdirt » Sun Mar 22, 2020 4:57 pm

If you have a merge request on SF, I can have a look and merge it (that works quickly via web interface).


Perfect, I'll do that with 2 merges then, one for the fixes, another one on the spherical tiles loading! Thanks.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby eatdirt » Tue Mar 24, 2020 2:34 pm

Huuuu, did not have time to post the links here Thorsten, James merged these requests almost instantaneously. The serious one is 182:

https://sourceforge.net/p/flightgear/fg ... uests/181/

https://sourceforge.net/p/flightgear/fg ... uests/182/

Cheers,
Chris.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby eatdirt » Tue Jun 02, 2020 9:14 pm

Hi,
I wanted to replace the Earth textures with the Moon's and, no surprise, it ended up being ugly.

First of all the moon altitude range between the deepest point and the highest point is 18km, for a radius of 1700km, that is more than 1% of the moon radius!!! On earth, that does not exceed 1 per mil. Then no atmosphere, no reflection, no specular light, the bloody moon is just diffusive dust for which the Lambert law is plain wrong. You can really spot it by eye.

So, I've tried to understand what is a shader last week, and I ended up with this:

viewtopic.php?f=19&t=37534

The best tutorial I've found online, more accurately the one I did understand, is this one (thanks Thorsten):

http://www.science-and-fiction.org/rendering/glsl.html

I really did find it by "duckduckgoing" GLSL, tutorial, shaders etc... LoL :D So I am not the only one to like it :)

That is still a ugly hack, nothing physical in altitudes of the UFO, the sun is not at the right place of course, and this creates issues because there are permanent shadows around the Moon's pole, which should never been lighten. I've been using the LROC images, and they are not illuminated at 90 degrees (for the previous reasons as well). There are LROC photometric flat images online but they all lack the poles, too bad :(

Anyway, here are the hacks:

The texture generator, fully inspired by Chris's (By the way Chris, I've solved the polar cap projection problem, the solution is called gdalwarp!)

https://github.com/eatdust/normalmap
https://github.com/eatdust/LROC2FGearthview

Edit: Texture generated available here: MoonView/

Pay attention to use the latest version of normalmap. I have indeed discovered that the high-res normalmaps we are currently distributing with NASA2FGEarthview have a problem. The "y" component seems to be flipped compared to what flightgear expects. It is almost unnoticeable while viewing the Earth because it mostly tilts the shadows by 45 degrees. But for the Moon and its huge relief, that was very clear, took me a while to understand (I'll fix the files as soon as I can).

A bit of tweaking for the files loaded by Earthview:

https://github.com/eatdust/moonshaders

This is only what have been changed compared to the distributed files, earthview is left untouched. Textures should go under the directory Models/Astro/Textures/ as usual. This is for moon_*.png texture files, the LROC generator produces dds files as well, but color artifacts are quite visible. If you lack graphic card memory, the dds are better suited, replace moon_*.png by moon_*.dds in all the ac files then (make a backup of the old files and directories).

Finally, it is difficult to remove the sky in FG :)

But this is doing quite a good job if you don't fly too low:
Code: Select all
fgfs --aircraft=ufo --prop:/sim/rendering/shaders/skydome=false


This disables ALS as well, so the SpaceShutte looks ugly around the Moon :)

Concerning textures size. If you have a big graphic card, the 16k heights and surface textures will take 6.2GB of graphics memory in total, so a recent 8GB G-force works with:

Code: Select all
--prop:/earthview/show-force-all=true


For more modest cards, the 4096 textures are already super nice, and they load fast. I did not try the lowest resolution textures, 1k and 2k, but they should be fine for the even more modest cards. I'll try to generate all texture sizes and put them online, but it takes quite some computing time...


I am not sure there is a future for this thing, we cannot go to the Moon with flightgear, but that was fun. And I would have never believed before that a simple normal map could render the relief as good as that. So cool.

Still need some shadows though!

I hope I did not forget a tweak file, ping me if required!

Cheers,
Chris.
Last edited by eatdirt on Thu Jun 11, 2020 10:38 pm, edited 2 times in total.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby GinGin » Wed Jun 03, 2020 9:49 am

Very nice.
Good work.

So it is either Moon 16 k or Earth 16 k textures with a 8 Gb of Vram ?
Could you make also an entry in the wiki page for all your work on previous 16 k earth textures, the code lines to load all the textures at once, etc

That would be a useful and direct link for people wondering how.
Or I can make it if you want
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

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

Postby eatdirt » Wed Jun 03, 2020 1:24 pm

So it is either Moon 16 k or Earth 16 k textures with a 8 Gb of Vram ?


Since I did not want to touch earthview, yes. As soon as your Models/Astro contains the tweaked files, moon textures will be loaded instead of earth textures. That is also why you need to add the *.frag *.vert and *.eff files in Effects/ and Shaders/, I did not want to touch the already existing files rendering Earth (planet-*.frag).

It would be not so difficult to modify earthview to support multiple bodies I guess, but this would need to be discussed first to make it in a proper way. And this triggers a pandora box of other questions. If we add the Moon, we should allow for putting new other bodies. And we should think about how to orient the body properly, how to change the day duration, etc... I suspect FG, or simgear, has never been designed to be extended as much.

Could you make also an entry in the wiki page for all your work on previous 16 k earth textures, the code lines to load all the textures at once, etc


There is an already existing wiki about Earthview and how to load high-res textures, I can make it up-to-date if everybody is ok with that, and maybe mentioning the way to get the Moon textures there as well?
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby GinGin » Wed Jun 03, 2020 2:39 pm

eatdirt wrote in Wed Jun 03, 2020 1:24 pm:
There is an already existing wiki about Earthview and how to load high-res textures, I can make it up-to-date if everybody is ok with that, and maybe mentioning the way to get the Moon textures there as well?


Yep.
That would be cool.
I got questions about Earthview, 16 k textures, seasons and script to load everything at once on discord or other forums.
I linked them on that thread, but that would be really good to have it in the earthview wiki page, as it is really usefull with powerful CG and RAM set up
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

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

Postby eatdirt » Wed Jun 03, 2020 3:29 pm

All right, I'll do that.

Among other problems, the seams are more prominent on the moon and quite visible as soon as the normalmap is switched on. And paying attention, I can see the seams on Earth as well as soon as we use a normalmap, in particular on specular reflection over the oceans. I've read through earlier posts, it looks like this is linked to uv map boundary conditions. And indeed, the normalmaps certainly kill the nice junctions between tiles made by extending the border.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby eatdirt » Wed Jun 03, 2020 8:48 pm

Here we go, moon textures are there:

MoonView/

I have also updated the normalmaps for the Earth textures by flipping "y":

EarthView.Clouds.Heights-2020.06/
Last edited by eatdirt on Thu Jun 11, 2020 3:44 pm, edited 1 time in total.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby eatdirt » Thu Jun 04, 2020 1:06 am

And indeed, the normalmaps certainly kill the nice junctions between tiles made by extending the border


I've just solved that!

Instead of propagating the last pixel to the edges to extend the texture, it is much much better to put a border cropped from the neighboring tiles. Done. Provided the normalmapping does not strech the texture by more than the border, you always see what you must see :)

I am good to regenerate the textures of the Moon, and also the Earth's :?
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby wlbragg » Thu Jun 04, 2020 1:49 am

So we will need to replace what we just downloaded from the previous post?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

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

Postby GinGin » Thu Jun 04, 2020 7:44 am

eatdirt wrote in Thu Jun 04, 2020 1:06 am:
And indeed, the normalmaps certainly kill the nice junctions between tiles made by extending the border


I've just solved that!

Instead of propagating the last pixel to the edges to extend the texture, it is much much better to put a border cropped from the neighboring tiles. Done. Provided the normalmapping does not strech the texture by more than the border, you always see what you must see :)

I am good to regenerate the textures of the Moon, and also the Earth's :?


Nice thanks.
So there are no more visible frontiers between tiles ?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 4 guests