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 frtps » Fri Oct 18, 2019 3:07 pm

statto wrote in Fri Oct 18, 2019 12:45 pm:Looks like the NVIS data is available here... Is this compatible with the GPL license? https://creativecommons.org/licenses/by/3.0/au/deed.en


Surely CC-BY is compatible?

NZ's land cover raster is CC3.0 as well, I can get that vectorised very easily (apart from the fact I'm low on disk space.)


Any favourite ways for turning raster data into smooth-looking blobs?

Also, I've generated vectors for the entirety of the United States based on NLCS data, but the data's locked away somewhere. The NVIS data is also highly accurate and could make for some very nice/specific scenery if done properly, but with our current texture mappings I assume you'd have to do a lot of recategorisation. I'll try to take some photos of at least eucalyptus on the next overcast day here.


For the recategorisation I've simply used an SQL phrase for the major vegetation group (MVG) which you can see from line 79 onwards here.

Suitable tree photos are in such short supply. I took a couple last weekend, it turns out cities are not so bad for finding isolated trees. I'm thinking some shrubs wouldn't hurt either.
frtps
 
Posts: 145
Joined: Sun Aug 05, 2018 10:58 am

Re: Next-generation scenery generating?

Postby wkitty42 » Fri Oct 18, 2019 3:24 pm

frtps wrote in Fri Oct 18, 2019 3:07 pm:
statto wrote in Fri Oct 18, 2019 12:45 pm:Looks like the NVIS data is available here... Is this compatible with the GPL license? https://creativecommons.org/licenses/by/3.0/au/deed.en


Surely CC-BY is compatible?

CC-BY-what? you might want to take a read here -> https://www.gnu.org/licenses/license-list.en.html

then there's also a big discussion on these forums about the various licenses... you might try to hunt it down and take a read of it...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Next-generation scenery generating?

Postby legoboyvdlp » Fri Oct 18, 2019 5:40 pm

CC-BY-3.0, the license mentioned above, is not compatible with GPL. It may be worth asking them for either a release under the 4.0 version or else permission to release derived data (i.e. generated scenery) under the GPL.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Next-generation scenery generating?

Postby frtps » Fri Oct 18, 2019 10:29 pm

Thanks for the heads-up.
frtps
 
Posts: 145
Joined: Sun Aug 05, 2018 10:58 am

Re: Next-generation scenery generating?

Postby bugman » Fri Oct 18, 2019 11:02 pm

bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Next-generation scenery generating?

Postby frtps » Sat Oct 19, 2019 12:49 am

legoboyvdlp wrote in Fri Oct 18, 2019 5:40 pm:CC-BY-3.0, the license mentioned above, is not compatible with GPL. It may be worth asking them for either a release under the 4.0 version or else permission to release derived data (i.e. generated scenery) under the GPL.


Right, I've resolved the NVIS situation. While the HTML page for the version 5.1 NVIS metadata (accessible starting from here) states only "CC BY", the XML metadata linked at the bottom of that page explicitly states CC BY version 4.0. I can't link to it directly as it seems that a unique URL is generated that expires after a while.

So NVIS (Australia) is in the clear.
frtps
 
Posts: 145
Joined: Sun Aug 05, 2018 10:58 am

Re: Next-generation scenery generating?

Postby statto » Sat Oct 19, 2019 9:09 am

Looks like the New Zealand land cover database is already vectorised. It's just almost a 1GB file for the entire country, and it's not split into different shapefiles for processing. But if anyone wants a project, that would be a very good/easy one to work on.
Custom Scenery available from http://www.stattosoftware.com/flightgear
statto
 
Posts: 2106
Joined: Fri Jan 25, 2008 10:57 pm

Re: Next-generation scenery generating?

Postby frtps » Sat Oct 19, 2019 10:11 am

legoboyvdlp wrote in Fri Oct 18, 2019 5:40 pm:CC-BY-3.0, the license mentioned above, is not compatible with GPL. It may be worth asking them for either a release under the 4.0 version or else permission to release derived data (i.e. generated scenery) under the GPL.


What is the basis for this statement? Is it the simple absence of a statement to the contrary on the FSF website, or has there been an abstruse legal discussion somewhere here in the last 20 years? I tried to search for "CC BY" on the forum but both those words are too short to allow searches. The wiki is also silent in the section on Creative Commons licenses. If there are some other keywords from that discussion that anybody can remember I can use to narrow down the search, that would be great.

I note that the FSF is happy to list many licenses that are not compatible with the GPL, and CC BY 3.0 is not among them.

Ultimately it is up to the core developers as to what they are prepared to merge, so if they will refuse CC BY 3.0 material, that would be good to know.
frtps
 
Posts: 145
Joined: Sun Aug 05, 2018 10:58 am

Re: Next-generation scenery generating?

Postby Thorsten » Sat Oct 19, 2019 10:20 am

What is the basis for this statement? Is it the simple absence of a statement to the contrary on the FSF website, or has there been an abstruse legal discussion somewhere here in the last 20 years?


That's the position of (among other actors) the FSF - GPL 3 and CC-BY 4.0 are compatible, but earlier versions generally not - for an explanation of why CC-BY-3.0 content is not GPL compatible see e.g. here

https://opensource.stackexchange.com/qu ... th-the-gpl
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Next-generation scenery generating?

Postby frtps » Sat Oct 19, 2019 12:21 pm

Great, thanks Thorsten. I did actually switch on my brain after that post and used Duckduckgo and site:forum.flightgear.org to find the relevant threads from 2015 with the links. So yes CC-BY-3.0 is not compatible. I think I (or someone) should update the wiki under the "Creative Commons" entry to state:

CC-BY-3.0: not compatible with FlightGear
CC-BY-4.0: compatible
CC-BY-SA: not compatible (GPLv3 only)
CC0: compatible
All others not compatible.
frtps
 
Posts: 145
Joined: Sun Aug 05, 2018 10:58 am

Re: Next-generation scenery generating?

Postby psadro_gm » Wed Oct 23, 2019 8:55 pm

I've been away for a while. I see some great ideas for the next scenery. ie using world builder.

I was playing with OSG Earth integration as well. I had some issues with ordering of initialization - i.e. jsbsim initializing the fdm before the highest LOD was loaded, so our initial altitude was incorrect, etc.
I think world builder gives you pretty much all of the important things OSGearth would provide (LOD being the most important), while being a much smaller integration effort.

I'm going to take a stab at taking the OSM road network and generating tiled images that could be baked into the terrain. I know mapnik uses AGG for this task, and I've started looking into that.
Unfortunately, I haven't found any image sw ( including gimp ) that saves ppm files in the format AGG expects them. I can only use the two PPM files in the art tarball provided with AGG.

On linux, AGG only supports PPM. I may look if mapnik has integrated other image formats and how far they've diverged from the AGG source.
It's possible that canvas has similar capabilities as agg, but I'm sticking with agg for learning/prototyping, since it's so small and easy.

I'm also developing on an 8 year old computer and graphics card now, so I prob don't need to worry about being to high end focused anymore :)
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 vnts » Fri Oct 25, 2019 3:32 pm

Parnikkapore wrote in Fri Oct 04, 2019 10:31 am:...so would OSGEarth / photoscenery be integrated in the WS 4.0 spec being discussed on the mailing list


Thanks for mentioning :D Link: https://sourceforge.net/p/flightgear/ma ... sg36774115

James wrote:
> On 1 Oct 2019, at 19:04, Thorsten Renk <thorsten@...> wrote:
>
> It comes with a bunch of unsolved problems though, chief among them... roads. They're currently a landclass, but a shader solution might not have sufficient resolution in a raster image to resolve them to the required accuracy.
>
> Also, any shader-based landclass drawing must be able to keep geodinfo() and company functioning - otherwise lots of things break...


James: My preferred approach for linear features (roads, rail, canals) is to rasterise them into the landcover at runtime - i.e make a copy of the landclass texture, and draw (in top-down orthographic projection) the road on top. This solves some issues with junctions and ordering, and even enables creating borders / verges.

It means for the land cover texture tiles near the viewer, there’s effectively higher-resolution data, than what VPB produced - high enough that geodinfo and friends can work by querying the land-cover texels.

(There’s actually a whole bunch of dynamic techniques that can be done by modifying the landcover raster in this way, from vector GIS data, if we have such a pipeline)

But, what I don’t know is how suitable or otherwise, the output format from VPB is to working this way. Most similar systems have a hook point, when a given resolution of texture is requested, where we could intercept it, and do whatever modifications we desire. (Normally tied into the paging system)

If I understood the thread & mailinglist correctly (I recall reading & posting in this thread a long while ago)..

AIUI: Mesh model (vector format) is stored without landclass info. To maintain compatibility with older systems the WS4.0 renderer will only have OpenGL 2.x&extensions available (?). Therefore no (fancy) fast editing of terrain mesh in GPU - e.g. to smooth out roads&rivers or create 3d detail. Landclass info is stored in a 2d texture (raster format) so the fragment shader is free to select textures and procedural effects based on landclass - and do smooth transitions.

psadro_gm wrote in Wed Oct 23, 2019 8:55 pm:I'm going to take a stab at taking the OSM road network and generating tiled images that could be baked into the terrain.


From what I (may not have completely) understood above :mrgreen: ..

Roads will be stored as vector data in terrasync. Wondering: Is the cost-benefit in favour of not just instancing roads? AIUI any 3d shape of roads or 3d roadside objects like streetlamps&hedges&road-barriers will likely (?) need an instanced scheme anyway. Similarly for train tracks.

AIUI Roads on terrain with bumps&spikes or on steeply sloping hillsides would need the terrain mesh to be cut out & replaced with somethign suitable at runtime by processing road vector data(?). Sloping hillsides: roads from (?) texture applied to mesh[2] . 3d OSM2City roads use a elevated road with a skirt to try to avoid bumpiness [3] [4].

Rivers, banks & verges may have to be cut into the mesh to be smooth anyway (?)..

A space saving vector data format to store roads may just be a list of points down the middle of the road+data about road properties like number of lanes, street-lighting, width. If CPU time & frame-spacing was a consideration, for instancing of roads or objects, there might be a point for each convenient model of a road segment to reduce CPU processing (?). It would work like the runtime 2d texture generation from tiled images of roads on the CPU, but it would tile an entire 3d model on the GPU along with the road verge and any roadside objects. Similar to how shader houses are done.

Conceptually, for a scheme that generates textures at runtime, it may save CPU time if the road texture contained tiled texture coordinates across 2 channels. Any road properties would be in 16 bits of the 2 other channels. That would let the fragment shader draw a road similar to how the road shader works (but no moving cars because the length coord repeats).

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

Re: Next-generation scenery generating?

Postby Hooray » Thu Oct 31, 2019 11:38 am

Thorsten wrote in Sat Oct 05, 2019 6:29 am:James (who has in actual reality been responsible for the OSG Earth patch review) isn't around


Actually, Stuart was the one originally involved in the original osgEarth review, with James awaiting Stuart's feedback, because of his involvement in that portion of the simgear code (scenery)

Both, Stuart and James and others suggested that the osgEarth patches be committed, with the condition of everything being a compile-time switch at the time:

https://sourceforge.net/p/flightgear/ma ... /31901928/
James wrote:I feel pretty strongly it needs to be a compile-time switch - partly I’m not really looking to deal with osgEarth deployment on Mac or Windows in the near future, and partly we have uses who do not want, or may not be able, to build osgEarth.


With Stuart's stating in January 2014 (aka, almost 6 years ago):

https://sourceforge.net/p/flightgear/ma ... /31885513/
Stuart wrote:I've now done a further review of an updated merge
request, and I'm happy that it should be merged.

Now that the V3.0 code-freeze has passed, are there any objections to me
merging the code?

-Stuart


psadro_gm wrote in Wed Oct 23, 2019 8:55 pm:On linux, AGG only supports PPM. I may look if mapnik has integrated other image formats and how far they've diverged from the AGG source.
It's possible that canvas has similar capabilities as agg, but I'm sticking with agg for learning/prototyping, since it's so small and easy.


Just briefly, regarding your comments on Canvas vs PPM:
The Canvas system is really "just" a wrapper around existing OSG formats - i.e. it works such that there is a property-enabled layer on top of stuff like osg::Image, which maps property updates (SGPropertyChangeListener) to the corresponding OSG APIs of the object at hand.
Which is to say, it would be relatively easy to adapt/extend the Canvas system to support additional formats, including other raster images, but also GIS related data formats like ESRI shapefiles/GeoTiff etc.
James and Stuart both hinted at that repeatedly over the years, because such changes would not just be useful for anything involving our scenery, but also for any mapping/charting functionality (think moving map displays).

You can open $SG_SRC/Canvas, which is where you can find something called CanvasImage.?xx - which is the wrapper mapping an osg::Image to a simgear::canvas::Element.

There are also examples of non-OSG code adapted to work like this, e.g. ShivaVG serving as the renderer for anything involving OpenVG (Canvas.Path elements).

We also have experimental patches illustrating how to take arbitrary fgdata imagery and use that as photo-overlays:
http://wiki.flightgear.org/Photo_scenery

In conjunction with how the Canvas system supports placing textures via so called "placements", it would be possible to adapt those patches and come up with a new dedicated "terrain-placement" that could use any Canvas texture and drape it over the terrain as needed - given how the Canvas system has helped boost avionics development by moving away from the core development bottleneck, and seeing how Tim's original work on the effects system has enabled fgdata developers to do fancy stuff like ALS, I am pretty sure that if a single C++ developer were to integrate these 2-3 features and patches to make this functionality available via the Canvas system, we would end up with a very useful toolbox/playground that could enable non-developers to tinker with alternate scenery/terrain rendering approaches without having to be experienced SG/FG coders, especially if this is coordinated with the ongoing Compositor work - at that point, we'd have all the tools at our disposal to do really cool stuff without having to patch/rebuild SG/FG, which would mean that people familiar with Canvas, Effects, Shaders and Nasal could implement tons of cool functionality without having to go through C++ space.


http://wiki.flightgear.org/Canvas_Devel ... y_Overlays
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

Previous

Return to Scenery

Who is online

Users browsing this forum: No registered users and 2 guests