TerraGear texmapped line data

Work in progress This article or section will be worked on in the upcoming hours or days. Note: This page features a currently unreleased feature. See history for the latest developments.

Current Status

As of January 20, 2012, there is a somewhat workable terragear branch allowing texmapped line data. It isn't complete, so scenery created with it isn't suitable for inclusion for terrasync, etc. (lakes are not flattened, shared edges db isn't honored, need new materials, etc)

The git repository is here: gitorious/fg/terragear-cs/newconstruct^{(missing repository)}.

This branch also includes the genapt850 airport parser.

Work is being tracked on the forum here: reworked fgfs-construct

It'll be a couple more months of adding in the rest of the features from the original fgfs-construct, and fixing some known errors in both construct, and the 850 parser. When complete, I hope to get this branch building on Jenkins, so people can begin testing it.

old status

I've been working on this a couple weeks, and am now on the third attempt. I get better ideas each time, and start over. My guess is I'll need another 2 or 3 iterations to get something working. I'm creating this page to document my thoughts and ideas. It can also be used for feedback. Because of the large amount of changes to TerraGear required, I expect this will be a long-term project.

• moved texparams from GenAirports into TGPolygon itself.
• added a new parameter to ogr-decode that triggers texparams to be generated for polygons that are generated with line data. The current line data polygon generator creates 1 large poly for the entire list of segments. If we are generating texparams, I instead create a list of polys (1 for each line segment). I've also included texparam data within the polygon itself. More on this later.
• When chopping, texparam data is copied to the newly created poly. We want the texture to be seamless across tile boundry - I haven't started this yet. When storing the polygon data, I created a new file header #2DTP and #3DTP to let construct's clipper code to read in the tex param data into the poly.
• Construct will now have an indexed array of texture parameters. This is done much like the indexed node list for triangulate. When adding the region attribute for triangulate, I changed the normal landclass type to 128*texidx + landclass type if the current poly had texture parameters. Once triangulate is done, the attribute is used to determine if we have texture parameters for the triangle.
• When constructing fans from the triangle data, I think I will first remove triangles with texture data - and add them to the bucket as triangles. This looks like how airport runways and taxiways are done. currently, tex coords are calculated via simgear, but this won't work. I'm borrowing the algorithms from the runway code in GenApts.

first checkpoint - texture mapped line data

• this is the first time I've gotten texture maps to (sort of) follow the line data. It's currently scaling to the whole polygon. But it's progress.

second checkpoint - correctly mapped image

• That wasn't too hard - unfortunately, there is a shortcut taken in ogr-decode to keep the polygon width consistent, but now you can see the road doesn't exactly follow the original line segment otientation. I have an idea how to fix this

OSM data

• I Had to try this with some detailed roads - it shows a definite need for more work. There is ongoing work to clean up / reduce complexity of highly detailed data. We'll have to see where this leads.

• Gijs pointed out that it would be nice to z-order the polygons. This would correct the error seen in the left red box. I had assumed the shape-files didn't have this information, but I was wrong (at least for OSM data). Since clipper already clips based on terrain type, I may be able to tweak this to ensure that roads that should be on top, will be. I can also fake out the old shape file data (cs_road), so that at least the errors won't appear. Each polyline will be given a unique z-order, although the ordering will probably be incorrect.

• The right red box shows an error due to the above mentioned optimization in ogr-decode. I will work on this first. I want to ensure that each polygon generated is parallel to the original data. The original data is what is used for calculating the texture coordinates. As you can see here - the texture is off a couple degrees from the actual poly.

Line Simplification

• I thought I had a serious bug while clipping, in that I was missing some large chunks of the ground.

After debugging, I found that I was most likely hitting a hardcoded maximum triangles / fans in simgear. If I limited the number of triangles output, the ground would appear, and the roads would disappear. Instead of looking for the hardcoded limit, I set my next priority to line data simplification. Using GRASS, this is a relatively straightforward process. I'm reducing the number of verticies in the osm_motorway shapefile by 50% for the rest of my testing.

Current results

• Here is the same intersection with the fixed polygon algorithm, and line simplification

As you can see, the textures flow better now (no more left side error above).

• For reference, here is a link to the real intersection I'm using for testing (Spaghetti Junction). It's one of the most complex in my area.

• December 26, 2011

I've created a newconstruct branch in the official terragear-cs repository on gitorious. newconstruct branch^{(missing repository)}. This contains the completed results of my experimentation. The hardcoded limit for the number of indices has been commited to simgear, and using the clipping / triangulation method from genapts has pretty much fixed all of the problems I had previously. All road polys are correctly textured (no more default textured triangles). I still see (very rarely) missing triangles, especially when one road merges into another with a small angle between them. My guess is that one of my cleanup routines is removing the poly. This happens very rarely, however. The original tests were erformed with just OSG motorway, and needed simplification in GRASS before the results were good enough. Now, I can bring in motorway, trunk, primary, secondary, and tertiary without problems. ( I even tried residential for laughs - it worked on some tiles, but not all. the frame rate hit of an extra 40-50 thousand road polys per tile, though, brought my computer to it's knees :) )

TODO : Roadmap

• The next error is when one polyline ends and a new one begins. Even though they share a vertex, the polygons end with 90 degree angles. I will need to make a pass through all polyline start / end vertices, and calculate the correct angles to make them seamless.

This has been very difficult. I'm getting very bad results. It looks like sometimes, the endpoint of a line can also be the endpoint of a line in the opposite direction. This leads to crazy looking triangles.

I have moved my focus from the use of ogr-decode to generate the polygons to a custom grass module. (mostly because by the time I have anything working good enough to merge, Terragear will have moved beyond ogr-decode...)

Wow - looked at v.buffer which generates polygons from line data. just using a stripped down area of the Atlanta area with OSM_Motorway data. It's been chugging away for almost a full week. I can't wait to see what it looks like :)

Note: be very careful selecting distances with v.buffer. I chose way too large. The following screenshot shows .0001 (blue) and .0005 (red). These took <1 minute to generate.

This is the result of 15 days of chugging on my first attempt - this is zoomed way out, and contains all the road data for atlanta :)

update - using the genapt methods, I clean polys, and only import 'unique nodes' based on their proximity. So, they snap together. This has greatly improved the continuity of coneected line segments.

• I want to incorporate the z_order from OSM map data, and correctly prioritze them in clipper

update - Martin has updated his scripts, so I should be getting lot's more line segment attributes.

• I want to look into changing the texture of bridges, so they look more like bridges (not too sure about adding fake shadows on the road below, because this would add a ton of small polys)

• I want to look into creating the shapefiles directly from OSM xml data (there is an experimental importer in GRASS). I would like to have the correct width / number of lanes.

• It would also be nice to support merge lanes. New textures would be needed when lines combine.

• I need to move to a more generic priority scheme: Sometimes railroads go over the road, sometimes under, sometimes at grade... SO ogr-decode will go away for line data - I need to work on all of the line data layers at once. We would also then change road graphics, so we get bridges over streams as well.