Re: [Flightgear-devel] HEADS UP: Scenery regeneration
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
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
On Thu, Aug 7, 2008 at 9:55 AM, Ralf Gerlich wrote: > Sorry to correct you, but in Triangle::build() the segment lists are > built using TGTriSegments::unique_divide_and_add(), which does segment > splitting if TerraGear thinks that one of the end-nodes lies on an > already known edge. These checks seem to be less exact than the > predicates used by TriangleJRS ;-) > Hi Ralf and Fred, Both of you have helped refresh my memory. :-) Yes, there is code to split long features of polygons so they can more naturally follow the underlying terrain features. A single mile long edge across varying terrain looks extremely ugly whereas splitting this up into 200m or 400m segments allows the feature to more naturally follow the underlying terrain. However, this is on a very large scale so shouldn't cause any numerical accuracy problems. 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. 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. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - 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
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
Hi Curt! Curtis Olson wrote: > As far as I know, terragear doesn't do extra edge splitting before handing > data to TriangleJRS. Sorry to correct you, but in Triangle::build() the segment lists are built using TGTriSegments::unique_divide_and_add(), which does segment splitting if TerraGear thinks that one of the end-nodes lies on an already known edge. These checks seem to be less exact than the predicates used by TriangleJRS ;-) 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
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
- "Curtis Olson" a écrit : > On Thu, Aug 7, 2008 at 7:08 AM, Ralf Gerlich wrote: > > > I have just checked once more and found that triangles for the extremely > > small triangle parts simply do not exist. They are not generated by > > TriangleJRS. > > > Hi Ralf, > > As far as I know, terragear doesn't do extra edge splitting before > handing > data to TriangleJRS. However at some point in the pipeline there is > a routine that attempts to identify "slivers" and merge them with > neighboring areas. The heuristics for identifying a sliver are pretty loose > and > weren't designed with high detail, high polygon count scenery in mind. You > may want to greatly constrain the area/angle checks, or remove the sliver > check entirely. This goes back a long time, but I think the sliver checking > was originally an attempt to work around numerical problems when letting > TriangleJRS subdivide triangles to get an "ideal" Delauney > triangulation. > We've since given up on that because it generates way too many > unneeded triangles so the sliver check could probably go away without hurting > anything. Hi Curt, Hi Ralf, maybe I don't recall correctly, but I thing long edges are split to avoid having, for example, long road segments cutting mountains or making banks when crossing valleys. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - 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
Re: [Flightgear-devel] CVS Pre OSG PLIB
* gerard robin -- Thursday 07 August 2008: > Is There any update of the Pre OSG PLIB CVS branch forecast ? or is it > definitively frozen. It's not formally frozen. There were a few bugfixes committed after the 1.0 release for the case that we'd have to make an urgent bugfix release. This didn't turn out to be necessary, and everyone focuses on fg/osg now. It's very unlikely that another release will be made from the plib branch. But people can still commit there, if they feel like it. :-) > As long we don't have nice shadows and 3D Clouds, when we demonstrate > FG the 1.00 version is now, only available. :( You can still use fg/plib with the data/plib branch, now and in the future. Shadows for fg/osg are being worked on and might be finished within a few weeks. Clouds are AFAIK also work in progress, but only in an early stage, so this may still take a while. There are also still some regressions/bugs in fg/osg that will have to be addressed before the next release. Some of them being: - segfault on early exit - CullVisitor/"detected NaN" bug - material animation broken - timed animation broken - model loading broken (embedded nasal) - particle-system problems - slowness on some systems(?) m. - 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
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
On Thu, Aug 7, 2008 at 7:08 AM, Ralf Gerlich wrote: > I have just checked once more and found that triangles for the extremely > small triangle parts simply do not exist. They are not generated by > TriangleJRS. Hi Ralf, As far as I know, terragear doesn't do extra edge splitting before handing data to TriangleJRS. However at some point in the pipeline there is a routine that attempts to identify "slivers" and merge them with neighboring areas. The heuristics for identifying a sliver are pretty loose and weren't designed with high detail, high polygon count scenery in mind. You may want to greatly constrain the area/angle checks, or remove the sliver check entirely. This goes back a long time, but I think the sliver checking was originally an attempt to work around numerical problems when letting TriangleJRS subdivide triangles to get an "ideal" Delauney triangulation. We've since given up on that because it generates way too many unneeded triangles so the sliver check could probably go away without hurting anything. I don't know if this will help your specific situation, but I don't think it will hurt. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - 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
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
Hi! Ralf Gerlich wrote: > While it seems to me that the workaround should work, due to previous > experience with TerraGear and its subtleties I would not want to bet on it. ...and I see that I was right not to bet: The workaround doesn't work. TerraGear failed on the first try building the EDDF-area. > The actual problem lies within TriangleJRS, the triangulation code of > TerraGear, which - as several checks have shown - is not as robust as > advertised regarding computational geometry predicates. The > "point-in-triangle"-detection-code does seem to have problems if the > respective point is pretty near to the contour of the triangle. While > the point is perfectly inside the triangle, TriangleJRS cannot detect that. Nope, that's not it... I have just checked once more and found that triangles for the extremely small triangle parts simply do not exist. They are not generated by TriangleJRS. This could have one of two reasons: 1) TerraGear does some specific edge-splitting when preparing the list of nodes and constrained edges for TriangleJRS. This is sensible, but may move the nodes of the slivers in a co-linear fashion, i.e. the sliver parts completely vanish. 2) TriangleJRS removes the triangles for these parts as it thinks they are too small. After some checking it seems that 1) is the case. I'm at it and I hope to still be able to do a rebuild as announced with a new solution. However, don't count on it. The call for submissions to the static scenery objects database is left as is ;-) 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
[Flightgear-devel] CVS Pre OSG PLIB
Hello, I know my question could be funny. Is There any update of the Pre OSG PLIB CVS branch forecast ? or is it definitively frozen. As long we don't have nice shadows and 3D Clouds, when we demonstrate FG the 1.00 version is now, only available. :( -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " - 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
