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 chris_blues » Thu Jun 04, 2020 8:09 am

Good work Chris!

I seem to remember a discussion about the pixel propagation at the seams of the normalmaps. We were wondering about the order of the process. Propagate the border of the heightmap or the normalmap? Or in other words, do the propagation before or after converting the height map into the normalmap.

I hope that helps!

And nice to hear you found a solution for the pole problem! Maybe we're getting FG-Earthview back from the sad future of no polar icecaps.

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

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

Postby eatdirt » Thu Jun 04, 2020 11:29 am

So we will need to replace what we just downloaded from the previous post?


yes! you can compare both, check out the borders. The new textures are at the same location as before:

MoonView/

The old ones have been moved to:

MoonView/old/

Now each tiles have a bit of other tiles in it. The height mapping tells by how much a texture should be shifted at a given location. Close to a boundary, if the shift asks for points outside the boundary, you see a seems. Previously, we were seeing a seem of the same color as the closest point on the texture. With the new border, you see what is in the adjacent texture. As far as I understand, this is exactly what you are supposed to see, so there is no seam left.


So there are no more visible frontiers between tiles ?


The trick works provided the texture shift required by the height mapping is less than the border width we put. For the Moon's flying I've done this morning, that works super nicely most of the time. But, if you go to the polar region with the huge craters, take a low flying, then the parallax asks for a shift larger than the border width, so there, I see far away a seem appearing again. It disappears when you get closer, or higher, this is the expected effect.

There are still some lines visible, but they're not mine, they are the ones from NASA/ASU! There is a missing pixel line in one of the polar cap height map, and, at the pole the lighting is quite different between different tiles. Nothing we can do here, up to editing the map by hand. We can complain though to these lazy researchers ;)

But at low flying other issues appear. The parallax shift I am using searches for only one solution for the intercept of the line of sight with the heightmap. So distant deep craters at low flying appear to be "cut opened" because the line of sight finds an intercept for the inner wall and stops there. I am pretty sure well known methods exist to solve this, but I did not look into that...

And nice to hear you found a solution for the pole problem! Maybe we're getting FG-Earthview back from the sad future of no polar icecaps.


Yes, we would need good polar images, and some color matching, but that's possible. All the TIFF flags warning we see in the world textures are precisely datums, so all these images can be re-projected as we want with gdalwarp. I am currently testing what the new border method for NASA2FGEarthView gives!
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby eatdirt » Fri Jun 05, 2020 12:46 pm

Hi there,
I have been testing Earthview with and without the new borders method since yesterday. The new borders work perfectly fine for Earth, as expected.

But, my post is about a few issues that are currently with the stock Earthview, and the current distributed maps. Could someone confirm it is not just me:

1) The normalmap_*.png files do not have an alpha channel. I am opening them in gimp, it is only RGB, so we have been missing the heightmap since a long while?

2) I have this problem, difficult to spot, you need to be at a tuned angle to see it:

Normalmap switched off:

Image

Normalmap switched on:

Image


Since I am now able to speak a few words in frag, I would say this is coming from these lines of code in planet-high.frag.

Code: Select all
if (NdotL > 0.0) {
        color += diff_term * NdotL * (1.0-shadowTexel.a);
        NdotHV = max(dot(n, halfVector), 0.0);
        if (gl_FrontMaterial.shininess > 0.0)
            specular.rgb = (gl_FrontMaterial.specular.rgb * specular_enhancement
                            * light_specular * (1.0-shadowTexel.a)
                            * pow(NdotHV, gl_FrontMaterial.shininess));
    }


NdotL is computed from the normalmap, but NdotHV from the smooth normal to the sphere. I think the conditional NdotL is cutting hard the specular.rgb which is following the smoother n. I have tried first to replace NdotHV by the dot product of N and halfVector. The problem disappears but it also kills the nice dawn reddish light. It is more closer to the first image actually. A fix which is keeping the reddish color is this one:

Code: Select all
if (NdotL > 0.0) {
        color += diff_term * NdotL * (1.0-shadowTexel.a);
    }
if (NdotLfog > 0.0) {
      NdotHV = max(dot(n, halfVector), 0.0);
      if (gl_FrontMaterial.shininess > 0.0)
   specular.rgb = (gl_FrontMaterial.specular.rgb * specular_enhancement
         * light_specular * (1.0-shadowTexel.a)
         * pow(NdotHV, gl_FrontMaterial.shininess));
 }


where NdotLfog is defined as
Code: Select all
NdotLfog =smoothstep(-0.2 , 0.2, dot(n, lightDir));


@Thorsten, would you mind having a quick look just checking I am not saying bullshit, and which fix would be more convenient. Replacing n by N, or the one with two conditionals?

If you want I can do a merge request to fix that and also to push the new 2048 normalmaps having the height channel, the right y-flipped, and the new 2048 border safe world textures?

Cheers,
Chris.
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby Thorsten » Fri Jun 05, 2020 2:45 pm

1) The normalmap_*.png files do not have an alpha channel. I am opening them in gimp, it is only RGB, so we have been missing the heightmap since a long while?


The default distribution on FGData never had much resolution nor a hightmap - the main concern was to provide something reasonably small and working. The hightmap was only intended to be a feature of the optional addon distribution.

NdotL is computed from the normalmap, but NdotHV from the smooth normal to the sphere.


No, actually it should not do this. The basic problem (as you've probably discovered) is that the normal map allows things to be in light based on their orientation, but they're shaded based on the position on the sphere. So to avoid getting a series of bright dots into the night region, we need to cut on what is genuinely in shadow.

I've excessively tested this and never seen the thing you describe - dawn regions for me look like this

Image

Image

so the first thing I'd verify is whether you have introduced this problem during your recent experiments.
Thorsten
 
Posts: 11748
Joined: Mon Nov 02, 2009 8:33 am

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

Postby eatdirt » Fri Jun 05, 2020 5:05 pm

Thanks for the explanations!
Ok so no height in normalmap in stock is normal. I am not sure it would increase computational load though because the fragment shaders-high are already doing the computation even if you feed it with hmap=1?

so the first thing I'd verify is whether you have introduced this problem during your recent experiments.


I almost sure it is not the case, I am getting this effect with stock FG, but only when the specular light is visible. This is not happening on continent but over the ocean. To see it, I am going over the ocean, and then move the time settings to get the sun low enough to see the reflection, the red light, and as the sun goes lower the hard cut appears.
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby wkitty42 » Fri Jun 05, 2020 7:09 pm

could the "hard cut" be the earth shadow coming around?
"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: 6662
Joined: Fri Feb 20, 2015 3: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 Thorsten » Sat Jun 06, 2020 5:18 am

could the "hard cut" be the earth shadow coming around?


Well, yes - but it should not be hard.

I am not sure it would increase computational load though because the fragment shaders-high are already doing the computation even if you feed it with hmap=1?


Computational load is irrelevant because most users never fire up Earthview, size on repository / in download package is the quantity to be minimized. :D

I almost sure it is not the case, I am getting this effect with stock FG, but only when the specular light is visible.


Okay - that's probably bad, because I remember this being dicy - for some variants the outcome was extremely driver dependent for some reason I've never understood - the nouveau was just showing pure black while the nVidia was doing okay.

Since it's specular light on the ocean, I don't understand your reasoning though - the ocean is flat, so the normal map condition and the sphere condition are identical for a realistic normal map, which means that cutting on NdotL is /not/ hard in any sense, but as you approach the tangent it goes to zero smoothly and the condition just removes the shadow branch that is below zero. So we do all the song and dance for mountain regions and clouds which have structure, but shading the ocean should not be affected at all by the presence/absence of a normal map.
Thorsten
 
Posts: 11748
Joined: Mon Nov 02, 2009 8:33 am

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

Postby eatdirt » Sat Jun 06, 2020 9:11 am

size on repository / in download package is the quantity to be minimized


Arf, yes indeed, I did not think to that.

the ocean is flat, so the normal map condition and the sphere condition are identical for a realistic normal map, which means that cutting on NdotL is /not/ hard in any sense


I though the same, but the fact is that n (from the sphere) and N from the normal map, do not exactly match on flat surfaces, as the oceans. If part of the light use NdotL and other ndotL, using a conditional on one can produce a cut on the other, depending on which one goes to zero faster.
Then, I don't know what the graphic card is doing exactly, maybe that small mismatch is driver dependent, or maybe it comes from errors in making the normalmap, or maybe it comes from the fact the sphere is not a sphere but a set of polygons, but I have it there (nvidia drivers).
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby Thorsten » Sat Jun 06, 2020 10:13 am

I though the same, but the fact is that n (from the sphere) and N from the normal map, do not exactly match on flat surfaces, as the oceans.


But that would indicate that there's a problem with your normal map - a 'flat' normal map has only a z-component and by construction that gets mapped into the normal of the underlying surface only. To get any other direction from the normal map, it needs to be non-flat, i.e. have x (tangent) and y (binormal) components (I guess you understand why I am reluctant to make any change in the absence of proper understanding of what is going on that requires the change...)

Edit: here's an old dawn view of Ocean I've posted on the FG website - all looking good in the specular response:

Image

Edit2: and another one from flightsim.com

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

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

Postby eatdirt » Sat Jun 06, 2020 12:45 pm

Ok, I'll post a video to show this more carefully. As I said, this is stock FG, the normalmaps are not mine, not any line of code changed.

I am sorry to have been confusing before. I've found this problem indeed by testing my tweaks; flying the UFO for an hour or so around the Earth. But before I posted, I reverted back to stock FG, literally installing it again from scratch, to see if this thing was the consequence of some of my tweaks: it is not.

But maybe that is my graphic card doing funny things, I will try to test with nouveau too. Or maybe I am too perfectionist, but that bloody line kills the whole perfection, sorry :)
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby Thorsten » Sat Jun 06, 2020 1:08 pm

