Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-24 Thread Geoff McLane
Hi Jason, Have just completed a new fgfs build, and a TG tool build, and have downloaded your - 34169132 newScenery-YSSY.tar.bz2 149396748 newScenery.tar.bz2 And yes, when I load that scenery in fgfs all I see are spaghetti strips, like in your work/fgfs-screen-001.png image... I unloaded it

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-24 Thread Geoff McLane
Hi Jason, Ok my 5426688.btg.gz took about 5 hours to generate. And most of the near final console output shows - ... center = [ -4.63734e+06, 2.55623e+06, -3.54361e+06 ] radius = 16282.1 dumping normals = 94646 creating 497 fans of type 0 creating 169 fans of type 1 creating 1470 fans of type 2

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-24 Thread James Turner
On 25 Oct 2011, at 03:03, Geoff McLane wrote: You can find it here - http://geoffair.org/tmp/5426688.btg.gz So tomorrow to try to discover is the problem in the fgfs-contruct output, the write, or in the fgfs read and rendering... I'll take a look too :) All the info above looks very

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-23 Thread Jason Cox
James, here is the scenery that I have generated. Te file 33M and i also have a complwork directory if you would like to look at that but its a +130M bz2 file http://dl.dropbox.com/u/3028956/newScenery-YSSY.tar.bz2 Jason On Sun, 2011-10-23 at 01:46 +0100, James Turner wrote: On 23 Oct 2011,

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-23 Thread Geoff McLane
Hi Jason, Thanks for sharing your generated BTG files... I will try loading these soon... I am presently in the process of updating SG/FG/TG to the latest respective gits, particularly to get James' latest sg_binobj, and would appreciate having your full - newSydScenery/work perhaps

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-23 Thread Jason Cox
Geoff, the whole scenery build directory is http://dl.dropbox.com/u/3028956/newScenery.tar.bz2 The process that i used for cutting up the 3sec dems was to use your makeYSSY-1.0.4 to produce only the SRTM directory and run terrafit as well as produce the airports. After that everything came from

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-22 Thread Jason Cox
James, good work :) I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I can also report that on my box running a GeForce 8400 that the frame rate above 80/sec :) Jason On

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-22 Thread James Turner
On 23 Oct 2011, at 00:41, Jason Cox wrote: I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I'd be pretty suspicious of this - much more likely, there's a bug in my

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-20 Thread Jason Cox
James, I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I tell the changes that were made to sg_binobj.cxx as I do not understand how to drive GIT to change to a branch? Jason On Sat, 2011-10-15

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-20 Thread James Turner
On 20 Oct 2011, at 09:48, Jason Cox wrote: I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I tell the changes that were made to sg_binobj.cxx as I do not understand how to drive GIT to

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-20 Thread Jason Cox
Thanks will give it a try Jason On Thu, 2011-10-20 at 10:04 +0100, James Turner wrote: On 20 Oct 2011, at 09:48, Jason Cox wrote: I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-17 Thread Lauri Peltonen
Hi. Here is a random thought: what if the polygon data was painted onto a raster texture (of some sufficient resolution) in correct bottom up order, rather than being clipped.   Then at the end of the process we figure out how to extract the resulting polygons from the raster image.  This

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-17 Thread Martin Spott
HB-GRAL wrote: There is so many software to do exactly this task. I could not imagine that our scenery is THAT important for this developement. At least our Scenery led to significant improvements in the way GRASS7 deals with vector data ;-) Cheers, Martin. -- Unix _IS_ user

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-16 Thread Maxime Guillaud
On Sat, 15 Oct 2011 08:53:45 + (UTC) Martin Spott martin.sp...@mgras.net wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. For

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-16 Thread Peter Sadrozinski
The 'bad' nodes are points that are co linear with a previous segment on the same contour. When this happens, the even-odd algorithms used for clipping only see one intersection instead of two. So, as a scanline is evaluated, if we were currently outside a poly, we would then determine we were

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-15 Thread Martin Spott
Jason Cox wrote: I am hoping to try your changes as I was constantly blowing up the scenery around YWLM by using osm residental data [...] OSM residential is quite ambitious - I'd be a happy man if I succeeded building tertiary without triggering GPC segfaults in 'fgfs-construct' I think

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-15 Thread HB-GRAL
Am 15.10.11 10:53, schrieb Martin Spott: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Martin. Hi Martin Are there any

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-15 Thread James Turner
On 15 Oct 2011, at 15:22, HB-GRAL wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Martin. Hi Martin Are there any

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-15 Thread HB-GRAL
Hi James Thank you very much (and Martin of course) for diving into. I am just curious how you go to replace GPC. Cheers, Yves Am 15.10.11 17:20, schrieb James Turner: On 15 Oct 2011, at 15:22, HB-GRAL wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-15 Thread Martin Spott
HB-GRAL wrote: Am 15.10.11 10:53, schrieb Martin Spott: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Are there any concrete

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-15 Thread HB-GRAL
Am 16.10.11 00:30, schrieb Martin Spott: HB-GRAL wrote: Am 15.10.11 10:53, schrieb Martin Spott: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct'

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-14 Thread Jason Cox
Hi all, Just giving the whole scenery gen ago for the YWLM area and found that the latest git pull appears to broken. the make bailed out with the following Making all in DemRaw2ascii make[3]: Entering directory `/data/terragear/terragear-cs/src/Prep/DemRaw2ascii' make[3]: *** No rule to make

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-14 Thread James Turner
On 14 Oct 2011, at 23:42, Jason Cox wrote: I then did a git pull just to make sure that it wasn't a file that i missed but it reports that i am up to date. I've been doing some TerraGear hacking recently, so I'm the most likely person to have caused this, but on both my systems (Linux and

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-14 Thread Jason Cox
James, I am hoping to try your changes as I was constantly blowing up the scenery around YWLM by using osm residental data and my TOPO's from ga.gov.au I will try a clean terragear pull and see how that goes Jason On Sat, 2011-10-15 at 01:37 +0100, James Turner wrote: On 14 Oct 2011, at 23:42,

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-08 Thread James Turner
On 7 Oct 2011, at 19:24, Martin Spott wrote: This is what happens when running 'genapts' with a modified 'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of just one runway and two windsocks): Starting program: /home/martin/install_headless/bin/genapts

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-06 Thread James Turner
On 4 Oct 2011, at 13:53, James Turner wrote: Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) I've committed an updated BTG reader/writer to simgear/next, which supports the current format, and a higher-versioned format with 32-bit indices. Based

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-06 Thread Curtis Olson
On Thu, Oct 6, 2011 at 3:35 PM, James Turner zakal...@mac.com wrote: I've committed an updated BTG reader/writer to simgear/next, which supports the current format, and a higher-versioned format with 32-bit indices. Based on some conversions, 32-bit indices (all zeroes so far) compress down

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-06 Thread Martin Spott
James Turner wrote: If someone could incorporate the revised sg_binobj.cxx from simgear/next into simgear-cs, and verify the results with terragear, I'd be fascinated to know if the 'swirlies' are gone! Will do, thanks a lot so far ! Martin. -- Unix _IS_ user friendly - it's just

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-04 Thread James Turner
On 2 Oct 2011, at 19:00, J. Holden wrote: Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices? Fans? Triangles? It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG format

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-04 Thread Curtis Olson
On Tue, Oct 4, 2011 at 3:10 AM, James Turner zakal...@mac.com wrote: On 2 Oct 2011, at 19:00, J. Holden wrote: Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices? Fans? Triangles? It's 65536

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-04 Thread James Turner
On 4 Oct 2011, at 13:34, Curtis Olson wrote: Here's a random idea on the writer side: Would it be possible to do something like: if (size of any of my structures are 65535) then write_32bit_index_btg() else write_16bit_index_btg() endif Then we'd be spending are larger

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-04 Thread Curtis Olson
On Tue, Oct 4, 2011 at 7:53 AM, James Turner zakal...@mac.com wrote: Entirely possible, yes - however I *suspect* it's unnecessary since gzip will compress the larger indices back down to a few % larger than what we currently have. Of course, I can't confirm or deny that suspicion until I

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-04 Thread Arnt Karlsen
On Tue, 04 Oct 2011 13:53:29 +0100, James wrote in message 04ab1637-d3b3-4396-9a68-4910e1235...@mac.com: On 4 Oct 2011, at 13:34, Curtis Olson wrote: Here's a random idea on the writer side: Would it be possible to do something like: if (size of any of my structures are 65535)

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-02 Thread J. Holden
Very good read - thanks. I was worried the limit had been reached and that may have been demoralizing - but I'm going to keep pushing forward now. Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices?

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread James Turner
On 1 Oct 2011, at 03:33, Curtis Olson wrote: That could very well be true ... and I don't think it would be a huge coding change ... but it should be done in a way that bumps up the btg version number and picks a new packet id so as to maintain backwards compatibility with all the

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread Curtis Olson
On Sat, Oct 1, 2011 at 9:29 AM, James Turner wrote: Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread James Turner
On 1 Oct 2011, at 15:37, Curtis Olson wrote: We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread Curtis Olson
I think the original intention was to keep the read/write together and centralized so it was easier to keep format changes compatible. That said, I haven't been tracking terragear-cs changes so I don't know what version of simgear they are using or if they've made other changes around this area.

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread Christian Schmitt
James Turner wrote: Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James Please be aware that TG uses SG-CS

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread Martin Spott
Christian Schmitt wrote: Please be aware that TG uses SG-CS currently. I used it with the normal SG for a while but this was no longer possible recently. It exposed weird behaviour and crashes. Indeed, we're still maintaining a simgear-cs for terragear-cs to keep a working source tree as a

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-10-01 Thread Martin Spott
Martin Spott wrote: Indeed, we're still maintaining a simgear-cs for terragear-cs to keep a working source tree as a fallback in those situations when essential features are removed from stock simgear (which already had happened).

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-30 Thread Martin Spott
J. Holden wrote: I apologize in advance considering I'm in a very complaining mood at the moment. From my perspective that's ok. We've been doing experiments with detailed land cover data and (OSM-) roads for about five years now - the first sample was built for LinuxTax 2006 - and I know how

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-30 Thread Martin Spott
J. Holden wrote: PS - I only get around 3-6 FPS on this brand new laptop(!), and I'm finding with 2.4 simply launching fgfs --airport=KMSP --aircraft=ufo loads up local weather/real-time weather, which is terrible for a simple scenery flyover test on a poorly performing computer Yup, we

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-30 Thread James Turner
On 30 Sep 2011, at 11:56, Martin Spott wrote: Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm A very useful description, yes! James

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-30 Thread Curtis Olson
All that weird stuff is quite easy to explain. The binary .btg scenery format uses 16 bit integers as indices for the vertex, normal, texture coordinate lists. At one point we were using signed 16 bit integers, but I'm pretty sure we sneakily changed the flightgear btg loader to use unsigned 16

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-30 Thread joacher
Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. Ten years ago 16 Bit

Re: [Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-30 Thread Curtis Olson
On Fri, Sep 30, 2011 at 4:22 PM, joac...@gmx.de wrote: Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional

[Flightgear-devel] Scenery Creation/TerraGear problems

2011-09-29 Thread J. Holden
I apologize in advance considering I'm in a very complaining mood at the moment. I've just compiled 4 square degrees of scenery around the Minneapolis/St. Paul area in an attempt to figure out whether or not my Alaska scenery creation process worked on places in the lower 48 states.