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 eatdirt » Sun Jun 07, 2020 8:34 pm

I don't even have the time to use it for enjoyment.


Sorry, would be nice if someone else could test then.

it's a redundant operation, but not a relevant thing because there's the flattening shananigins going on later anyway and we normalize the end result.


I really do think it is a bug:

If nx=2 x - 1 and so on for y and z, enforcing x^2+y^2+z^2=1 and nx^2+ny^2+nz^2=1 necessarily induces a funny dependency on nx, ny, nz. Removing that normalize(nmap.rgb) line fixes the red-cut, works for me TM :)
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby Thorsten » Mon Jun 08, 2020 6:40 am

Okay, if that is so then please remove the line and test the Himalaya is rendering okay (says it does sanity processing at the edge of the heightmap, so that'd be either oceans or the highest mountains).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby eatdirt » Mon Jun 08, 2020 3:53 pm

please remove the line and test the Himalaya is rendering okay


In fact, we should be careful, my turn to be reluctant :)

This normalization is artificially creating parallel components on N, and I do see that you have tweaked other parts of the code to give a good rendering, by precisely damping the parallel components, like the 0.6 factors on Nx and Ny instead of 1, etc...
I am afraid that just removing it could also badly impact everything you have tuned, so I'll test for a while. I'll report what I see, and we can for sure wait you're back for flying to push any change!
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby wlbragg » Mon Jun 08, 2020 5:33 pm

Sorry, would be nice if someone else could test then.

I tried to reproduce but don't think I got the orientations and position correct. If you could give me detailed instruction as to how to set up for the test I can try it again.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
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 eatdirt » Mon Jun 08, 2020 7:05 pm

If you could give me detailed instruction as to how to set up for the test I can try it again.


Thanks Wayne, please try like this:

taking off with the UFO at KTTS, 10 sec of 100000m/s flight up over the Caribbeans (speed max with keypad ]). Then I play with the time to be at sun rise.


Ensure in the EarthView menu that you have "Terrain Normal Map" enabled, and move the sun to the East. Like in the video I posted, Environment -> Time settings you can click on "Dawn" and then use the Time Warp to move time even earlier till the sun kisses the horizon. You have to see the reflection of the sun over the Ocean, let the accelerated time go on forward, or backward as needed, to scan all angles. The red-cut should appear from some range of angles. I am testing stock FG, there are normalmap_earth* in Astro/Textures/
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby GinGin » Mon Jun 08, 2020 8:33 pm

I have some time this week.
I will test that also.
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 17, 2020 11:23 pm

All right, I think I nailed the redcut for good. It was quite subtle. Let me try to explain with a few pictures, and 2 lines change in planet-high.frag

Let me recap what I see with current stock FG (no tweaking).
normalmap enabled (planet-high.frag in use)
Image
normalmap disabled (planet.frag in use)
Image

Now the fix I proposed earlier, i.e., removing this line
Code: Select all
nmap.rgb = normalize(nmap.rgb);

Image
Compared to the previous image (no normalmap), it is quasi-identical, so, indeed, normalizing(rgb) created spurious normal effects.


Now, look at that, without normal mapping, I am pushing the sun quite low and a very small redcut appears, difficult to spot because the luminosity of the reddish light is low.
Image

This drove me mad, but this tiny cut comes from this conditional in planet.frag
Code: Select all
if (NdotL > 0.0)

The fix is to relax the strictly positive!!!! It looks like the graphic drivers, at least both nouveau and nvidia, are really happy to truncate a strictly positive to a value which is quite far from zero :shock:

Ok, let's see how the two issues interfere? Here I am testing the normalmap enabled, with the relaxed conditional, i.e., in planet-high.frag I have
Code: Select all
if (NdotL >= 0.0)

and I keep
Code: Select all
nmap.rgb = normalize(nmap.rgb);

We get:
Image

The cut is gone. But, the reddish color is very bright, and very red, much redder than what we have with no normalmap (see 2nd picture). This is not expected on the oceans, normalmap, no normalmap should give the same behaviour. So, yes, there is not one but 2 issues at work, and one issue was actually put in evidence by the other.

