Thorsten,
You mentioned earlier that a lot of the performance issues would disappear
if we could probe the terrain 100 times faster. I've been thinking about
this for a while for ai traffic, skyop's moving map instrument, and weather.
I'm thinking of storing some resolution of altitude data in the tile itself,
making altitude queries very fast at the expense of a larger tile (in memory
and disk).
I'm just starting the work, but I would like any feedback on the idea. It
may require some lod implementation if the base tile size gets too big.
I've been thinking about trying to get osg paged lod working with a new sg
bucket.
Obviously, this is a huge undertaking, but I hope to get a proof of concept
up and running in the next 6 months or so.
On Jul 12, 2011 6:24 PM, "Vivian Meazza" <vivian.mea...@lineone.net> wrote:
> ThorstenB wrote
>
>> -----Original Message-----
>> From: ThorstenB [mailto:bre...@gmail.com]
>> Sent: 12 July 2011 22:40
>> To: FlightGear developers discussions
>> Subject: Re: [Flightgear-devel] Future Weather System
>>
>> On 12.07.2011 23:11, Vivian Meazza wrote:
>> > I would even sacrifice a few more fps for the sake of smoothness.
>> > For me the main issue is not so much the framerate, as the way the
>> framerate
>> > is being delivered.
>>
>> Indeed. Frame rate is misleading - the number only has a meaning if all
>> frames were guaranteed to be evenly spaced (like on a TV/display). But
>> that's not guaranteed for FG, so ignore this number.
>>
>> In order to judge and compare visual quality, look at the worst-case
>> delay in between two frames instead. If a single delay in between two
>> frames is too high, the human eye immediately spots a "stutter". Doesn't
>> help if all the other frames were produced at high rate. And if that
>> stutter happens repeatedly (say every second), it's what limits visual
>> quality.
>>
>> You can enable a better property to compare performance using "View" =>
>> "Show worst-case frame delay". It shows the longest delay in between two
>> frames within the last second of simulation (lower left corner). The
>> lower the number, the better. In order to maintain an acceptable 25Hz
>> simulation, the frame delay must never exceed 40ms.
>> Is anyone capable of running FlightGear with either global or local
>> weather enabled with a frame spacing not exceeding 40ms?
>>
>
> Local 60 - 120ms and anything in between ~ 40 fps indicated
> Global 17 - 37ms ~ 75 fps indicated
>
> Both showed occasional excursions well outside these values.
>
> Using the Hurricane at EGMH and current METAR
>
> Vivian
>
>
>
>
------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
