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 GinGin » Mon Feb 03, 2020 12:44 pm

I will give it a try this week.
The one from EatDirt direct Link and Chris torrent are the same ?
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 chris_blues » Mon Feb 03, 2020 12:47 pm

I just took the missing normalmaps, that my machine refused to process. And then I baked this torrent. EatDirt only provided the 8k and 16k textures, in the torrent there is all texture sizes.

So yes; since we both generated the textures with the same script, they should be identical.
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
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2: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 » Mon Feb 03, 2020 1:23 pm

Here a first working version of my nasal tutoring project that loads Earthview tiles based on spherical geometry:

https://github.com/eatdust/sphtiles/tree/master/Nasal

Up to unexpected bugs, you won't see any differences in SpaceShuttle and LEO, up to a smaller memory usage as visible tiles are unloaded a bit sooner while invisible tiles are loaded a bit later than the current way. The differences mostly appear on high earth orbits, like with the UFO, or super-elliptical trajectories, tiles loading should now be complete for these.

No fps changes for me, but I am welcoming any critics/remarks/advices, that's my first ever coding in Nasal... :oops:

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

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

Postby wlbragg » Mon Feb 03, 2020 5:18 pm

Hey Chris,

Are you planning on eventually requesting a merge into fgdata with this?

If it's better than what is already there, I think you should.

It doesn't matter if it is your first nasal foray or your billionth. :)
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 Hooray » Wed Feb 05, 2020 7:39 pm

the best option to get something like this reviewed and possibly committed is to provide a startup/runtime option to enable/disable your modifications, so that the reviewer (I suppose Thorsten) can easily test for regressions, but also so that any regressions that may show up later can be addressed by simply disabling the new option/code until it is fixed for good

Also, if you are replacing/adding new geo related functions, it would make sense to provide a few self-contained unit tests so that both APIs can be checked against each other, to provide a scripted option for testing purposes (continuous integration) - these checks could be executed while starting/re-initializing fgfs, and would only show a message if an error occurs, so that such problems can be easily spotted in the future.

If something does indeed perform faster, you can optionally use debug.benchmark() to compare execution times
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

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

Postby eatdirt » Thu Feb 06, 2020 11:12 am

@Wayne and Hooray, yes, why not. The code still need some testing from my side, but once done, and only if Thorsten thinks there an interest, I can indeed work on how implementing a runtime switch-on.
That's not easy though as the changes are in a control loop, so any switch should rather be above it, and thus I would certainly need to write a second control loop for that purpose. I'll be happy to have any link to example as I have no idea how to set an init/runtime switch.

For geo.nas, the interest may be larger than the SpaceShuttle, I've added two new functions, one returning the distance to the horizon, the other the shortest distance to another route on Earth. But here as well, I'll be happy to have links/example for such "unit tests". Notice that the API has to be backward compatible, I've added only 2 new methods without touching anything else.

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

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

Postby chris_blues » Thu Feb 06, 2020 6:12 pm

Having just looked at a few textures, I'm beginning to see the reason for these color distortions eatdirt mentioned. He also told me, they are related to the ice sheet, which once must have been *on* the world maps. And looking at the textures NASA provides, I'd guess they had a tough time separating the data sets from one another. The north-polar ice-cap is made up of sea-ice. And they filtered out all sea-ice from the worls-map, so that's probably the artefacts we're seeing.

Which brings me back to the old point, where I was very annoyed and frustrated as to why they actually removed the sea-ice. The sea-ice maps they do have, are of terrible resolution. Yes you can get 8k maps and such, but if you look closely, the ice-pixels are about 20 or 50 pixels in size...

If only they had left the sea-ice in there...
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
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2: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 Thorsten » Thu Feb 06, 2020 6:36 pm

and only if Thorsten thinks there an interest, I can indeed work on how implementing a runtime switch-on.


Don't bother, I think I'll be able to understand the changes in geometry just fine, and if it tests out okay for you, then we can use it. There's not much that can go subtly wrong after all.

For geo.nas, the interest may be larger than the SpaceShuttle,


It actually isn't - the 'move aloing a great circle' method in geo.nas is actually flawed for distances > 12.000 km, so at some past point I asked whether it would be worth fixing it (possible breakage if things rely on the fault) and there was zero interest, so I've been implementing all geometry since as part of the Shuttle private lib.

From where it can easily be moved elsewhere - but the fact of the matter is that there's zero interest in any inertial pointing, orbital computation or such like otherwise.

If only they had left the sea-ice in there...


They probably didn't have a consistent data set. :(
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby eatdirt » Thu Feb 06, 2020 6:54 pm

then we can use it. There's not much that can go subtly wrong after all.


Yes I agree!

I am seeing one issue that I am fighting with right now. I came to the conclusion that it is not due to tile loading, sometime terrain S1 and only terrain S1, is just not showing even though it is correctly set to "visible". The clouds are visible, just the terrain tile remains out. S1 is the only tile in which there is almost no elevation and I am suspecting that something else forces it to be invisible. Would it be possible that it ends up being hidden under the untextured sphere sometimes due to some numerical rounding?

Edit: It seems that S1 is not showing when another tile is shown, seems to be N3, GPU memory is fine. I even try by forcing all tiles to be loaded at once, then S1 is never shown. Might it be some flipped normals somewhere?

