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 » Mon Jan 27, 2020 10:22 am

Thorsten wrote in Sun Jan 26, 2020 8:03 pm:Obviously you could manually repaint to the same blue hue (or automatically, though I don't know how that works). :D


That might be possible, though I don't think this is a good approach. I wouldn't wanna use huge sattelite images with great detail and paint them uniformly afterwards. Seems backwards somehow...
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: 1570
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 Thorsten » Mon Jan 27, 2020 10:30 am

Well, the problem is that in the input texture data there is a color variation that *probably* should not be there (I'm vaguely guessing that sea color is artificial in these textures, as it's likely not real - sea color is to a good degree created by sky reflection and that's never so uniform as in these textures.

Since we faithfully process input data, you get the variation correctly translated into the output. If you don't want it there, the most straightforward way is to change the input data in some way.

So I don't know what approach you are imagining instead :?:
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

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

Postby chris_blues » Tue Jan 28, 2020 6:56 am

I wasn't imagining anything at all! :) I'm rather out of ideas at this point.

If we were to change the textures in some way, I foresee the following obstacles arising on the horizon:

  • Use ImageMagicks "MagickWand". That's about the same thing as the wizards magic wand in any graphic program. Select all areas that share the same color up to a certain tolerance. But I believe all of us have seen this kind of thing work. And now imagine, what it would do to, say, the Caribbean. Or the big river deltas.
  • Use some kind of vector data to paint the coast lines uniform blue. Pretty much same effect to the caribbean.
  • Do it by hand. Well I guess no one has that kind of spare time...

So, none of these options seem very helpful...
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: 1570
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 Thorsten » Tue Jan 28, 2020 7:59 am

And now imagine, what it would do to, say, the Caribbean. Or the big river deltas.


Not much if the tolerance is chosen small enough I guess - it would seem the problem arises from pixels which are visually not different but actually have a slightly different color value - which then shows up in the reflection. Tagging these pixels would not visually change anything since... they're visually not different now.

Basically reflection isn't going to be perfect till we use a dedicated reflection map, but since I don't think there's a free texture slot any more, it'd mean increasing memory occupancy by yet another 16k texture - which is probably crippling.

So it means either repair work on the textures or leave as is.
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

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

Postby eatdirt » Tue Jan 28, 2020 1:36 pm

So it means either repair work on the textures or leave as is.


Or, this works quite fine, changing this

Code: Select all
oceanness = smoothstep(0.0, 0.1,length(texel.rgb - vec3 (0.007,0.019, 0.078)));


to

Code: Select all
oceanness = smoothstep(0.05, 0.15,length(texel.rgb - vec3 (0.007,0.019, 0.078)));


clamps the reflections made by that very color fluctuations. I do not see visible changes elsewhere, but I did not try to optimize too much the lower bound (put 0.15 to preserve the range, but 0.1 works fine too).

Thorsten, I have been playing a lot with the UFO in Earthview, I think I love the UFO now.... But I think I spotted some issues with the loading of the texture tiles when I am far from Earth. I have been looking at the code a bit, and if I understand it, from what I see, the tiles loading is designed for object being not too far from the ground, I mean real flying object like the SpaceShuttle right? If yes, I'll be interested to improve it with some exact calculation in spherical geometry, for me that could be some doable project for learning nasal. Is there anything I should know before trying to do so?

Thanks!
Cheers,
Chris.
eatdirt
 
Posts: 497
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby Thorsten » Tue Jan 28, 2020 3:32 pm

I have been looking at the code a bit, and if I understand it, from what I see, the tiles loading is designed for object being not too far from the ground, I mean real flying object like the SpaceShuttle right? If yes, I'll be interested to improve it with some exact calculation in spherical geometry, for me that could be some doable project for learning nasal. Is there anything I should know before trying to do so?


To say it bluntly - the whole of Earthview is designed to be seen from low orbit - there's a whole host of things which you would not do from far away (loading 16k textures for starters to see their lowest mipmap levels only :mrgreen: ), then having a separation between clouds and terrain which leads to z-fighting,...)

You should know that it's a pretty delicate balance just how and when to load things - if you end up loading 'too much' with 16k textures, you drive even a well-equipped computer into swap - if you load 'too little', so see temporary gaps.

Change at your peril, there's quite a number of ways to get this really badly wrong.
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

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

Postby eatdirt » Tue Jan 28, 2020 8:01 pm

Change at your peril, there's quite a number of ways to get this really badly wrong

:) Yes indeed, I remember the Z-fighting in the Van Allen mission, had forgotten. Thanks for the infos!
eatdirt
 
Posts: 497
Joined: Wed Aug 15, 2018 2:06 pm

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

Postby chris_blues » Fri Jan 31, 2020 1:43 pm

Hi guys!

I'm just running tests on the new generator script to produce all the textures. Plus, I seem to remember some talk about missing space for more textures (couldn't find it at a glance). There actually is a lot of space! The cloud textures have 3 empty channels available for 3 new maps or textures or whatever. The clouds are composed of a white image (3 RGB channels on 255) and the actual information is only in the alpha channel. Thorsten would probably have to change the way the clouds are rendered, but the space is available!

Just thought I'd let you know...

Cheers!
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: 1570
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 Thorsten » Fri Jan 31, 2020 1:47 pm

Yes, but the cloud sphere can be shifted with respect to the terrain, so you can't encode terrain info in there. You could encode more cloud info, but I don't think we have it.
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

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

Postby chris_blues » Fri Jan 31, 2020 4:46 pm

Thorsten wrote in Fri Jan 31, 2020 1:47 pm:Yes, but the cloud sphere can be shifted with respect to the terrain, so you can't encode terrain info in there. You could encode more cloud info, but I don't think we have it.

I see. Too bad! :)

The other thing is, @dirteat: the script and normalmapping/heightmapping seems fine. 8)

Here's my latest generation of the convert script (torrent).
*********** magnet link removed, see below ***********

Once it's confirmed to be good we can announce it through the FG-channels. (Wiki, here, mailing list)

I got one note to add: I found heightmaps in the output folder. I added them to the torrent. Fortunately the datasize is even smaller than the old one (6.6GB vs 6.8GB), despite the additional heightmaps! So there's definitely improvement...
Last edited by chris_blues on Fri Jan 31, 2020 6:18 pm, edited 1 time in total.
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: 1570
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 GinGin » Fri Jan 31, 2020 5:25 pm

Great job guys.
What kind of cloud textures would you need ?
GinGin
 
Posts: 918
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

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

Postby chris_blues » Fri Jan 31, 2020 5:28 pm

chris_blues wrote in Fri Jan 31, 2020 4:46 pm:Fortunately the datasize is even smaller than the old one (6.6GB vs 6.8GB), despite the additional heightmaps! So there's definitely improvement...

...or maybe not!

I found the problem. The 16k normalmaps have 32kB filesize each... :cry:
I noticed some output by convert when generating the 16k normalmaps. Sth about problems allocating memory. So probably my 8GB just don't cut it, or I should limit IM in the script at that step. I'll dig in a bit...
Last edited by chris_blues on Fri Jan 31, 2020 5:41 pm, edited 1 time in total.
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: 1570
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 chris_blues » Fri Jan 31, 2020 5:41 pm

GinGin wrote in Fri Jan 31, 2020 5:25 pm:What kind of cloud textures would you need ?

I don't understand. What cloud textures and why?
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: 1570
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 chris_blues » Fri Jan 31, 2020 5:50 pm

Found it. Normalmap is trying to allocate more memory than my 8GB, so it fails with:
Code: Select all
Memory allocation error!: Cannot allocate memory


So, I guess, someone with more than 8GB RAM has to try this... My 8k normalmaps are fine.

Edit:
I'll remove the torrent, since we already know it's faulty. If one of you could send me the 16k normalmaps, then we can release it into the realm of the holy torrent... :lol:
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: 1570
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 eatdirt » Fri Jan 31, 2020 8:04 pm

Hi Chris,
yes, I can generate the 16k normalmaps, I'll do it this week-end then!
Thanks for the tests!
eatdirt
 
Posts: 497
Joined: Wed Aug 15, 2018 2:06 pm

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest