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 Thorsten » Sat Nov 19, 2016 6:49 am

if I understood correctly, the best texture, in DDS format, can only be used with NVidia proprietary drivers, right?


Compressed dds likely doesn't work on free drivers, yes. But Chris has the same texture also in png format - that will cause more memory occupancy and a longer loading time (I'm guessing some 2 minutes), but once it's loaded, you should see the same visuals with the same performance as if you would use dds. I have not tried how much worse the memory load with png is though.
Thorsten
 
Posts: 11135
Joined: Mon Nov 02, 2009 8:33 am

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

Postby rominet » Sat Nov 19, 2016 7:47 am

Thanks for the info, Thorsten, that is good to know. Looking at the wiki, the reality check fails elsewhere: I only have 256 MB of graphics RAM... clearly not enough for the 16k textures. Oh well...

Great work, anyway.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

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

Postby Thorsten » Sat Nov 19, 2016 6:05 pm

Well, yeah... that's a show-stopper.
Thorsten
 
Posts: 11135
Joined: Mon Nov 02, 2009 8:33 am

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

Postby rominet » Mon Nov 21, 2016 7:55 am

Well, I think I have misinterpreted the output of 'lspci -v'. 256 MB of VRAM seemed so small to me that I looked for other sources to get this information. 'dmesg' tells me:
Code: Select all
[   11.934147] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[   11.934208] radeon 0000:01:00.0: GTT: 1024M 0x0000000020000000 - 0x000000005FFFFFFF
[   11.934267] [drm] Detected VRAM RAM=512M, BAR=256M
[   11.934310] [drm] RAM width 128bits DDR
[   11.934402] [TTM] Zone  kernel: Available graphics memory: 4087108 kiB
[   11.934449] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   11.934495] [TTM] Initializing pool allocator
[   11.934542] [TTM] Initializing DMA pool allocator
[   11.934600] [drm] radeon: 512M of VRAM memory ready
[   11.934646] [drm] radeon: 1024M of GTT memory ready.

so it actually seems to be 512 MB of VRAM and a 1024 MB wide window of system RAM accessible via DMA, if I understand this correctly. So, maybe there is some hope...
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

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

Postby chris_blues » Mon Nov 21, 2016 9:11 am

My 1GB VRAM allows me EarthView with 8k resolution. It then uses about 700MB. (Haven't checked with latest EV yet)

If 8k doesn't work, then 4k should...

Cheers
chris
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: 1534
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 rominet » Mon Nov 21, 2016 7:57 pm

8k×8k works fine and loads relatively quickly (a few seconds, didn't try with clouds). Midnight was less pretty than noon, I should probably try dawn and dusk too...

Thanks
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

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

Postby chris_blues » Mon Nov 21, 2016 10:12 pm

Yes loading times have improved considerably! You should also play around with the overlay texture (or sth between those lines) - I'm not yet sure if I like the noise-overlay on the world-texture. :) Maybe there could be a check-box for that?

But the clouds are a MUST! Makes all the difference!

Have fun!
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: 1534
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 rominet » Tue Nov 22, 2016 7:19 pm

I have played a bit more... It's very nice when one stays at the proper altitude (or rather looks at things located at a proper distance). Too high gives the Earth weird geometric properties, and too low shows lack of data in the textures. Not sure about the "Overlay textures" either. At high altitudes, it's OK, but if the area looked at is too close, it creates visible patterns.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

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

Postby Thorsten » Wed Nov 23, 2016 6:42 am

Define 'too high' and 'too low'.

The 16k textures have 500 m x 500 m resolution per pixel - if you view that from 30 km altitude, you'll see that there are pixels. Overlay texturing hides their boundaries by adding noise and fiddling with the edges, and it goes some way to trick the eye that there's better resolution, but it can't supply detail that isn't there in the first place.

From a 300 km orbit, 16k is okay even when zooming in some, from 1000 km even 4k starts to look quite good.

Not sure about 'weird geometric properties' - I can go out to 3000 km without seeing problems and even if I go further predominantly the atmosphere is affected, but then again, different graphics cards have their own way of handling large numbers - a screenshot of what happens would be appreciated.
Thorsten
 
Posts: 11135
Joined: Mon Nov 02, 2009 8:33 am

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

Postby rominet » Wed Nov 23, 2016 8:19 am

I'll try to get more screenshots. Just for now, on http://imgur.com/a/DwvH8 :
- in the first five images, there is something fishy in the projection: Madagascar in the end appears to cover a huge surface of the Earth; the way Africa disappeared from the visible part was very weird;
- on the sixth image, there is a strange "envelope" around the Earth; the first time I tried Earthview, IIRC this particular thing aggravated when getting farther from the Earth, which appeared quite non-sperical (and not the physically correct oblate ellipsoid of revolution, there was an angular point, I'll try to reproduce this and get a screenshot);
- on the last image (very far), one sees a polygon rather than a disc.

But maybe these are due to changing the view orientation? Is it allowed?

There are nice shots too! http://imgur.com/a/Th36R
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

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

Postby Thorsten » Wed Nov 23, 2016 11:11 am

I'm guessing you didn't use ALS in any of those, so what the atmosphere does is up to anyone's guess, the classic and Rembrandt renderers don't come with a valid high altitude atmosphere visual model (and the white thing around Earth would be the skydome).

Also, for many you're quite a bit further out than 3000 km (that's just half an Earth radius) - you are likely seeing some clipping effect rather than an actual projection.
Thorsten
 
Posts: 11135
Joined: Mon Nov 02, 2009 8:33 am

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

Postby chris_blues » Wed Nov 23, 2016 11:19 am

That's what I'd call: Far out!

We've had that discussion before, but in another thread I believe (meaning Thorsten and me). If you're too far away from mother earth, the numbers go havoc. Imagine a double type number measured in meters (or possibly feet) developing over 1000km height. You'll have gaps between one bit more and one bit less. That's why the skydome comes creeping up from behind earth. And the corners of earth in the last pics might just show the same. Maybe some mipmap effect?
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: 1534
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 rominet » Wed Nov 23, 2016 11:35 am

Thanks for the replies. I did use ALS for all my tests (I read the wiki page). I do have the atmosphere rendering most of the time, but sometimes it disappears (maybe when I am too far away?).

Indeed, the problem I mentioned where I said the projection looks fishy is very likely a clipping effect because of the way I saw it evolve over time. And yes, I accept the explanation of numerical errors when distances are too large (this may be, in qualitative terms, your "too high", Thorsten :wink:).

I'll get to the "too low" (using 8k textures), but I am a bit short on time now for accurate reports, sorry. Anyway, there wasn't anything really unexpected here: just the texture being too coarse for the distance (maybe around 100000 feet high or less; and yes, I have read on the wiki the altitude range where you suggest to transition to normal FG rendering), and obvious difficulties of terrain loading (via TerraSync) for a high-altitude view when switching to normal FG rendering.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

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

Postby wlbragg » Thu Nov 24, 2016 6:52 pm

Any idea what to look at to fix this?
Image

I used the test orbital rendering code Thorsten posted and Chris's 8 or 16k textures (don't remember off the top of my head). Everything worked fine. Then when the final was pushed to FGDATA I removed the testbed edits and pulled the FGDATA changes. I don't know if that is when it broke or something else may have caused it.

If you recognize the overall failure and specifically where the green arrow is pointing and can point me the right direction it would make fixing it easier. Otherwise I will have to wipe some things and pull fgdata again and hope it works.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4927
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

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

Postby Thorsten » Fri Nov 25, 2016 6:17 am

The overall failure is a non-compiling shader (or a texture loading issue?), and the thing pointed to is a city light encoded in the alpha channel which you see as fully transparent if the shader doesn't work, and since the skydome is 'behind' it it appears white/blue.

-> We need the error message from the log file.

Though the Shaders of the pushed version ought to be identical to the alpha version - I just fixed a few Nasal-side bugs. So there's that...
Thorsten
 
Posts: 11135
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 0 guests