> 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.
Ignore my previous e-mail on this issue, I misread the "each poly" part.
Adrian
-
> 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.
Hi Peter,
I thought that was already the case? I was fooling around the other day,
mo
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 are
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 polyg
Jason Cox wrote:
> With GRASS how ever there is no doco and so it would take people such as
> myself a long time to come up to speed.
Nobody will force you to use a GRASS-based Scenery toolchain,
especially not if you're happy with the current one.
Cheers,
Martin.
--
Unix _IS_ user fri
I am all for changing the generation tools but have one issue with the
use of GRASS and that is how to use it.
Currently there is some good doco's on building scenery via the current
tools and also some scripts that people have put together to automate
all or part of it.
With GRASS how ever there
On Sun, 2011-11-13 at 11:02 +, Martin Spott wrote:
> James Turner wrote:
>
> > Looks very good to me - especially when it's combined with some of
> > the shader / materials work that is coming!
>
> Ah, well, I'm having mixed feelings about the shaders because they're
> imposing a huge perform
Christian Schmitt wrote:
> So if you all agree, I can create a clipper/epsilon branch against master to
> get this tested first.
Yes, please, maybe even one for clipper and another with Maxime's
epsilon changes applied.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective
James Turner wrote:
> Okay, this all sounds like good news indeed. Martin, Chris, Peter - I
> think the steps need to be as follows - get a branch of terragear with the
> clipper changes, and probably the epsilon changes Maxime describes
> (because I've always worried, they were only needed due t
Hi,
Martin Spott wrote:
> Thus, if you'd be willing to put your stuff into a branch at the main
> repo, please go ahead - call us if you don't have write access.
I don't feel too good about adding even more branches directly into the main
TG repo. The reason is this: In the process of the 850
James Turner wrote:
> Looks very good to me - especially when it's combined with some of
> the shader / materials work that is coming!
Ah, well, I'm having mixed feelings about the shaders because they're
imposing a huge performance hit onto our bigger multi-monitor setup
Cheers,
Ma
Curtis Olson wrote:
> 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 poi
On 13 Nov 2011, at 10:04, Martin Spott wrote:
> I'm just a bit unhappy that I'd have to check various _repositories_
> (_plus_ various branches therein) in order to get an update about what
> peple are actually doing about TerraGear. Experimental stuff is pretty
> much what Git branches (or bran
Maxime Guillaud wrote:
> 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
I've seen a couple of these when preparing the terrain which
Peter Sadrozinski wrote:
> 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.
Sure, I didn't propose to put the e
Hi Martin,
Martin Spott wrote:
> 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.
S
Peter Sadrozinski wrote:
> 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.
Actually, this is exactly what one of my commits is doing:
https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/
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
wrote:
> Hi Martin,
>
> I've been reluctant to m
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
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
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
On 12 Nov 2011, at 13:59, Maxime Guillaud wrote:
> I have had pretty good luck building complex scenery with a modified version
> of
> fgfs-construct. Here is what I did:
>
>
Okay, this all sounds like good news indeed. Martin, Chris, Peter - I think the
steps need to be as follows - get a b
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 po
James Turner 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 rep
24 matches
Mail list logo