From: Michael Selig [EMAIL PROTECTED]
At 10/23/02, Curtis Olson wrote:
I'm not coming up with any good ideas ... I *thought* that if you
didn't specify --enable-clouds3d, then none of that code was executed,
but perhaps that's not the case ... (?)
From gdb, it's dying in the 3d cloud
John Check wrote:
On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
I just fixed a bug in the tile freeing code which accounted for the
very long pauses people were seeing after flying for a while.
Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std::cout
On 10/23/02 at 11:58 AM Jacek M. Holeczek wrote:
There is also another annoying problem. Basically, the FGFS runs very
smoothly on my machine except that every now and then (I don't have my
machine at hand now, but let's say it is about every 30 seconds) it
stops for a moment - I can see that in
Minimize the console window to minimise the effect.
Richard
-Original Message-
From: David Luff [mailto:David.Luff;nottingham.ac.uk]
Sent: 24 October 2002 11:27 am
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
On
Dear Jim Arnt,
I found the mistake in my FEM model. The struts are
coupled to the wing by means of hinges. In my model they were rigidly attached
!!. I alsocorrecteda wrong torsional stiffness for the spars. I now
find atan(127/1180) = 6.14 degrees for 80 N at the tip. Thus this is more
John Check writes:
On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
I just fixed a bug in the tile freeing code which accounted for the
very long pauses people were seeing after flying for a while.
Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std::cout
Michael Selig writes:
At 10/23/02, Curtis Olson wrote:
I'm not coming up with any good ideas ... I *thought* that if you
didn't specify --enable-clouds3d, then none of that code was executed,
but perhaps that's not the case ... (?)
From gdb, it's dying in the 3d cloud setup/init but beyond
Jacek M. Holeczek wrote:
...
There are two problems with the joystick.
First, there are two vertical bars/arrows in the cockpit for the
elevators, but only the right one is following the joystick (the
left one always stays in the middle) - however, if I view the plane
from outside I can see that
On 10/24/02 at 12:48 PM Jacek M. Holeczek wrote:
This is a known problem - Win95/98/Me are absolutely hopeless at
outputting
to the console - NT/2000/XT are much quicker, and Linux quicker still.
I'm not very experienced here ... but are you sure that the problem is
just writing to the
quickest fix
would be to fix the SG_LOG level of that output to be disabled with
--without-logging. The best fix might be to enable full run-time
logging
control. I have commented out all the sun position information
stuff in my
own build in the past and the pauses go away. As someone
Curtis L. Olson wrote:
[EMAIL PROTECTED] writes:
Agreed. Instruments that test whether they are powered should
default to powered if the aircraft does not provide a suitable
electrical system. This could translate to if the required power
bus property is not present. A simple default
David Megginson writes:
Norman Vine writes:
Also even though we probably would be drawing more objects
I wouldn't expect much of a hit in that there would be lot fewer
culling operations
When I was initially experimenting, putting all objects under a
fan-level branch gave quite a
Norman Vine writes:
Also even though we probably would be drawing more objects
I wouldn't expect much of a hit in that there would be lot fewer
culling operations
When I was initially experimenting, putting all objects under a
fan-level branch gave quite a performance hit, as well as
David Megginson
Norman Vine writes:
IMHO we should take advantage of our existing bucketing by fans
and put the LOD nodes at the 'leaf's branch' level instead of the
individual
triangle level. Just doing this would save us LOTS of nodes and should
speed things up a bit and not
David Megginson writes:
No, unfortunately, it does not handle a plain old recursive
destruction without having to do a linear search to find each kid
first. (Granted it's a short linear search since it should find it
right at the beginning of the list, but still, a lot more overhead
Norman Vine writes:
IMHO we should take advantage of our existing bucketing by fans
and put the LOD nodes at the 'leaf's branch' level instead of the individual
triangle level. Just doing this would save us LOTS of nodes and should
speed things up a bit and not require YAN set of
Curtis L. Olson writes:
Andy Ross writes:
Ah, never mind then. :)
Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
allocator hack is going to fix that for us. I'm with David now; plib
might have trouble doing constant-time deletion of children, but it
Curtis L. Olson writes:
Norman Vine writes:
How big is the hit if you simply delete a higher-level node and let
plib delete all of the branches and leaves underneath automatically?
My guess is that we would gain more by having the random objects
connected to the leaf rather then to
Norman,
This seems like a sensible optimization. If you remove the last entry
you don't need to do a memmove ... just decrement the total count. We
don't worry about freeing the memory until the entire list goes away,
and we never shrink list memory allocation.
But ok, while we are optimizing
From: [EMAIL PROTECTED]
[mailto:flightgear-devel-admin;flightgear.org]On Behalf Of Norman Vine
So if you aren't comfortable hacking, I suggest waiting a bit yet
Thanks, Norman, so I'll prefer to wait. As a close watcher of the scene you
might give a shout to the list when you think it's time
Curtis L. Olson writes:
David Megginson writes:
What I meant is that you use your scheduler a little higher up the
scene tree. The dynamic objects, for example, are under separate
branches for each scenery triangle; just deleting the top-level
triangle branch should be good enough,
Andy Ross writes:
Ah, never mind then. :)
Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
allocator hack is going to fix that for us. I'm with David now; plib
might have trouble doing constant-time deletion of children, but it
certainly should handle a plain old
On Thursday 24 October 2002 8:02 am, Curtis L. Olson wrote:
John Check writes:
On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
I just fixed a bug in the tile freeing code which accounted for the
very long pauses people were seeing after flying for a while.
Cool, but it
Andy Ross writes:
David Megginson wrote:
How big is the hit if you simply delete a higher-level node and let
plib delete all of the branches and leaves underneath automatically?
Probably equivalent. The overhead is usually in all the per-chunk
bookeeping, not the function calls.
On Thu, 24 Oct 2002 09:30:29 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Richard Bytheway wrote:
We really ought to sort out the ability to disable *any*
console
output after initialisation on Windows...
Is it maybe time to revisit the priority of most of the log messages?
I mean, the vast
Andy Ross writes:
David Megginson wrote:
How big is the hit if you simply delete a higher-level node and let
plib delete all of the branches and leaves underneath automatically?
Probably equivalent. The overhead is usually in all the per-chunk
bookeeping, not the function calls.
We
Richard Bytheway wrote:
We really ought to sort out the ability to disable *any* console
output after initialisation on Windows...
Is it maybe time to revisit the priority of most of the log messages?
I mean, the vast majority of these things are debugging output for
code that is mature and
* [EMAIL PROTECTED] (Jon Berndt) [2002.10.24 08:49]:
quickest fix
would be to fix the SG_LOG level of that output to be disabled with
--without-logging. The best fix might be to enable full run-time
logging
control. I have commented out all the sun position information
stuff in my
David Megginson wrote:
How big is the hit if you simply delete a higher-level node and let
plib delete all of the branches and leaves underneath automatically?
Probably equivalent. The overhead is usually in all the per-chunk
bookeeping, not the function calls.
We could try playing games with
Hi,
Thanks for your reply.
This is a known problem - Win95/98/Me are absolutely hopeless at outputting
to the console - NT/2000/XT are much quicker, and Linux quicker still.
I'm not very experienced here ... but are you sure that the problem is
just writing to the terminal window ?
From what
Curtis L. Olson writes:
However there is still an issue to worry about. The random ground
cover code can create thousands of objects which means a branch node
in our scene graph with thousands of kids. plib is not exactly
efficient at deleting kids and even if you know the index, it
David Megginson writes:
Curtis L. Olson writes:
However there is still an issue to worry about. The random ground
cover code can create thousands of objects which means a branch node
in our scene graph with thousands of kids. plib is not exactly
efficient at deleting kids and even
I little while ago, I made a posting asking how a pilot in the
Canadian far north (where magnetic compass readings are not useful)
could reset the heading indicator in flight using a single GPS
receiver.
The answer is actually fairly simple, if you don't mind a brief course
excursion: turn the
David Megginson writes:
I little while ago, I made a posting asking how a pilot in the
Canadian far north (where magnetic compass readings are not useful)
could reset the heading indicator in flight using a single GPS
receiver.
The answer is actually fairly simple, if you don't mind a
David Megginson writes:
What I meant is that you use your scheduler a little higher up the
scene tree. The dynamic objects, for example, are under separate
branches for each scenery triangle; just deleting the top-level
triangle branch should be good enough, rather than recursing right to
David Megginson wrote:
Curt's problem, though, is that his deletion code has to do a linear
search in the parent for each child node to remove it; I assume that
plib's internal code just iterates.
Ah, never mind then. :)
Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
David Megginson writes:
Curtis L. Olson writes:
However there is still an issue to worry about. The random ground
cover code can create thousands of objects which means a branch node
in our scene graph with thousands of kids. plib is not exactly
efficient at deleting kids and
Curtis L. Olson [EMAIL PROTECTED] said:
David Megginson writes:
Maybe a middle ground approach would be to add a branch for each
fan/strip and then underneath that, add a branch for the objects from
each leaf.
This is a **long** thread :-) (and I'm behind reading the list). I'm glad
you
Tony Peden writes:
Hmm, curious. How can you get anything but ground track from a single
receiver with a single antenna?
You can't, but ...
your ground track is a 'heading' if ...
you keep a steady course.
This is not as hard as it sounds with a GPS because
most units allow you to program
* [EMAIL PROTECTED] (Jon S Berndt) [2002.10.24 12:08]:
On Thu, 24 Oct 2002 09:30:29 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Richard Bytheway wrote:
We really ought to sort out the ability to disable *any*
console
output after initialisation on Windows...
Is it maybe time to revisit the
Hi,
Following my yesterday's mail I gained some more experience in my
joystick problem. It seems that the problem is related to the fact
that I have two USB RamblePads, instead of only one (yesterday I said I
did not observe problems with the rudder, but ... they are there).
In the evening by a
41 matches
Mail list logo