As I said, this is stock FG, the normalmaps are not mine, not any line of code changed.


I've been using Chris' hires textures and maps, so it's possible that there's no problem with these normal maps but there is one with the ones on the FG repository (haven't been using them much).

But the point stands - even after inspecting the code, I can't see how a flat normal map should be able to change the reflection of the basic mesh.
Thorsten
 
Posts: 11748
Joined: Mon Nov 02, 2009 8:33 am

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

Postby eatdirt » Sat Jun 06, 2020 7:43 pm

Here the video, stock FG. The normal map looks seriously flat over the Oceans, tested with both nouveau and nvidia driver.

I am 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. Here we go:

redcut_stockfg.webm

I have exactly the same with high-res normalmaps, so something makes n computed and N from flat normalmap quite different. I have not enough understanding of the underlying way things work, so I could not tell if this is possible or not.

From the embryonic things I remember from the GLSL tutorials, computation of normal, tangent and binormal are at the vertex level, while loading a normalmap is at the fragment level. Would it be possible that some smoothing applies only to N from normalmap while n jumps from vertex to vertex?

I have to say that while playing with the Moon, that binormal we have at the vertex level was behaving in a funny way, and I ended up computing it in the fragment shader by the cross(normal,tangent), maybe some nasty things happen to the normal as well?
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby Thorsten » Sun Jun 07, 2020 6:27 am

Would it be possible that some smoothing applies only to N from normalmap while n jumps from vertex to vertex?


The relevant line in planet_high.frag is

Code: Select all

    N = normalize(N.x * normalize(VTangent) * 0.6 + N.y * VBinormal * 0.6 + N.z * n);


where n is the normal from a sphere.

So - first important observation - we normalize N, so it is a unit vector no matter what. Good.

Second observation - N as it comes in is basically the normal map.rgb. So, if the normal map is flat, this should be (0,0,1) or N.x = N.y = 0, N.z = 1. If that is the case, the tangent and binormal are multiplied with zero and you end up with N = 1 * n, i.e. the normal-map modulated normal N is identical to the mesh normal n.

I unfortunatelt find the logic leading to this point inescapable (there's irrelevant complications in the way there's some flattening happening etc. which don't alter the fact that multiplying a complication with zero yields zero) - for n and N to be different, the normal map must be different from (0,0,1).

And that's independent on how other things are smoothed, whether something else jumps etc. If the normal map is flat, n=N is the outcome of the above line. If shading without a normalmap works based on the mesh, it must work with a flat normalmap, the math tells you so.

Welcome to the wonderful world of debugging... :evil: You need to find the one thing that breaks the above reasoning for you (but somehow not for me).
Thorsten
 
Posts: 11748
Joined: Mon Nov 02, 2009 8:33 am

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

Postby eatdirt » Sun Jun 07, 2020 10:17 am

You need to find the one thing that breaks the above reasoning for you (but somehow not for me).


Agreed. Just to be sure I understand, you say it is only me? Did you test along the lines I mentioned in my previous post and you don't have that line showing up?

Edit:
That is something I don't fully understand and changes the vector encoded in the normalmap?
Code: Select all
nmap.rgb = normalize(nmap.rgb);


Edit: That is a bug as far as I understand. The thing that should be normalized is 2 nmap.rgb - 1, one cannot have both normalized.
eatdirt
 
Posts: 653
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby Thorsten » Sun Jun 07, 2020 5:41 pm

Did you test along the lines I mentioned in my previous post and you don't have that line showing up?


I'm not doing any active FG development or testing at the moment - I don't even have the time to use it for enjoyment. So no, I didn't and I won't - I'm around to discuss, answer questions or process merge requests, but I won't be lured into lengthy debug sessions, sorry.

I dug up old pics to see whether I observed the phenomenon previously, and they would conclusively show I did not. So either it's my GPU playing along and yours not, or something critical has changed since I installed Earthview hires (I only did that on the 2018.3 I've been using for Shuttle enjoyment rides).

That is a bug as far as I understand. The thing that should be normalized is 2 nmap.rgb - 1, one cannot have both normalized.


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.

What really 'should be normalized' are vectors that are dotted into each other to get a sine/cosine of an angle - all else can be normalized or not.
Thorsten
 
Posts: 11748
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests