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
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
Geoff,
thanks for looking at this.
I think that the swerllies have actually gone and are now replaced by
spaghetti.
the old behavior was the terrain being stretched inside a triangle
incorrectly followed by tile not being produced at all. in FGFS this
would also bottom out the rendering at <1 fps.
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
I just added a comment to a merge request for "terragear-cs" on
Gitorious and I think this might be of general interest. Therefore I'm
posting the same comment as a followup to this thread:
- snip -
Increasing the ressource limits i
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 s
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 excluding
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, a
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
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
O
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
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
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
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 fr
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. Thi
On Sun, Oct 16, 2011 at 7:22 AM, Peter Sadrozinski wrote:
> 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 w
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 in
On Sat, 15 Oct 2011 08:53:45 + (UTC)
Martin Spott 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 what it's worth...
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 'f
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 concret
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
>>>
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
>
>
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
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 t
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:4
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 M
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 ta
On Sat, 2011-10-08 at 11:17 +0100, James Turner wrote:
> 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):
> >
> > [snip]
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
> --input=/hom
James Turner wrote:
> If someone could incorporate the revised sg_binobj.cxx from
> simgear/next into simgear-cs, and verify the results with terragear,
This is what happens when running 'genapts' with a modified
'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of
just one runwa
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
On Thu, Oct 6, 2011 at 3:35 PM, James Turner 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 with
> gzip -9 t
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. Base
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 structure
On Tue, Oct 4, 2011 at 7:53 AM, James Turner 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 upgrade the
>
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
On Tue, Oct 4, 2011 at 3:10 AM, James Turner 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 vertic
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
fo
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
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).
http://mapserver.flightgear.org/git/gitweb.pl?p=t
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
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 cur
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.
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
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-shor
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 exis
On Fri, Sep 30, 2011 at 4:22 PM, wrote:
> Am Fri, 30 Sep 2011 16:10:39 -0500
> schrieb Curtis Olson :
>
> > 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
Am Fri, 30 Sep 2011 16:10:39 -0500
schrieb Curtis Olson :
> 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 hurt much more than
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 b
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
"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
"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
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.
Fortunately
53 matches
Mail list logo
