Hi Maxime,
Final material assignment is done when the data is triangulated. (All the
points connected into triangles.) The algorithm needs a set of points, and
it also needs a set of edges (boundaries) that show the division between
material shapes. Finally for each material type, it needs a point inside
each unique area.
The algorithm starts at each given point and finds the triangle that
encloses it assigns it the material type of that point. Then works it's
way to all the neighbor triangles and assigns them the same type. It keeps
going until it hits an edge (which we provide) or it runs out of triangles.
Then it continues on to the next point and the next and the next.
So this all sounds good (I think) except we now have to compute a point
inside each material region. Easy, right? Well, except that all the
published algorithms can tell you if a random point is inside a polygon or
not, but they don't tell you how to manufacture a point that is guaranteed
to be inside a polygon. With very complex convex shapes, possibility of
holes, and all kinds of extremely tiny numbers (or points that are
extremely close to each other) this becomes a bit more of a challenge.
We have an approach with some heuristics to try to find a good point inside
a polygon, but it sounds like this is failing. Also I haven't had my
fingers in the code for quite some time and there have been some
substantial changes.
So what you want to do is identify the mistaken areas and determine the
point we generate inside those areas. Then try to figure out what's wrong
with the picture? Is the point in the area? Is it too close to an edge?
Did we miss an edge such that the classification algorithm loses contain
and spills out into a neighboring region.
The answer here is to get down and dirty and look at the intermediate
results ... it's painstaking, drudgery work, but someone needs to dig in to
each specific case and figure out exactly why it's breaking, and then
either fix the problem directly, or back up to an earlier stage in the
pipeline and try to catch/avoid/fix the situation before it causes trouble.
There are direct bugs, and then there are difficult situations with the
data that arise.
Best regards,
Curt.
On Sat, Nov 12, 2011 at 7: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
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
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
