Talk:TerraGear texmapped line data

This looks great and is something I intended to do earlier, but never really got into it.

I wonder how you managed to make the clipper honour the texture coordinates, as that was the step where I let the project be? Whenever the roads are crossing, you should probably create a new polygon (quad maybe?) there and assign it a "crossroad" material. Of course then you'd need to have different textures for T cross or X cross etc, this is hard.

I also suggest you to use OSM data instead of the line data. As you modified to code generating the wider polygons, I guess it should be quite straightforward to generate the line graph with correct width from OSM xml files and then polygons from those. That way you could get also lane information etc.

I'd like to see how you did this, if you could upload a diff somewhere so I could check? I have some ideas of adding extra parameters and this code of yours might help in the process.

Oh, and I don't think it matters if the "already textured" polygons are added as single triangles or fans or strips. As long as the texture coordinates are preserved :)

Zan 09:02, 26 January 2011 (UTC)

Freeways in the Netherlands (and most other 'Western' countries) have interchanges, rather than intersections. So for freeways the current look is fine (except for the z-ordering issue), but for primary/secundary roads Zan's idea would be nice to have...

Gijs 04:10, 26 January 2011 (EST)

I've been working within a local git repository, and committing very small steps to keep a log of the mods I've made. I'll upload a diff somewhere soon.

I'm not calculating texture coordinates until after triangulation. In clipper, I still have a texture parameter for each polygon. whenever a polygon is intersected or differenced, the new poly just receives the same tex param. The problem I'm having right now, is polys are unioned into an accumulator. I need to keep this from happening for texmapped line data, so I'm looking at changing how the accumulator works. This isn't as big a deal for OSM data, as I've been looking at keeping OSM z_orders on separate priority levels. (Giving accurate overpasses / underpasses).

The next hurdle was passing in the trieles to the triangulate library. It currently only takes 1 parameter (the texture type). I combine this with an index into an array of texture parameters, so when the triangles come back, I can then calculate the texture parameters for each triangle based on the indexed texparam. I think I'd rather have the triangle library take the parameters separately, but I haven't looked at the code for that much.

I've been thinking about interchanges, and such. I think a lot of this should be done with a tool other than ogrdecode. we should have a specialized road decoder (for freeways, primary roads, railways, etc) That can handle OSM data, and optimize/simplify it (I saw a link on some of the research somewhere) and handle merge lanes, intersections and bridges. Lot's of new materials required.

--Psadro gm 12:14, 27 January 2011 (EST)

I guess you mean this page [1] that talks about line simplification.

-- Zan 04:18, 28 January 2011 (EST)

Instead of writing my own code to do simplification, I've been reading up on GRASS. I was amazed at how simple it was to get good results with a reduction of 50% of the OSM motorway vertices. I see that newer portions of terragear are also done using grass. Defiantly a step in the right direction.

v.in.ogr -o dsn=./data/shapefiles/osm_motorway/osm_motorway.shp output=osm_grass

v.generalize -c input=osm_grass output=osm_grass_simple method=douglas_reduction threshold=0 reduction=50

g.remove vect=osm_grass

v.out.ogr -e input=osm_grass_simple dsn=. format=ESRI_Shapefile

g.remove vect=osm_grass_simple

--Psadro gm 13:42, 30 January 2011 (EST)