With this minimal data set, do you see bad node print messages during
construct?
found a bad node = xxx
When a node touches a line segment on the same contour, the bad node is
removed, as odd/even clipper algorithms blow up when this occurs.
I would experiment with removing the code that removes the node. You'll be
trading one error for another, but it may help track this down.
Take a look at reduce_contour_degeneracy() in poly_support.cxx
If this is the cause, then we'll have to figure out a different way to
handle touching segments. As Curt said, pushing nodes around may not be
any better than removing the offending node all together.
Pete
On Sat, Nov 12, 2011 at 8:59 AM, Maxime Guillaud <m...@mguillaud.net> wrote:
> James Turner <zakal...@mac.com> wrote:
> >
> > Onwards with fixing the fgfs-construct crashes!
>
> I have had pretty good luck building complex scenery with a modified
> version of
> fgfs-construct. Here is what I did:
>
> Following advice by Peter Sadrozinski here on the list, I started from the
> code
> in papillon's terragear repo where GPC is replaced by clipper. I then
> applied a few
> patches, reducing various "epsilon" constants in the code which I think
> were too loose and
> caused inconsistencies in the clipper. You can find my code here (in the
> branch
> "custom_scenery_clean"):
>
> https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/commits/custom_scenery_clean
>
> More specifically, the patches relevant to fgfs-construct are in commits
> 81a78602e09b67edd58b2cedacf09079239b0177 and
> 8601f66cf7cf00ffda38f57cee77ae991c42dab8.
> The second one uses the constant "SG_EPSILON" defined in Simgear. I
> reduced the
> value of this constant in simgear/constants.h:
> #define SG_EPSILON (DBL_EPSILON*10)
> (Note that I am using a different installation of Simgear for terragear
> and for fgfs, so
> I do not know if this change would have consequences on fgfs).
>
> With the above settings, I was able to process large amounts of scenery
> without any crash.
> So far I have tried a band covering Europe between 12 and 14 degrees East,
> i.e. going
> through Sicily, Italy, the Austrian Alps, the Czech Republic and Germany,
> Sweden and
> Norway, up to 69 degrees North. My scenery includes detailed terrain
> (fitted with 15m
> accuracy), the CORINE land cover, and OSM rail and roads up to the
> secondary network. The
> latest update in the BTG format seem to have fixed the "swirlies".
>
> You can see a few screenshots here:
> http://www.mguillaud.net/fg/scenery-gallery/
>
> The only problem that prevents me from calling it final and generating
> custom scenery for
> all of Europe can be seen in the last screenshot:
> http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png
> Sometimes, one polygon will have the correct shape but the material is
> wrong, and it
> appears all gray. This seems to occur only around roads. Any advice on
> this is
> appreciated. I had a chat with Martin Spott (hi Martin !) a few days ago
> and he mentioned
> that the bug is known, and proceeded to explain it to me, however I have
> not been able to
> relate his explanation to the code in fgfs-construct. I can provide a
> minimal set of
> files (3 roads) that trigger this problem, in case anyone can help with
> the debugging.
>
> Maxime
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
