Hello Maxime,
I had also noticed more instances of the grey poly with clipper than GPC.
As an experiment, on Saturday, I spent several hours gutting fgfs-construct
down to the bones. Although the grey polys didn't disappear completely, I
got Clipper producing as good results as GPC did.
The areas I still see problems are on tile boundaries, and osm roads.
I'm at work right now, but will download your tarball tonight to if it's
useful. I have also been trying to reproduce the issue on the simplest
possible case. This could save some time.
I think the grey polys are the default material. I was going to verify
this tonight by assigning bogus materials to some well known land-class.
I think the solution to this whole issue is to bring fgfs-construct .btg
generation closer to how the genapt works - keeping the material
information around with each poly through the clipping process. This is a
necessary requirement to be able to generate good texture coordinates for
linear data as well. I think I will work on this in parallel with the
texture mapped roads / streams.
Pete
On Sun, Nov 20, 2011 at 4:31 PM, Maxime Guillaud <m...@mguillaud.net> wrote:
> Hi Peter,
>
> Any news on the topic of the "gray" polygons ? I have been experimenting
> more with this,
> and I can confirm that it occurs only when clipper is enabled.
>
> If this can help, I have isolated a simple dataset (much simpler than last
> time) that
> triggers the bug. It is just one landmass polygon with a handful of
> vertices. This data
> is here: http://www.mguillaud.net/fg/2794338/2794338.tgz
> (I also include the fitted elevation, since I don't know if this data
> interacts with the
> bug). The bug occurs with fgfs-construct built from the code in papillon's
> tg850 branch
> (i.e. with clipper), with or without my attempts at adjusting the epsilon
> constants that
> can be found here and there in the code.
>
> I run "fgfs-construct --work-dir=[..] --output-dir=[...] --tile-id=2794338
> SRTM-3
> Landmass ", and the gray area is around -9.40025/51.5005 degrees.
>
> Any insight on this issue is appreciated...
> Maxime
>
>
>
> On Sat, 12 Nov 2011 21:52:56 -0500
> Peter Sadrozinski <psadrozin...@gmail.com> wrote:
> > I have verified that the problem lies in using clipper.
> > Using the same simple data with GPC works. It appears clipper can
> > sometimes produce clockwise winded polys.
> >
> > I'm working on a fix now.
> >
> > Pete
> >
> > On Sat, Nov 12, 2011 at 7:59 PM, Peter Sadrozinski
> > <psadrozin...@gmail.com>wrote:
> >
> > > Hi Martin,
> > >
> > > I've been reluctant to move to the official repository mostly because
> of
> > > very little understanding of GIT.
> > > I'm a bit more confident, now, so I don't see it as a big problem.
> > >
> > > I think most of the work we are doing (alternate clipping library, 850
> > > format) should be considered experimental, however. I'm pretty sure we
> > > want to keep the main branch
> > > concentrated on fixing problems with detailed landclass.
> > >
> > > We seem to be breaking terragear pretty good as of late :)
> > >
> > > Maxime: I have an experiment for you to try - could you take the UFO
> under
> > > those grey sections of scenery, and look up at them? I think the
> normals
> > > have swapped.
> > > Chris mentioned this happening with the skirt around the airport, and I
> > > hadn't seen it until a recent update. Looks like something broke
> recently.
> > >
> > > Pete
> > >
> > >
> > >
> > >
> > > On Sat, Nov 12, 2011 at 2:38 PM, Martin Spott <martin.sp...@mgras.net
> >wrote:
> > >
> > >> Hi Maxime and others,
> > >>
> > >> Maxime Guillaud wrote:
> > >>
> > >> > You can find my code here [...]
> > >>
> > >> I'm just starting to recover from a couple of _really_ tight days
> > >> (including a nice PostgreSQL conference "PGConf.DE" where I gave a
> talk
> > >> about our geodata collection and in-database processing), therefore
> I'm
> > >> not yet ready to provide comprehensive responses. Anyhow there's one
> > >> point I'd like to emphasize:
> > >>
> > >> I know it's really "cool" to maintain private source repositories ;-)
> > >> .... but for increasing the overall success of building FlightGear
> > >> scenery I'd think it would be really beneficial to keep the various
> > >> development efforts in close relation and sync. Thus I'd invite
> > >> everyone who's serious about improving the TerraGear toolchain to
> > >> create a branch in the main repository in order to develop their
> > >> specific features/changes there - not only but also because this would
> > >> simplify tracking of the various changes.
> > >>
> > >> The former "terragear-cs" main repository at MapServer was already
> open
> > >> to (almost) everybody who asked and now that it's moved over to
> > >> Gitorious there's really no more excuse not to create branches inside
> > >> the main repo :-)
> > >>
> > >> Best regards,
> > >> Martin.
> > >> --
> > >> Unix _IS_ user friendly - it's just selective about who its friends
> are !
> > >>
> --------------------------------------------------------------------------
> > >>
> > >>
> > >>
> ------------------------------------------------------------------------------
> > >> 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
> > >>
> > >
> > >
>
>
> --
> sent from my armchair
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel