Board index FlightGear Development Scenery

A reworked fgfs-construct

Questions and discussion about enhancing and populating the FlightGear world.

A reworked fgfs-construct

Postby psadro_gm » Thu Dec 01, 2011 4:21 am

As mentioned in the 850 apt.dat parser thread, we're not quite ready to begin merging the new parser into the main terragear repository until it's obvious we don't regress too much.
The two big issues are the replacement of the GPC library for clipping, and the problems with triangulation when using more detailed data.

I believe both issues are now resolved, after reworking fgfs-construct to work in the same manner as genapt. genapt basically generated polygons on the fly, and then clipped them against each other. The texture coordinates for each polygon is kept along with the polygon data. When clipping is completed, t-junctions are removed by adding colinear points from the entire dataset to the current polygon's edges. Then triangulation is performed per polygon.

The old fgfs-construct triangulated an entire tile in two passes. The area type for each polygon was added as an attribute type of the polygon, and with complicated datasets, it looks like this didn't always work out. The other issue, was when trying to keep texture parameters (for linear data), many more attributes were needed to be added.

The fgfs-construct I've come up with looks like it will work much better with clipper, and very complex data. For my test run, I used osm_freeway data directly from the mapserver. In the past, I needed to simplify the data in GRASS to get decent results. With unmodified data, I see no missing textures on the line data. There is also no indication of missing 'grey' polygons.

It's by no means complete, as it is currently 1 huge c file, and less understandable than the original fgfs-construct.

The things that don't work:

1) no custom objects (airports are big grey areas with a pretty green border)
2) elevation smoothing (all elevation points are raw ram height data from .fit file, and interpolated for polygon points)
3) texture coordinates are hard coded. This should be easy to fix for land-class data. I want to generate tcs that follow vector data from roads, streams, and railways
4) face normals currently, there is only 1 normal per tile. Will bring in the old function to do per face normals.
5) No -class raster landclass support. It only supports landclass via polygon import. Does anyone use raster images for landclassing now? If so, I think it should be a different construct app.
6) fitting neighbor tiles. old fgfs construct could write and read adjacent tile data. if ogr-decode does it's job, is this necessary?

Here's a screenshot of some osm data that looks good after the t-junction issues I was having have been solved:

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: A reworked fgfs-construct

Postby psadro_gm » Thu Dec 01, 2011 5:05 pm

Crossing items 1 and 3 off the list. Airports, and other custom objects from the index file are working, as are the texture coordinates for landclass areas.
Item 6 is a concern. I'm still seeing seams, and sometimes tears on tile boundaries. I'll need to look into what's happening with the height data at tile boundaries, as the polygon splitting looks good.

Here's the latest screenshot:

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: A reworked fgfs-construct

Postby f-ojac » Thu Dec 01, 2011 6:33 pm

Very nice, congratulations! Very happy to see such hard work on fgfs-construct, which definitely needed it.
f-ojac
 
Posts: 1303
Joined: Fri Mar 07, 2008 9:50 am
Version: GIT
OS: GNU/Linux

Re: A reworked fgfs-construct

Postby psadro_gm » Sat Dec 03, 2011 1:35 am

I've redone the texture mapped vector data. Done right, this time - it works exactly the same as linear features in genapt.

Now, I'll need some new highway textures :)

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: A reworked fgfs-construct

Postby adrian » Sat Dec 03, 2011 6:49 am

Wow! Just wow!
You've done so many improvements to the terragear chain in such a short time, it's unbelievable :)
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: A reworked fgfs-construct

Postby radi » Sun Dec 04, 2011 2:05 pm

Awesome!
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 647
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: A reworked fgfs-construct

Postby psadro_gm » Mon Dec 05, 2011 2:57 am

I've grabbed as much OSM data as we have at the mapserver to run a torture test.

OSM_motorway, OSM_truck, OSM_primary, OSM_secondary and OSM_tertiary.

It takes over an hour to construct a tile with this much data, but it looks clean, with no errors.

Image

I'm going to ask if I can begin moving this into the official repo
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: A reworked fgfs-construct

Postby Gijs » Mon Dec 05, 2011 6:53 am

Wow, that's the news of the day!! Great work!
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9387
Joined: Tue Jul 03, 2007 2:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: A reworked fgfs-construct

Postby Sealbhach » Mon Dec 05, 2011 7:30 am

Does this mean we now can have proper lines and markings on the roads?

.
Sealbhach
 
Posts: 934
Joined: Wed Jun 30, 2010 9:17 am

Re: A reworked fgfs-construct

Postby ot-666 » Mon Dec 05, 2011 7:45 am

Fantastic work.
Always hoped for denser roads, since they make the impression so much more real.
Callsign: ot-666
Working on LOWI and other stuff - Custom Scenery Overlay Repo: http://gitorious.org/fgfs-custom-scenery/custom-scenery-overlay/
VMX22 - Osprey... sometimes in 2014
ot-666
 
Posts: 746
Joined: Sun Nov 08, 2009 5:14 pm
Location: Germany, Konstanz
Callsign: ot-666
IRC name: ot666
Version: GIT
OS: win7 64bit

Re: A reworked fgfs-construct

Postby scighera » Mon Dec 05, 2011 10:26 am

The only word I understood is "texture" ... but, looking at the screenshot, the work you are making looks great :shock:

Hope the same may apply to railroad, so that I may switch back to my hold passion: model railroading !!!

keep on !!! BRAVO
Callsign: I-SCIG
The hangar: http://digilander.libero.it/scighera_fg/index.html
The "happy motorbiker" - http://web.tiscali.it/kclub
User avatar
scighera
 
Posts: 328
Joined: Thu Nov 19, 2009 8:29 am
Location: LIME-Bergamo-Italy
Callsign: scighera
Version: 2dot6
OS: Windows 7

Re: A reworked fgfs-construct

Postby Tuxklok » Mon Dec 05, 2011 3:38 pm

I wonder, have you given any thought to overlaying the road/rail data with polygon offsets and/or other rendering techniques to remove z-fighting...as your doing with linear data at the airports? It seems to me there could be some real benefits and opportunities to overlaying rather than cutting them in, but I'm curious your thoughts on this as you are much more in tune with the guts of the whole system than I ever hope to be.

cheers
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1320
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

Re: A reworked fgfs-construct

Postby psadro_gm » Mon Dec 05, 2011 4:30 pm

Sealbhach wrote in Mon Dec 05, 2011 7:30 am:Does this mean we now can have proper lines and markings on the roads?.


Yes it does :)

scighera wrote in Mon Dec 05, 2011 10:26 am:Hope the same may apply to railroad, so that I may switch back to my hold passion: model railroading !!!


Yes, for now, roads, railroads and streams. Any shape file that has line data.

In the future, I can see other possibilities as well. For instance when landmass meets coastline, polygons could be added between the water and land to create coastlines. Texture coordinates for these polys could start in water, and move into the land, alowing textures, shaders to model this properly.

Tuxklok wrote in Mon Dec 05, 2011 3:38 pm:I wonder, have you given any thought to overlaying the road/rail data with polygon offsets and/or other rendering techniques to remove z-fighting...as your doing with linear data at the airports? It seems to me there could be some real benefits and opportunities to overlaying rather than cutting them in, but I'm curious your thoughts on this as you are much more in tune with the guts of the whole system than I ever hope to be.


It's been on my mind. The difference is that the linear features at airports are in some instances exactly coplanar (the stripes at the edges of taxiways), and the others (center lines, and hold short lines, etc) , because of the airport smoothing algorithms, are still nearly coplanar.

The linear data for roads create all kinds of ridges and valleys as they traverse the terrain. The polygon offset would have to be huge, and would look artificial. I am thinking of ideas for smoothing the terrain for highways, right now, however. I'm thinking there would be another step after ogr-decode, and before construct, where highway decoding would generate even bigger polys that would be used for smoothing the underlying height data. I know this can be done in grass, and it would need to be done for large areas (not per tile). perhaps when this is done, highways could be overlaid on top since the height data would be smoothed out.

Currently fgfs-construct performs smoothing like this on its own, but can cause issues as tile boundaries. Lakes fopr instance would be perfectly flat, streams would have their own smoothing, and secondary roads, would not smooth as much as highways, etc.

Pete
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: A reworked fgfs-construct

Postby ot-666 » Mon Dec 05, 2011 4:33 pm

Tuxklok wrote in Mon Dec 05, 2011 3:38 pm:I wonder, have you given any thought to overlaying the road/rail data with polygon offsets and/or other rendering techniques to remove z-fighting...as your doing with linear data at the airports? It seems to me there could be some real benefits and opportunities to overlaying rather than cutting them in,...


Maybe if they are overlayed, they could be even leveled to the higher side (left to right side of the road) and maybe extruded downward to make roads look plauseble in mountain areas?
Callsign: ot-666
Working on LOWI and other stuff - Custom Scenery Overlay Repo: http://gitorious.org/fgfs-custom-scenery/custom-scenery-overlay/
VMX22 - Osprey... sometimes in 2014
ot-666
 
Posts: 746
Joined: Sun Nov 08, 2009 5:14 pm
Location: Germany, Konstanz
Callsign: ot-666
IRC name: ot666
Version: GIT
OS: win7 64bit

Re: A reworked fgfs-construct

Postby Tuxklok » Mon Dec 05, 2011 6:18 pm

psadro_gm wrote in Mon Dec 05, 2011 4:30 pm:The linear data for roads create all kinds of ridges and valleys as they traverse the terrain. The polygon offset would have to be huge, and would look artificial.

Would that not be a matter of "simply" generating the polygons for the linear data such that they fit the underlying terrain closely? For example generating the terrain first, then generating the linear data while projecting its vertices down to the underlying terrain...tessellating the linear data as needed. That should leave you with pretty much what we have now, roads/rails/rivers that follow terrain, even if at odd angles and such, except not having to tessellate the underlying terrain a bunch. Instead that extra tessellation could possibly be used for smoothing and leveling the terrain under rails/roadways or other types of things.

ot-666 wrote:Maybe if they are overlayed, they could be even leveled to the higher side (left to right side of the road) and maybe extruded downward to make roads look plauseble in mountain areas?

That could be possibly certainly. I was also thinking, if overlaid, that linear data could then allow a z coordinate and thus make it possible to have road/rail networks that don't all lie flat on top of each other like cooked noodles dropped on the ground. Instead you could have elevated on and off ramps, over and under passes, etc...ie realistic roads with height and depth. Later if things like extrusion and other things were added you should be able to generate some pretty plausible looking road/rail networks.


All easier said than done of course...

cheers
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1320
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

Next

Return to Scenery

Who is online

Users browsing this forum: No registered users and 2 guests