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
I'm not sure if increasing the tree count could trigger the same
problem.
I've been flying with 8 times the default tree density for the last half
year (I edited materials.xml) - apart from the (expected) general overall
impact on framerate, I haven't seen any issues like second-long lags when
I think it's grossly unfair to mix these issues: Spaceflight requires
to essentially write a space simulator. One of my first statements in
the
forum was:
Orbital flights opens a whole new can of worms besides the need for
different rendering - completely different physics, completely
From: thorsten.i.r...@jyu.fi
To provide the context: I wrote the above in response to pictures of Mars
(from Celestia) being posted and talk about Apollo missions, i.e. having
interplanetary missions in mind. (Jon actually knows that, because I
explained it later in the thread :-) ) -
On Mon, Aug 1, 2011 at 5:41 AM, Ove Kåven o...@arcticnet.no wrote:
If there are no other references, the prop_root is automatically
destroyed when sgLoad3DModel_internal returns, causing the memory to be
freed. So, later on, when OSG wants to do something with these
particles, the freed
On 1 Aug 2011, at 12:30, Csaba Halász wrote:
Indeed, I have been unable to run FG with particles enabled since a
long time due to random crashes in the particle code. Call stack
frequently included functions your description mentions, so I hope
this patch will fix that issue.
Can anyone
James wrote:
On 1 Aug 2011, at 12:30, Csaba Halász wrote:
Indeed, I have been unable to run FG with particles enabled since a
long time due to random crashes in the particle code. Call stack
frequently included functions your description mentions, so I hope
this patch will fix that
FlightGear 2.4.0 will be released in a bit more than two weeks from now.
To reach a broad audience, I am looking for someone to write an
announcement, initially in English.
Also, very welcome are people able to translate this into their native
language and distribute it to their local
On Mon, Aug 1, 2011 at 2:24 PM, James Turner zakal...@mac.com wrote:
Can anyone think of a reason particles are fine for some (many?) people
without this patch? Of course the patch should be applied, I'm just wondering
what would affect the ref-counting logic to hide the problem in some
On 01.08.2011 14:24, James Turner wrote:
On 1 Aug 2011, at 12:30, Csaba Halász wrote:
Indeed, I have been unable to run FG with particles enabled since a
long time due to random crashes in the particle code. Call stack
frequently included functions your description mentions, so I hope
this
for pilots:
A new FG plane is coming with an updated flight deck, more real weather,
more fog and RVR, more realistic in dynamics.. U can still fly however u
want wherever u want.. and do it better..
for city:
The FG development is gonna kill the market, its basically a drop in
replacement for M$
NOTAM
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on
Hi All,
The July 2011 edition of the FlightGear Newsletter is now available:
http://wiki.flightgear.org/FlightGear_Newsletter_July_2011
As always, we are looking for contributions to the next newsletter,
available here:
http://wiki.flightgear.org/FlightGear_Newsletter_August_2011
-Stuart
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
23 matches
Mail list logo
