Hi James,
On 24 Apr 2012, at 11:13, James Turner wrote:
> Well, the main thing needed is to break apart the 'finishInit' into more
> steps, to avoid the remaining pause. I think that can be done by traversing
> the scheduled aircraft list in batches.
>
Just as a quick heads up; I didn't have
On 25 Apr 2012, at 07:04, Renk Thorsten wrote:
> A quick 3 minute test flight with the ufo looks very promising - I didn't see
> any obvious issues with the version pulled 10 minutes ago. I will do longer
> tests later toady.
Thanks Thorsten!
James
--
On 25 Apr 2012, at 08:15, Durk Talsma wrote:
> 1). On my machine I'm actually experiencing an extremely startup during the
> "reading airport/nav data" stage (~up to minute or so). This usually only
> happens when I try to load flightgear for the first time. Once these files
> are buffered eve
> Yves:
>
> Towns are not point features. The vmap0 represents towns as points, but
> these particular points are parsed by terragear and turned into 1km by 1km
> "polygons" which are burned into the terrain. That gives the square
> appearance in the default scenery.
>
Hi John
Yes, Im aware of t
On Wed, Apr 25, 2012 at 9:03 AM, wrote:
> Yes, I’m aware of this behaviour of terragear and vmap0. But I also
> remember this "town model", a european church-like building with some
> houses grouped, all with same elevation. This looked very ugly i.e. in
> mountain areas (half of the village in th
Stuart Buchanan wrote:
> I don't believe the town model has been used for some time. It was supersede
> by the random object masking I introduced a while back.
I think what John and Yves are talking about is the introduction of the
various "zone_maison" models for each spot (therefore the term
"p
On Wed, Apr 25, 2012 at 9:26 AM, Martin Spott wrote:
> Stuart Buchanan wrote:
>> I don't believe the town model has been used for some time. It was supersede
>> by the random object masking I introduced a while back.
> I think what John and Yves are talking about is the introduction of the
> variou
On Wed, 2012-04-25 at 08:26 +, Martin Spott wrote:
> Stuart Buchanan wrote:
>
> > I don't believe the town model has been used for some time. It was supersede
> > by the random object masking I introduced a while back.
>
> I think what John and Yves are talking about is the introduction of th
Erik Hofman wrote:
> On Wed, 2012-04-25 at 08:26 +, Martin Spott wrote:
>> Unfortunately Erik never bothered responding to this issue, therefore
>> it's uncertain wether he'd silently agree or silently disagree to
>> reverting the above commit.
>
> I don't mind if it gets reverted but I did r
On 24 Apr 2012, at 22:09, Stuart Buchanan wrote:
> Feedback is welcome as always.
For me, the builds are extremely expensive - no idea why. The actual density
doesn't make a huge different (1.0 vs 2.0, I will experiment more later).
Eg my draw + GPU times go from 15msec to 100msec when I enab
On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote:
> For me, the builds are extremely expensive - no idea why. The actual density
> doesn't make a huge different (1.0 vs 2.0, I will experiment more later).
>
> Eg my draw + GPU times go from 15msec to 100msec when I enable random
> buildings. T
Hm... I'm getting good performance, but the rendering of the random buildings
do not seem to go via model-default.eff - they respond to the normal
visibility, but not to the terrain haze layer, so they remain visible when I
turn on heavy ground fog. Is there a conceptual problem, or can this be
On Wed, Apr 25, 2012 at 10:33 AM, Renk Thorsten wrote:
> Hm... I'm getting good performance, but the rendering of the random buildings
> do not seem to go via model-default.eff - they respond to the normal
> visibility, but not to the terrain haze layer, so they remain visible when I
> turn on h
Stuart
> -Original Message-
> From: Buchanan [mailto:stuar...@gmail.com]
> Sent: 25 April 2012 10:20
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Random Buildings
>
> On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote:
> > For me, the builds are extremely ex
Stuart
> -Original Message-
> From: Stuart Buchanan [mailto:stuar...@gmail.com]
> Sent: 25 April 2012 10:20
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Random Buildings
>
> On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote:
> > For me, the builds are extre
I'm overhauling how we expose FMS related data to Nasal, to hopefully make
FMS/CDU construction in Nasal easier, but also re-using the C++ code we already
have, since many systems tie into the data.
Along the way, I'm learning a lot about the easiest way to expose C++ data to
Nasal, and I'm als
Hooray alerted me to that one, and I would like to ask a few opinions on what
to do and offer my own thoughts.
> *What steps will reproduce the problem?*
> 1.F10-Environment-Weather-Advanced Weather
> 2.Select METAR
> 3.Return to Basic weather
> *What is the expected output? What do you see ins
> -Original Message-
> From: Vivian Meazza [mailto:vivian.mea...@lineone.net]
> Sent: 25 April 2012 10:46
> To: 'FlightGear developers discussions'
> Subject: Re: [Flightgear-devel] Random Buildings
>
> > One random thought - I think the texture (data/Textures/buildings.png)
> > may st
On 25 Apr 2012, at 11:53, Vivian Meazza wrote:
> Removed in Git
Alas this makes no difference.
Performance drop is roughly linear in the building density, though I won't
claim it's strictly linear. Given that this is an Ati 5770, I would be
*extremely* surprised if I'm fill-rate limited.
Ver
Hi,
I'm also interested about RTI/HLA informations.
Actually I 've compiled FGFS and SG with "-D ENABLE_RTI=ON" and I run FGFS with
"--hla=bi,10,FOM,ASN,mp-aircraft.xml"
If I use av-aircraft.xml in replacement of mp-aircraft.xml I have an FGFS crash
with this error during splashscreen:
Cannot
On Wed, Apr 25, 2012 at 12:05 PM, James Turner wrote:
> Performance drop is roughly linear in the building density, though I won't
> claim it's strictly linear. Given that this is an Ati 5770, I would be
> *extremely* surprised if I'm fill-rate limited.
>
> Very suspicious.
Have you tried areas
> It would probably make things a lot simpler for the average user if
> FGFS included a wizard that automatically identified which
> combinations of features would be usable on a specific installation.
> Using that result as constraining logic in the menus would allow
> unusable features to be kept
On 25 Apr 2012, at 12:35, Stuart Buchanan wrote:
> I must admit that I've only tested Edinburgh and San Francisco, which
> may simply not have as much Urban area as Berlin. I'll try Berlin
> when I get the chance, but could you see if the same problem occurs at
> EGPH and KSFO?
>
Yep, second ru
On 25 Apr 2012, at 12:56, James Turner wrote:
> Right, I can see that too. The draw / GPU times increases proportionally as
> the tiles (re-)load with buildings.
>
> It points to the actual geometry being the limiting factor, which is very
> odd.
http://files.goneabitbursar.com/fg/no-buildin
On 25 Apr 2012, at 13:35, James Turner wrote:
> Other suggestions most welcome.
Emilian suggested I check random vegetation (which generates many more quads),
at LOWI with vegetation off/onthe difference is from 50 fps down to 30ish, and
quad count goes from 100k to 200k - but nothing like wha
On Wed, Apr 25, 2012 at 1:35 PM, James Turner wrote:
> Observations
> - where did all the quads come from? Is my card going to a slow path
> to submit quads?
The Quads came from all the random buildings you've just created (or
have I misunderstood?) Each building consists of 9-12 quads, de
On Wed, Apr 25, 2012 at 1:57 PM, James Turner wrote:
> Emilian suggested I check random vegetation (which generates many more
> quads), at LOWI with vegetation off/onthe difference is from 50 fps down to
> 30ish, and quad count goes from 100k to 200k - but nothing like what happens
> for buildin
On 25 Apr 2012, at 14:22, Stuart Buchanan wrote:
> Perhaps I should be using a QUAD_STRIP instead. Don't know if that
> would make much difference though.
Doubtful, I'd say, if they are already in a single primitive set.
>
> The extra 300 Drawables are from the quadtree that is generated to a)
On Wed, Apr 25, 2012 at 2:44 PM, James Turner wrote:
> On 25 Apr 2012, at 14:22, Stuart Buchanan wrote:
>> The extra 300 Drawables are from the quadtree that is generated to a)
>> make culling fast b) to provide a mixture of LOD so that buildings
>> don't all appear in big blocks. That code is tak
> Emilian suggested I check random vegetation (which generates many more
> quads), at LOWI with vegetation off/onthe difference is from 50 fps down to
> 30ish, and quad count goes from 100k to 200k - but nothing like what
> happens for buildings with draw / GPU time.
>
> Interesting to note that ve
On 25 Apr 2012, at 14:56, Stuart Buchanan wrote:
> One benefit is better culling. The other is that we can have
> buildings gradually appear rather than all springing into view at once
> when you get within the LoD range of the center of the time (where
> objects at the edge might be significant
Am 25.04.2012 12:50, schrieb Renk Thorsten:
>> From my perspective, switching between GUIs runtime and trying to
>> mix features is problematic input in the first place. My
Agreed. And I don't think it was the intention of the current GUI to
toggle between both dialogs, while keeping advanced (or
Am 25.04.2012 13:35, schrieb Stuart Buchanan:
> Also, there is a significant slow-down in scenery loading.
I can certainly confirm ;-). It's not just a longer delay for initial
start-up (splash screen takes much longer to drop), it's also causing
issues with scenery taking too long to be loaded
Hello,
Well done!
A great enhancement! Now towns and Cities looks like they should!
Here on my system Framerates are really good, but yes scenery loading needs
some time- until framerates are stable enough to use it needs a much longer
time.
A very big surprise to me was that all buildings a
Heiko
> Hello,
>
> Well done!
>
> A great enhancement! Now towns and Cities looks like they should!
> Here on my system Framerates are really good, but yes scenery loading
> needs some time- until framerates are stable enough to use it needs a much
> longer time.
>
> A very big surprise to me w
35 matches
Mail list logo
