Hi! I have uploaded a picture showing the situation in the example of VHHH to http://www.custom-scenery.org/fileadmin/people/rgerlich/vhhh.png
This is an export from QGIS, using shapefiles I generate from test printouts of TerraGear. I forgot to color this properly, but actually the textures and colors don't matter. What we have is a blue polygon, which should be of material type IrrCropPastureCover. This lies inside an Ocean polygon, which extends on the east side of the blue polygon in pink. The blue IrrCropPastureCover is also adjacent to a light-blue GrassCover polygon. What you see at the bottom are two circles, representing the "point in polygon" for these polygons. They have the material type attached to them. In the small cutout on the right side you see that the blue polygon continues in a very slim sliver to the south, the width of which is about 4 to 8 times SG_EPSILON and which becomes more slim towards the south. The calc_point_inside() algorithm I implemented places the "inside point" perfectly within this sliver, which I have checked by appropriately scaling the part in QGIS. Unfortunately in preparation to the triangulation step, the vertices of the right border of the sliver are merged onto the left border of the sliver, so that the sliver essentially vanishes. Curtis Olson wrote: > As Ralf points out, there is code that attempts to find stray nodes that lie > on existing edges and split the edge at that point. When this situation > exists, it can lead to degenerate behavior. As I understand it, the > terragear check should be more ambitious than the TriangleJRS check in order > to prevent problems down stream. Not necessarily _more_ ambitious, but at least as exact. As far as I have understood, Jonathan Shewchuk uses what he calls "Adaptive Precision Floating-Point Arithmetic" for the geometric predicates, so this is quite different from the "epsilon"-approach. > You can tune the thresholds for detection of this situation, but the looser > you make the constraints, the more you are likely to alter the original > geometry which will create artifacts in the final result. I have tried, but for some reason TriangleJRS then has problems with colinear edges, which is - as far as I understand - exactly the thing which should be avoided by splitting. And it is curious, as it seems to contradict the "adaptive precision" idea expressed above... In general, what TerraGear is doing currently - eliminiating the slivers - actually is the right thing performance-wise, as we really do not want these slivers to take up valuable triangles in the scenery files. What we might have to change is the point were the "point inside polygon" is calculate to after the creation of the edge and vertex lists for triangulation. It should be possible to keep the information about the edges belonging to a polygon resp. contour, so that the point-inside-calculation could use these instead of the original polygons. Cheers, Ralf ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