This drives me mad, I've been through earthview.nas ten times (I think I've found a typo there by the way: https://github.com/eatdust/sphtiles/com ... 77a6bdb9fb)

'move aloing a great circle' method in geo.nas is actually flawed for...


You mean these *_course_to* methods? Did not check these ones.

and there was zero interest, so I've been implementing all geometry since as part of the Shuttle private lib.


Ok, that's sad. No pb for me to fold back everything in the Shuttle lib. Lol, I did make an effort to put all the geo methods in geo.nas to be object-oriented friendly :) Since I am still in an naive state, I can insist on the mailing list. If the methods are flawed and nobody cares, that's like a boomerang, it usually goes back to your face.
Last edited by eatdirt on Sat Feb 08, 2020 3:09 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 GinGin » Fri Feb 07, 2020 11:06 am

Do we have to specify the path for normalmap.png and heights.png in some files ( AC or XML in the Astro root), like we had to do for the world png or dds textures in earthN1.ac etc and earth_unitscale.ac ?
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 » Fri Feb 07, 2020 1:53 pm

Do we have to specify the path for normalmap.png and heights.png in some files


No, it should work out of the box once the normalmap_* files are put under the Model/Astro/Textures/ directory. The height*.png files are not used. They are the source of the normalmap*.png and we have let them here just in case you would fancy processing them differently (for instance with photoshop, gimp, or see all possible options in the normalmap binary https://github.com/eatdust/normalmap).
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

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

Postby GinGin » Fri Feb 07, 2020 7:16 pm

Thanks.
Download finish from direct link, I will reinstall a torrent soft to test chris ones later.

Tests this week end :)
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 » Sat Feb 08, 2020 3:38 pm

Ok, I confirm that there is an issue with the earth_*.ac files. The "dummy" texture of earth_N3.ac, which has exactly the same coordinates as the "world" texture of earth_S1.ac is hiding it when both of these tiles, N3 and S1 are loaded. I have even tested it by removing the "dummy" part in earth_N3.ac, and then I can see the whole earth full tiles loaded without any issue (tested on 2 computers with next and 2019.1).

What I don't understand is why the issue only shows up for the pair N3/S1, because the dummy coordinates of the all the northern tiles indeed match the world textures coordinates of one of the south tiles.
I would need the help of someone understanding this files to fix it, but it looks like some normal vector flipped or not flipped

Edit: Ok, that was easy to fix but not easy to find :) In Model/Astro, the file earth_N3.xml misses these last lines:

Code: Select all
<animation>
  <type>select</type>
  <object-name>dummy_N3</object-name>
  <condition>
   <property>/earthview/show-dummy</property>
  </condition>
 </animation>


As an aside remark, I think we could also have a command-line switch to force the loading of all textures all the time for people having a lot of graphics memory. It takes 1 or 2 mn, 7GB of GPU memory for 16K textures. But once loaded, man... That's fantastic and super smooth!

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

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

Postby GinGin » Sun Feb 09, 2020 5:04 pm

eatdirt wrote in Sat Feb 08, 2020 3:38 pm:
As an aside remark, I think we could also have a command-line switch to force the loading of all textures all the time for people having a lot of graphics memory. It takes 1 or 2 mn, 7GB of GPU memory for 16K textures. But once loaded, man... That's fantastic and super smooth!

Cheers,
Chris.


Totally up for that, tell me how you do this :)
Thanks for the work around for textures, issue was a problem with hand over during texture loading ( didn't experience that)

I got that in N3.xml
Code: Select all
 <animation>
  <type>scale</type>
  <x-offset>58030</x-offset>
  <y-offset>58030</y-offset>
  <z-offset>58030</z-offset>
 </animation>


I replace it then ?

i tested the 16 textures, can't say if I see real difference, but is still beautifull
That takes me 10 go of ram just for FG, don't know about you ? I will compared with previous set of 16 k textures.


Also I tested with and without textures overlay.
Can't say the one I prefer.
With overlay is supposed to be the most realistic ?

Without

Image



With

Image
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 Feb 09, 2020 7:30 pm

Totally up for that, tell me how you do this


:) If you're brave enough, you can test my modifs (as far as I have tested now, that works). Backup the overwritten files though!

https://github.com/eatdust/sphtiles/

The directory tree is respected, so the earthview.nas, geo.nas should go into the install dir of flightgear/Nasal/, and the default.xml just above (that's forked from the next-branch 2019.2.0).
I've added
/earthview/show-force-all
in the property tree, so if you start fgfs with --prop:/earthview/show-force-all=true full texture loading will be done. Mind that if you graphic card or RAM is not enough, you're certainly good for a crash/reboot... Yes, expect minimum 7-8GB on the GPU, between 10 and 20GB on the RAM depending how many 16K textures you're using.
You can also access it with the Property Browser under /earthview and set it to true with the mouse (CTRL+click).

Now, for the file earth_N3.xml, do not replace anything, just append the missing lines at the end of the file (you can compare to earth_N2.xml for instance which is ok).

Let me know if you see any issues, that'll be probably my fault then :)


For the overlay, it is very good in hiding defects from low altitude and increases a lot the details on the clouds. But if you start flying high (see Van Allen mission), the periodic pattern starts to be very visible and the view gets nicer without.

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

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests