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 Richard » Wed Jun 01, 2016 1:52 pm

erik wrote in Wed Jun 01, 2016 12:01 pm:This sounds very exciting.
If there's no drawback memory wise this would fit well with the airport layout draping I think and then maybe it is a good idea to create a test area using this method.


It occurs to me that instead of draping the airport could we just use (or specify a second) texture that has the airport info for a procedural shader?

I think it's a very great concept; it has the possibility to solve a lot of the texture related landclass issues. Only last week whilst flying over the current industrial texture I couldn't help thinking that there must be a way to do it better so that it joins up and doesn't look so repetitive.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Next-generation scenery generating?

Postby erik » Wed Jun 01, 2016 2:06 pm

Richard wrote in Wed Jun 01, 2016 1:52 pm:It occurs to me that instead of draping the airport could we just use (or specify a second) texture that has the airport info for a procedural shader?

That crossed my mind too but I expect that the resolution will never be good enough to get the sharp seems and crisp textures we have now.

Edit: It probably will work great for all the many small airports with grass or dirt runways though.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: Next-generation scenery generating?

Postby erik » Wed Jun 01, 2016 2:13 pm

It also occurred to me that this requires a different way of random object assignment. But it will probably not be extensive work.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: Next-generation scenery generating?

Postby Thorsten » Wed Jun 01, 2016 3:05 pm

As I said: This may or may not become an outlook at the structure of WS 4

It's a bit early to talk about memory consumption, framerate or random objects. There's a whole list of things which will need to change if we adopt this and a whole bunch of yet unsolved problems - which we need to study. You're not going to see any of this in FG for a while.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Next-generation scenery generating?

Postby Thorsten » Thu Jun 02, 2016 7:13 am

The idea for man-made landclasses would be to really put them 'on top' of natural surfaces, such that the original topology (and colors) are allowed to partially influence the visuals.

Image
Image
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Next-generation scenery generating?

Postby erik » Thu Jun 02, 2016 8:21 am

Thorsten wrote in Wed Jun 01, 2016 3:05 pm:As I said: This may or may not become an outlook at the structure of WS 4

I proposed it because the scenery WS V3 developers indicated they hit a snag and also indicated this would be much easier for them. I think this approach is a brilliant step forward from our current scheme (and 'photorealistic' scenery as well), And it is promising enough that I wouldn't mind loosing some features early on, to be added later. And being an Open Source project: many hands make light work, so release early and release often.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2245
Joined: Thu Nov 01, 2007 2:41 pm

Re: Next-generation scenery generating?

Postby wlbragg » Thu Jun 02, 2016 6:43 pm

After studying the residential on top of a base background on Google Earth, it is indeed almost identical to the above (in some cases) in others there is a clear and distinct difference with sharp boundaries. This would be such a nice addition to the arsenal!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Next-generation scenery generating?

Postby Hooray » Thu Jun 02, 2016 8:14 pm

admittedly, it's looking freaking awesome - if this could be combined with the urban shader approach to create a spatial/3d illusion, the whole thing could become very compelling

There's the only issue that shader-based features are unlikely to be very popular with people who don't have GLSL support ...

Anyway, the 2nd screenshot in conjunction with some kind of urban/buildings shader that makes those rooftops look 3D and maybe the traffic shader with moving lights (i.e. the one that i4dnf came up with), could be really quite convincing, especially in night time conditions. And maybe there's a simple scheme to apply some heuristics to restrict this based on altitude/POV and vicinity to airports (i.e. typical approach/takeoff conditions).

Richard wrote in Wed Jun 01, 2016 1:52 pm:I think it's a very great concept; it has the possibility to solve a lot of the texture related landclass issues.


Just for the sake of completeness, here's my usual Canvas related comment: we are already able to create a texture representation of arbitrary airport features like runways, taxiways etc - even in Nasal/Canvas space using a handful of APIs (navdb), which works using the Canvas::Map element to project lat/lon tuples of arbitrary Canvas::Path segments to the texture:

Image

This texture could be simplified/customized and fed to a shader/effect:

http://wiki.flightgear.org/Canvas_Devel ... 2F_Shaders
Image

And it could also be draped using geo-referencing, for which we have existing SimGear patches: http://wiki.flightgear.org/Photoscenery ... otoscenery

This way, if/when Canvas+Shaders/effects are better integrated, many TerraGear-level things could actually be moved to fgdata space:
Image
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: Next-generation scenery generating?

Postby Thorsten » Fri Jun 03, 2016 8:33 am

There's the only issue that shader-based features are unlikely to be very popular with people who don't have GLSL support ...


Without shaders, the plan is you'll have to use the current scenery, the scenery rendered by texture compositing would no longer be supported on legacy systems. There's no other fallback plan possible.

Anyway, the 2nd screenshot in conjunction with some kind of urban/buildings shader that makes those rooftops look 3D and maybe the traffic shader with moving lights (i.e. the one that i4dnf came up with), could be really quite convincing, especially in night time conditions. And maybe there's a simple scheme to apply some heuristics to restrict this based on altitude/POV and vicinity to airports (i.e. typical approach/takeoff conditions).


It's not that this can't be done - it just all costs extra. So let's see the performance of the basic setup first before composing a wishlist of other features and getting single digit framerates... :-)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Next-generation scenery generating?

Postby vnts » Fri Jun 03, 2016 4:42 pm

Thorsten wrote in Wed Jun 01, 2016 6:37 am:It is a texture lookup, yes. The encoding to be used is what I'm trying to research at the moment. I'm aiming for some experience with the rendering part so that I know what's needed, useful and not relevant before stating potential requirements for the scenery creation.


So the shader branches between applicable land-class types based on a texture lookup? If there's more than 2 applicable land-class types in a given area with procedural aspects, will all branches be evaluated because of SIMD GPU processing or is there a way around it?.. Transition regions sort of conceptually imply 1-2x more load..

The screens look great. Meta-information maybe(?) could be used to classify areas in textures, like with the screens posted, classifying buildings/trees/roads/floodable areas/water to stop specific types of colour influence from transitions/underlying terrain..8(=n+m) bits of a texture channel can store n flags+region id out of m^2 possibilities.. That would allow texture areas showing grass/crops to be influenced, but not others. Areas could be reinterpreted via regional definitions for different landclasses, or environment settings.

Thorsten wrote in Wed Jun 01, 2016 6:37 am:We may want to add complexity to the raster image though - specify what pattern to use for the transition for instance, store information about roughness and height-mapping,...


Additional data needed to describe a transition at different scales would seem to depend on the type of landclasses on either side of the boundary, maybe..so perhaps interpreting datafields differently would save space.
e.g. a crisp boundary between managed forest or other human influenced terrain might be best described with a description of a curve to be somehow calculated taking data on 2+ neighboring squares (on a scale >5m). Other transitions might involve islands/coverage, distance fields, boundary characteristics at different scales..

The interesting regions are the boundaries/transition areas..if the ability to compress identical areas of something like png for hdd storage is not good enough, a multi-resolution data-structure may work (assuming the idea is to avoid vector representation in downloaded terrain data too).

Regards,
vnts
vnts
 
Posts: 409
Joined: Thu Apr 02, 2015 1:29 am

Re: Next-generation scenery generating?

Postby Thorsten » Fri Jun 03, 2016 5:05 pm

So the shader branches between applicable land-class types based on a texture lookup?


It doesn't actually branch, it just chooses different texture coordinates to effectively read a different texture.

Transition regions sort of conceptually imply 1-2x more load..


There's no such thing as a conditional texture lookup in GLSL, but subsequent lookups on the same texture are cheaper than the first one - so the actual performance equation is not what one would naively think.

Meta-information maybe(?) could be used to classify areas in textures, like with the screens posted, classifying buildings/trees/roads/floodable areas/water to stop specific types of colour influence from transitions/underlying terrain..


Meta-information that determines whether underlying color influences a pixel or not is otherwise known as the alpha-channel :-)

other human influenced terrain might be best described with a description of a curve to be somehow calculated taking data on 2+ neighboring squares (on a scale >5m). Other transitions might involve islands/coverage, distance fields, boundary characteristics at different scales..


Whatever you want to calculate, you have to do it sixty times per second for two million pixels, so it better be really simple.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Next-generation scenery generating?

Postby psadro_gm » Sat Jun 04, 2016 2:43 pm

I've been thinking about this ( and what James has been writing on the mailing list ). I'm trying to determine how to best support high resolution for things like roads and airport markings.
I think James said higher resolution layers would be an overlay.

I'm still thinking we would want to drape geometry over the terrain for things like road markings, taxiway lines, etc, but if I'm wrong, that would be great :)

Do you think we can get the kind of precision to draw broken lines, runway designation characters, etc using this technique? I was thinking the landclass lookup would be 1 image per tile. These high resolution overlays would need to be a LOT smaller, and use different texture coordinates on the mesh, correct?

Pete
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 3:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby Thorsten » Sat Jun 04, 2016 2:59 pm

I admit my main concern isn't airports at this point... so take this with a grain of salt.

But: For the renderer, textures are sort of scale invariant entities - they just care that they have a texture and texture coordinates. Which means you can use the same renderer and feed it textures at whatever resolution you need as you get closer to an object, and you can pass a single pixel alpha = 0 texture when you don't need it.

So for LOD purposes, textures look much more handy than vector geometry.

I would not try to render an airport with the normal terrain shader in the first place (like with water, making it aware of transitions with the help of the meta-texture is one thing, using the same rendering code quite another). So we can use much higher resolution for airports.

Also, procedural techniques can add details like erosion, discoloration,... down at the milimeter level, so they don't have to be there.

So I don't really see the huge advantage of geometry for lines.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Next-generation scenery generating?

Postby Hooray » Sun Jun 05, 2016 10:17 am

Notice that the photoscenery patches are fairly old meanwhile, last I looked at them, I had something working that would render an arbitrary texture to a hard-coded tile using a lat/lon tuple - but meanwhile, all the PagedLOD refactorings are complicating things a bit - I guess that Stuart or poweroftwo would be in a better position to judge if/how that functionality can be generalized and integrated/exposed at the SimGear level to be useful here ...

Also, given the shifting focus of the discussion, the Canvas route may be super-flexible, but it won't align nicely with all the effects/shader and PagedLOD infrastructure that you need, i.e. the Canvas system would literally need to provide its texture in a PagedLOD-compatible form which has other implications, especially from a multi-threading standpoint, and a texture would need to be able to use shaders and effects, for both, input and output.

Thus, for prototyping and a proof-of-concept, the old patches may be suitable and should be straightforward to integrate with the Canvas system to come up with a geographic Canvas placement - but all the other fancy stuff you are talking about would sooner or later benefit from using osg::PagedLOD and osg::OverlayTexture - none of which is currrently used by the Canvas system.
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: Next-generation scenery generating?

Postby psadro_gm » Thu Jun 16, 2016 1:16 pm

CGAL team just fixed my infinite loop issue. Yay. https://github.com/CGAL/cgal/pull/1169. I should now be able to start generating .btg files again. I'll look into generating a base mesh with with rasterized landclass info this weekend.
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 3: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 7 guests

cron