I wrote
Thorsten wrote:
Meanwhile - at the cheap end of the market, Emilian and I have cleaned
up
most of the textures, made some of the AC3D models single-sided,
reordered
the objects, provided unique names, and converted everything to .dds.
This has much improved
Unless there are any objections, I intend to push Emilian's and my work
to Git later today.
Has been working fine for me the last days - no problems with dds
textures, and I've been using your reworked texture sheets as basis to
generate the regular m x n structures needed for Stuart's system.
Hi Stuart,
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it avoids the
extra computations/allocations
2011/8/7 Mathias Fröhlich:
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it avoids the
extra
Hi,
On Sunday, August 07, 2011 12:32:36 Stuart Buchanan wrote:
2011/8/7 Mathias Fröhlich:
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be
2011/8/7 Mathias Fröhlich wrote:
I have now seen that this has overlapped a question from yours form yesterday
evening. I just got up today morning, took a look outside - still no summer in
mid europe - and decided to hack something. Then I just thought that this
change might be good to
2011/8/7 Mathias Fröhlich wrote:
Hi Stuart,
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it
Hi,
On Sunday, August 07, 2011 20:46:46 Stuart Buchanan wrote:
I think this may have broken YASim aircraft. I've tried a selection (dc3,
dc-3, a4f) and they all start at 36,000ft altitude with 0 IAS.
I suspect it might be an initialization order issue,
I've raised it as bug 397
2011/8/2 Mathias Fröhlich wrote:
So I decoupled these two structures somehow. I have put bv-trees of geometry
into the userdata field of the scenegraph. So for the high level operations
like tile loading, the scenery paging is used to load and get rid of the bv-
trees. The whole intersectable
2011/8/2 Mathias Fröhlich wrote:
snip
So I decoupled these two structures somehow. I have put bv-trees of geometry
into the userdata field of the scenegraph. So for the high level operations
like tile loading, the scenery paging is used to load and get rid of the bv-
trees. The whole
Meanwhile - at the cheap end of the market, Emilian and I have cleaned up
most of the textures, made some of the AC3D models single-sided,
reordered
the objects, provided unique names, and converted everything to .dds.
This has much improved loading/unloading, and given a much better
Thorsten wrote:
Meanwhile - at the cheap end of the market, Emilian and I have cleaned
up
most of the textures, made some of the AC3D models single-sided,
reordered
the objects, provided unique names, and converted everything to .dds.
This has much improved loading/unloading, and
ThorstenB wrote:
On 02.08.2011 00:30, James Turner wrote:
Yes - I have wondered about separately loading the BTG files, but
that seems like a world of pain. In the first instance, simply having
the tiles loaded in the cache would be a reasonable start.
The tile manager is capable of
So, I quickly wrote an alternative to the current Nasal system
geodinfo(),
using the groundcache instead of the current scenery method.
(...)
Comments?
You just made me a rather happy person :-) That seems like a sizeable
improvement in performance!
One question - do the two methods have
On 30 Jul 2011, at 20:31, Stuart Buchanan wrote:
So, I quickly wrote an alternative to the current Nasal system geodinfo(),
using the groundcache instead of the current scenery method.
I'm working on a new (C++) navigation display instrument, which I hope to add a
proper EGPWS terrain
Hi Stuart,
On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
So, I quickly wrote an alternative to the current Nasal system geodinfo(),
using the groundcache instead of the current scenery method.
This sounds very interesting: As far as I can tell, the AI system still makes
use of
On Mon, Aug 1, 2011 at 10:18 AM, Durk Talsma wrote:
Hi Stuart,
On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
So, I quickly wrote an alternative to the current Nasal system geodinfo(),
using the groundcache instead of the current scenery method.
This sounds very interesting: As far as
On Mon, Aug 1, 2011 at 9:48 AM, James Turner wrote:
On 30 Jul 2011, at 20:31, Stuart Buchanan wrote:
So, I quickly wrote an alternative to the current Nasal system geodinfo(),
using the groundcache instead of the current scenery method.
I'm working on a new (C++) navigation display
On 1 Aug 2011, at 22:35, Stuart Buchanan wrote:
In both cases, are you not going to be limited by what tiles have been loaded?
Yes - I have wondered about separately loading the BTG files, but that seems
like a world of pain. In the first instance, simply having the tiles loaded in
the cache
On 02.08.2011 00:30, James Turner wrote:
Yes - I have wondered about separately loading the BTG files, but
that seems like a world of pain. In the first instance, simply having
the tiles loaded in the cache would be a reasonable start.
The tile manager is capable of satisfying multiple
Hi,
On Thursday, July 14, 2011 11:04:50 thorsten.i.r...@jyu.fi wrote:
I can maybe tell you what I need. Currently, Local Weather uses terrain
info in three ways:
1) a presampling routine gets gross features in the vicinity of the
aircraft, i.e. mean altitude, median altitude, max.
Hi,
On Saturday, July 30, 2011 21:31:37 Stuart Buchanan wrote:
Hi Mathias,
Sorry not to anser in time ...
Presumably this is using the ground_cache rather code rather than the
scenery.get_elevation_m() code that the Nasal system uses to to get
geodinfo()
If so, I'll see if there's
Durk,
On Monday, August 01, 2011 11:18:02 Durk Talsma wrote:
On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
So, I quickly wrote an alternative to the current Nasal system
geodinfo(), using the groundcache instead of the current scenery
method.
This sounds very interesting: As far
Stuart,
On Monday, August 01, 2011 21:51:16 Stuart Buchanan wrote:
I'm looking to see whether we should just have a single way to query
the ground elevation using the groundcache, and use that everywhere.
See the lenghty explanation in the response to the weather system.
However, the AI call
On Fri, Jul 29, 2011 at 3:18 PM, Stuart Buchanan wrote:
2011/7/14 Mathias Fröhlich wrote:
While being able to do a croase ground query on such a kind of regular grid
might be beneficial for the weather module. I would prefer the ai module just
using the already available bounding volume tree
2011/7/14 Mathias Fröhlich wrote:
While being able to do a croase ground query on such a kind of regular grid
might be beneficial for the weather module. I would prefer the ai module just
using the already available bounding volume tree that is used for the main
aircrafts elevation queries.
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
Here, with a Core 2 Quad, 4Gb RAM, nVidia GTx285 with 2Gb VRAM there is a
huge difference in performance. At EGMH and using METAR, I get 75 fps
with
Global Weather, but when I use Local Weather, using the same METAR, I
get a
little over half that.
I hate to repeat myself, but what set of
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,
Hi,
On Wednesday, July 13, 2011 02:16:29 Peter Sadrozinski wrote:
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.
What I'd really love to see in the mid-to-long-term range is some kind
of unified weather system. It does not really make sense for an average
user to have two systems to choose from.
Well, there's also a reason - the different design philosophy - and at
some point you may want to consider
Am 12.07.2011 10:18, schrieb thorsten.i.r...@jyu.fi:
Well, there's also a reason - the different design philosophy - and at
some point you may want to consider that before you merge.
Rest assured, there won't be any merge of the weather system without you ;-)
If you compare a system that
-Original Message-
From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi]
Sent: 12 July 2011 09:18
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Future Weather System
What I'd really love to see in the mid-to-long-term range is some kind
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
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
[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
Am 11.07.2011 14:37, schrieb Stuart Buchanan:
Hi Thorsten,
I think we've gone beyond what can be done for the upcoming
release, but comments below.
What I'd really love to see in the mid-to-long-term range is some kind
of unified weather system. It does not really make sense for an average
On Mon, Jul 11, 2011 at 8:32 PM, Torsten Dreyer wrote:
Am 11.07.2011 14:37, schrieb Stuart Buchanan:
Hi Thorsten,
I think we've gone beyond what can be done for the upcoming
release, but comments below.
What I'd really love to see in the mid-to-long-term range is some kind
of unified
Am 11.07.2011 22:05, schrieb Stuart Buchanan:
[For a moment I thought this post was from Thorsten Renk, and got _really_
worried ;) ]
Hehe - apologies for having so many T(h)orstens around here. The parents
of the mid 60s were not very creative with names...
Do you see this as a problem with
39 matches
Mail list logo