In conclusion, the fixes are:

1) In both planet.frag and planet-high.frag, we should relax the conditional, i.e., replace
Code: Select all
if (NdotL > 0.0)

by
Code: Select all
if (NdotL >= 0.0)


2) In planet-high.frag, remove
Code: Select all
nmap.rgb = normalize(nmap.rgb);


And here how it is after the fixes (no differences at all between normalmap enabled or not), I post only one picture for this reason:
Image

I can propose a merge request if you want Thorsten, I do not see the shadow of a cut anymore and the normals become very smooth once the rdb normalization is removed. I've even tested changing the 0.6 factor you put on nx, ny to 1 and I do not see any change on cost lines. Mountains look a bit sharper though.

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

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

Postby eatdirt » Thu Jun 18, 2020 12:14 am

Unrelated, but here the difference between the new bordering for EarthView's tiles and the old one:

Old one, color pixel extended:
Image

New one, border cropped from neighbor tile:
Image

The seems are particularly visible for clouds, they're quite high and their shadow asks for texture pixels possibly lying on neighbor tiles. Now, they're gone :)

For the moon, I would even need larger borders, the relief is so high. But I think that would require making a new UV-sphere with overlapping maps, and I have actually no idea how to make that. If anyone has a link, I am interested!

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

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

Postby GinGin » Thu Jun 18, 2020 10:55 am

It looks awesome.
Great work.
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 wkitty42 » Thu Jun 18, 2020 4:53 pm

very nice troubleshooting and problem solving work!
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9125
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

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

Postby wlbragg » Thu Jun 18, 2020 5:43 pm

Really nice work Chris.
Thanks for taking time with this and cleaning things up. It can take take vasts amount of time polishing stuff. I spent a good bit of time yesterday cleaning up the fg1000 in the J3Cub/PA-18 and all I did was tie it back into fgdata VS local and size it on the various variant panels as large as I could make it. One thing always leads to another and it's almost always the hidden discoveries that are the final fix and time consumers.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
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 eatdirt » Thu Jun 18, 2020 10:55 pm

Thanks guys!
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby eatdirt » Sun Jul 12, 2020 8:51 pm

Hi there,
I've had some time to prepare for a merge request; Thorsten, if you want to have a look, here it is:

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

The first commit is the redcut fixes, the second one are for new default textures with the new boundaries. I've also added the missing alpha channel in the normalmap, the whole texture set takes now 52MB instead of 49MB previously. I honestly think the 3 extra MB are worth the improvement, but feel free to revert the second commit if you don't think so.


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

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

Postby eatdirt » Sat Sep 26, 2020 10:20 am

Thanks Thorsten for the push!

I've given a shot at enabling compositor, and this is quite a catastrophe for Earthview, the whole planet looks like a giant swimming pool full of giant caustics :-/

I've discovered that the Compositor uses Shaders and Effects there:

flightgear/Compositor/Shaders
flightgear/Compositor/Effects

and my push made these guys out of sync with the standard ones. So I can try to fix that along with the caustics, but if any if you has an idea / advice from where the giant caustics come from, that would be nice!

Edit: With 2020.3.1, most of the above-mentioned issues are solved, but you have to start with:

Code: Select all
--Compositor=compositor/als


I'll push an update to the Shaders in Compositor/ to implement the red-cut fixes as well.


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

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

Postby Gomendio » Tue Mar 30, 2021 5:13 pm

Hi to all.

I've found myself tinkering a bit and took the plunge to install the 16K earthview textures. I've followed the root and put directly onto the \FlightGear 2020.3.6\data\Models\Astro\Textures overwriting
the pre existing ones.

Running under 20.3.6 and with the latest dev version every time I launch "Uphill" and when the eartview is triggered I suffer an CTD. I try as well to open up the eartview consol and acitvate manually. The CTD happens right away I press the start button.

Is there any other tweek that has to be done to use the 16k o the 8k textures other than install and overwrite the prevous files ?

thanks in advance.
Gomendio
 
Posts: 29
Joined: Fri Oct 25, 2019 11:03 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest