Board index FlightGear Development Scenery

Next-generation scenery generating?

Questions and discussion about enhancing and populating the FlightGear world.

Re: Next-generation scenery generating?

Postby psadro_gm » Sun Oct 02, 2016 4:05 pm

Here you go, Bugman :)



at the very beginning, you can see I don't handle the poles correctly, as well - I need to generate the top / bottom row as single triangles, not pairs (quads).
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby Hooray » Sun Oct 02, 2016 4:10 pm

Here's Zan's original thread discussing Fred's LOD approach and his own ideas to address such issues: viewtopic.php?f=5&t=11592
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: 12092
Joined: Tue Mar 25, 2008 8:40 am

Re: Next-generation scenery generating?

Postby psadro_gm » Sun Oct 02, 2016 7:04 pm

I remember reading that so many years ago. So much went over my head.

Most has been implemented:
- vfp dem
- apt.dat 850

What's exiting, is the work with curves rendered with shaders. Looks like it can pick one of two colors. I am wondering if the technique could be extended to warp an image
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby Hooray » Sun Oct 02, 2016 7:51 pm

yeah, looking back, it would actually have been a good idea to preserve such ideas/discussions and maybe come up with a corresponding wiki article and update that over time - according to the devel list archives, Tim Moore was also experimenting with a LOD scheme - had such ideas, and the corresponding code, been preserved in some form, it would be much easier for people to continue such work, should RL take over at some point.

Thus, I really hope that you find some time to get your work committed and documented, even if just in the form of a topic branch and a README.LOD file for $FG_ROOT/Docs - with so much work that never made it back into the project (Fred's, Zan's, Tim's, Mathias', Manuel Massing), we could really be standing on the shoulders of giants, had such experiments been documented and shared more rigorously, regardless of it just being proof-of-concept

Unfortunately, this also applies to other areas in FlightGear ...

PS: Note that Zan also posted his "new-camera" experiments, which exposed the effects framework so that cameras could be rendered to scenery textures - the original screenshots posted on the forum are long gone now, and all this took place at the time when everybody was considering to make Rembrandt the default rendered, so it was conflicting with Fred's commits - but the code is still there, and Fred and Mathias were actually contemplating to get Zan's work integrated: http://wiki.flightgear.org/Supporting_m ... _.28Zan.29

This is the sort of thing that could put procedural texturing on steroids: https://gitorious.org/fg/zans-flightgea ... newcameras
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: 12092
Joined: Tue Mar 25, 2008 8:40 am

Re: Next-generation scenery generating?

Postby vitos » Mon Oct 03, 2016 6:29 am

Having in mind that such attempts was made for years at my memory, looked promising, but not one led to final implementation, it seems that there is some things and forces at FG which prevents it. So, I would say, if You would meet some troubles, then not drop Your efforts, but think about fork, and count me in - we will find others who are interested in open development truly. If these forces are not existed really, and there will be correct new engine at FG itself finally - OK, why not. Anyone have right to change to better.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Next-generation scenery generating?

Postby erik » Mon Oct 03, 2016 8:18 am

It really would be great to get the scenery-module plugin system ready for this effort. Unfortunately I'm too unfamiliar with the scenery code to take a stab at it myself.

At a first glance it looks really promising but the videos seems to reveal that the hight map resolution is a little lower that what we have now (not the hight itself but the horizontal resolution). I might be wrong though since I don't know the technical details and I've only seen two areas that are unknown to me without any comparison.

Then again, you could argue that the benefits of the LOD system are larger in the end.
Great work.

Erik
erik
 
Posts: 1764
Joined: Thu Nov 01, 2007 1:41 pm

Re: Next-generation scenery generating?

Postby bugman » Mon Oct 03, 2016 9:40 am

psadro_gm wrote in Sun Oct 02, 2016 4:05 pm:Here you go, Bugman :)


Apart from some cosmetic artifacts, this looks like an awesome technology preview for the next world scenery series (WS v3.X). Hopefully those working on improving the earthview renderer see this and join in the effort. I guess that high resolution, whole earth, day and night textures from the NASA blue marble series wouldn't be a problem to use on the highest LOD tiles and then to ship it to users via TerraSync.

Cheers,
Edward

Edit: For those planning to head to the moon, maybe one more LOD level with a low resolution texture would be of interest in the distant future.
bugman
Moderator
 
Posts: 1799
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Next-generation scenery generating?

Postby Thorsten » Mon Oct 03, 2016 10:17 am

Hopefully those working on improving the earthview renderer see this and join in the effort.


Those working on the Earthview renderer hate to spoil the party, but don't see the need for Earthview gone for a number of reasons:

* shaders work in floating point precision, and hence complex shaders break and render garbage if you push large numbers to them. There's a reason FG has a default far plane clipping at 120 km - and there's most definitely a reason Earthview uses ray optics to get the vertex coordinates scaled down into a range shaders can sanely process. Thus, while Earthview can use any shader you can dream up on the terrain from orbit, you can't if you use 'real' vertex coordinates in meters.

* there's no strategy we can blend over from pale blue marble to the forseen procedural terrain texturing - and pale blue marble has a resolution of a few hundred meters per pixel on the ground, so it's just not an option for close up - I don't know about you, but rather than having pale blue marble and vectorized terrain procedurally textured in view at the same time for an extended period, I'd much prefer to have a one second transition and then it's done

* the pale blue marble textures at high resolution, processed to be usable with FG require DDS (otherwise the loading time is infinite) and have a total size of 2 GB - definitely not suitable for every system

* orbital visuals also require cloud textures (ideally casting cloud shadows) - the way we use clouds in the normal course of the sim couldn't be more different from the way a cloudsphere for orbital visual works

Also, those working on Earthview are also those working on the procedural terrain shaders supposed to render the vector terrain from close up :-)
Thorsten
 
Posts: 11906
Joined: Mon Nov 02, 2009 8:33 am

Re: Next-generation scenery generating?

Postby psadro_gm » Mon Oct 03, 2016 11:11 am

erik wrote in Mon Oct 03, 2016 8:18 am:It really would be great to get the scenery-module plugin system ready for this effort. Unfortunately I'm too unfamiliar with the scenery code to take a stab at it myself.


- It's actually very few changes in the core code. I am trying to document the API a bit more formally. It's very close to what poweroftwo did for osgearth integration.

erik wrote in Mon Oct 03, 2016 8:18 am:At a first glance it looks really promising but the videos seems to reveal that the hight map resolution is a little lower that what we have now


- It's less triangles, certainly, as there are no vector features. The actual heightmap, however, is higher resolution - for a normal 1/8 x 1/8 degree tile, the max res I'm using here is 151x151 regular grid - the native SRTM3 format. ws2.0 used a simplifier on this grid to remove unimportant points ( within an error bounds ) - generating a non regular mesh that closely resembles the shape of the regular grid.

I do notice that the regular mesh - with such simple shading - does look more 'artificial'. all the triangles are the same size and orientation. I never came accross that as one of the 'cons' in regular mesh vs tin, but I think it certainly is.
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby Hooray » Wed Oct 05, 2016 7:49 pm

psadro_gm wrote in Mon Oct 03, 2016 11:11 am:
erik wrote in Mon Oct 03, 2016 8:18 am:It really would be great to get the scenery-module plugin system ready for this effort. Unfortunately I'm too unfamiliar with the scenery code to take a stab at it myself.
It's actually very few changes in the core code. I am trying to document the API a bit more formally. It's very close to what poweroftwo did for osgearth integration.


To be fair, we should NOT (again) allow the perfect to be the enemy of the good, which is kinda what happened to poweroftwo's osgEarth work unfortunately - as far as I am aware, things like the "multiple renderers", or even "scenery-plugins" are even more pie-in-the-sky than anything involving HLA support in FG, which has been killing off a plethora of good ideas, and efforts, for almost a decade now.

According to the devel list archives, everybody seems to agree that a more modular scenery/terrain and rendering architecture would be good to have, but nobody seems to be willing to actually help come up with a concrete plan to make that happen, let alone help review related patches or actively get people involved who have demonstrated an ability to make the corresponding modifications (poweroftwo/osgEarth) by providing the corresponding commit access and encouraging them to work on a corresponding topic branch (analogous to Rembrandt and Tim's original effect work).

http://wiki.flightgear.org/Supporting_m ... _renderers
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: 12092
Joined: Tue Mar 25, 2008 8:40 am

Re: Next-generation scenery generating?

Postby vitos » Thu Oct 06, 2016 12:58 pm

Common things are changing not when it's possible, but when there is not another option presented.

Same way people keep talking about thermonuclear power plants or Mars manned flight for half of century.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Next-generation scenery generating?

Postby psadro_gm » Sun Oct 09, 2016 6:20 pm

I've added a wiki page to track the development, and I've checked in the latest code to the simgear anf flightgear repos on topics/new-scenery.

Included on the page is a link to the dem around Hawaii, and instructions how to get it up and running:

http://wiki.flightgear.org/Experimental_terrain_engine
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby wlbragg » Mon Oct 10, 2016 5:31 pm

I don't have a Windows build system in place currently, If anyone builds this demo for Windows platform, please contact me PM, I would be interested in obtaining a binary.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5958
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Next-generation scenery generating?

Postby vitos » Mon Oct 24, 2016 9:44 pm

I compiled and started code, but it demands latest fgdata, which can be obtained, seems to, with 1.5Gb dmg only, download of which fails here. Would try again tomorrow.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Next-generation scenery generating?

Postby psadro_gm » Tue Oct 25, 2016 11:24 am

I'm close to having correct normals on tile boundaries and skirts. This will require a new DEM format ( the dropbox tarball ) When the DEM is created, I overlap 8 pixels for each tile. The Generated DEM no longer just samples points, but uses the resolution of the bitmap to generate the triangles. I was seeing floating point roundoff cause neighboring pixels get the same value.

There are now just 3 DEM levels, and 9 LOD levels.

1x1 degree DEM ( w/8 pixel overlap ) - tiles are 1217x1217 pixels (1201 + 8 pixel overlap on edges )

lod lvl 9 = native resolution - 1/8 x 1/8 degree = 151x151 grid ( +1 pixel overlap used for normals on edge )
lod lvl 8 = 1/2 res (1/4 x 1/4 degree = 151x151 grid ( +2 pixels needed for normals on edge )
lod lvl 7 = 1/4 res (1/2 x 1/2 degree = 151x151 grid ( +4 pixel overlap )
lod lvl 6 = 1/8 res (1x1 degree ) = 151x151 grid ( +8 pixel overlap )

12x12 degree DEM (w/6 pixel overlap ) tiles are 913x913

lod lvl 5 = native resolution = 2x2 degree = 151x151 (+1 pixel overlap)
lod lvl 4 = 1/2 resolution (4x4 degree = 151x151 (+2 pixel overlap)
lod lvl 3 = 1/6 resolution (12x12 = 151x151 (+6 pixel overlap)

60x60 degree DEM
lod lvl 2 = native reolution (60x60 degree = 151x151 (+1 pixel overlap)
lod lvl 1 = 1/2 resolution (60x60 degree = 75x75 (+2 pixel overlap )

The transitions appear smoother, but I feel there may be too many triangles. I will have a tunable to reduce the resolution of far tiles.
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 3 guests