On 12/20/02 at 4:59 PM Bernie Bright wrote:
On Thu, 19 Dec 2002 20:36:12 -0700
Dave Perry [EMAIL PROTECTED] wrote:
I updated plib, simgear, and FlightGear source from cvs this evening and
compiled plib and simgear with no problems. I get the following error
compiling FlightGear (at the
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
David Megginson writes:
He means texture animations (moving the UV coordinates around).
Probably easier to use pbuffers or the equivalent on those platforms
that don't support pbuffers
ie reconstruct the texture each
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
Then what does ssgTexTrans:: support?
It controls the texture transform
google( glMatrixMode GL_TEXTURE )
That's correct, but I haven't used that. My reading is you can apply matrices
to rotate and translate the texture mapping
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
Then what does ssgTexTrans:: support?
It controls the texture transform
google( glMatrixMode GL_TEXTURE )
That's correct, but I haven't used that. My reading is you can apply matrices
to rotate
Norman Vine wrote:
In the case of a 3D cockpit there may be a good use for this
in building the texture up but the main problem I see is still
going to be polygon offset related, so I am suggesting that
a better approach might be to bind to textureObjects rather
then an actual texture and
Norman Vine writes:
Norman Vine wrote:
In the case of a 3D cockpit there may be a good use for this
in building the texture up but the main problem I see is still
going to be polygon offset related, so I am suggesting that
a better approach might be to bind to textureObjects rather
Curtis L. Olson writes:
One of the knocks against programs like Fly and MSFS is their horribly
slow instrument update rate.
I will confirm that comment on FLY. The panel operation is great for
startup, etc., but it's basically unusable for IFR because of the slow
update.
All the best,
Curtis L. Olson writes:
Norman Vine writes:
This method should also be *considerably* faster then the current
Panel code in that the actual updating of the instruments can be
done on a round robin basis reducing the work done per pass as
all but the instrument texture being
Norman Vine writes:
If we can half the frame rate hit of the Panel using this kind of scheme,
and I expect even a better boost, then we could render half the instruments
one frame and the other half the next and still have the ~same instrument
update rate as we currently have and an
Norman Vine wrote:
This method should also be *considerably* faster then the current
Panel code in that the actual updating of the instruments can be
done on a round robin basis
I'm not sure this will work as well as you think. The only way to
reduce the amount of work done is to re-render
David Megginson writes:
Norman Vine writes:
If we can half the frame rate hit of the Panel using this kind of scheme,
and I expect even a better boost, then we could render half the instruments
one frame and the other half the next and still have the ~same instrument
update rate
Andy Ross writes:
Norman Vine wrote:
This method should also be *considerably* faster then the current
Panel code in that the actual updating of the instruments can be
done on a round robin basis
I'm not sure this will work as well as you think. The only way to
reduce the amount of
Curtis L. Olson wrote:
Interesting stuff ... One paper discusses land mark recognization to
aid autonomous vehicle navigation (i.e. around a different planet that
doesn't have gps satellites overhead), and the other paper discusses
the development of an autopilot for a Mars flying vehicle.
Do
Erik Hofman writes:
Curtis L. Olson wrote:
Interesting stuff ... One paper discusses land mark recognization to
aid autonomous vehicle navigation (i.e. around a different planet that
doesn't have gps satellites overhead), and the other paper discusses
the development of an autopilot for
Norman Vine wrote:
This used to be true but not with the current cards or on any NVIDIA
card with a current driver glCopyTexSubImage is FAST even without
using pbuffers
It's not all that fast. You still have to clear the back buffer and
you still need to do the memory blit into the texture.
Norman Vine writes:
also note I think we would all be happy with a 15hz instrument update
if it meant we went from a 30hz to a 60hz screen refresh rate :-)
For VFR, usually; for IFR, never. Even in VFR, we have to watch the
instruments closely sometimes -- on final approach, I want the
Andy Ross writes:
Again, I'm not saying that it won't be faster. I'm saying that it
might not be quite as fast as you imagine, and that it involves
significant tradeoffs in panel fidelity that I'd be really hesitant to
make on systems that are already getting slow frame rates.
You'd
hi all,
i'm working on an overhead gps-like display to aid landings
(because i'm too lazy to bother with VOR, etc). so far, i've got a
graphical app that takes in lat/long/heading from FG's network io and
displays the heading, KSFO's runways, and a line from the current
location to KSFO.
Curtis L. Olson wrote:
Erik Hofman writes:
Curtis L. Olson wrote:
Interesting stuff ... One paper discusses land mark recognization to
aid autonomous vehicle navigation (i.e. around a different planet that
doesn't have gps satellites overhead), and the other paper discusses
the development
rm writes:
also, does anyone know of a reference regarding making
corrections for true north
I missed this one
see SimGear / magvar
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Andy Ross writes:
Remember that the slow thing your trying to fix is the fill rate
penalty of rendering all the panel layers; the panel layers don't have
significant geometry to speak of, they're slow because of all the
texture reads. Fixing that problem with a fill-rate-intensive
Melchior FRANZ writes:
http://www.unet.univie.ac.at/~a8603365/remote.html
(link to the script at the bottom)
It's still rudimentary. It doesn't treat longer packages
correctly yet. I should really finish it some day ... :-)
Melchior,
Thanks, I just got a chance to test this out. It
Erik Hofman writes:
I think I should have stated this a little more clear (In this case I
used the Dutch grammar to express an English sentence the wrong way, I
expect this might happen every once in a while in the feature).
To state it clear: I do like to be noticed of all those projects
Curtis L. Olson wrote:
Ok, I've put both of those as news items on the web page, but these
days you have to scroll down to see the news items so I doubt most
people even see them ...
You make me feel like it's all my fault.
;-)
Erik
___
Norman Vine writes:
The main speedup will come not from the method that the instrument
texture is constructed but from the side effect in that most of the
time most of the instrument textures will not need to be
constructed at all !!!
The instrument textures are all static.
All the
David Megginson writes:
Norman Vine writes:
The main speedup will come not from the method that the instrument
texture is constructed but from the side effect in that most of the
time most of the instrument textures will not need to be
constructed at all !!!
The instrument
On Fri, 2002-12-20 at 09:58, Norman Vine wrote:
David Megginson writes:
Norman Vine writes:
If we can half the frame rate hit of the Panel using this kind of scheme,
and I expect even a better boost, then we could render half the instruments
one frame and the other half the
Tony Peden writes:
I think you'll find that once turbulence is introduced, this won't be
true at all. Maintaining straight and level flight in even light
turbulence requires the pilot (or autopilot) to constantly scan the
instruments and make adjustments.
That won't affect oil pressure
Tony Peden writes:
ie in quasi steady flight conditions most instruments would probably go
minutes before needing a refresh esp. if we were smart about the delta
value that required an update.
I think you'll find that once turbulence is introduced, this won't
be true at all.
Norman Vine writes:
That won't affect oil pressure temp gas gauges ect :-)
If I ever find a plane without a wobbly gas gauge, I'll let you know.
The point is well taken, though. The question is whether there's
enough potential saving left to bother.
All the best,
David
--
David
David Megginson
It's hard to picture any
situation (other than parked with the engine off) where the main six
and the mag compass won't need updating every frame.
I respectfully disagree
I think you would be surprised at how steady some gauges
are when sampled at 30 hz and displayed at the
Norman Vine writes:
Anything that has built in damping, air pressure controlled devices ect,
probably have no need to be sampled at anything greater then 5 hz
unless you are flying thru a tornado :-)
Needles start to look very awkward below 20 fps -- that's one reason I
like FlightGear so
On Fri, 2002-12-20 at 15:18, Norman Vine wrote:
Tony Peden writes:
I think you'll find that once turbulence is introduced, this won't be
true at all. Maintaining straight and level flight in even light
turbulence requires the pilot (or autopilot) to constantly scan the
instruments
On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
David Megginson
It's hard to picture any
situation (other than parked with the engine off) where the main six
and the mag compass won't need updating every frame.
I respectfully disagree
I think you would be surprised at how steady
Thanks to Norman Vine and Curt!
I did not find any stray copies of either SimGear of plib. the only
thing I did different in this update was to remove fgfs from
FlightGear/bin before I did make and make install. The cvs update of
all (plib, SimGear) was done last night and I updated
David Megginson
You can spot a
trend with a needle much faster than you can read an absolute value,
and to fly steady, you really have to work hard to damp out the
movement.
I agree and with my proposal you would see a deflection once
the required 'delta' was reached. I am assuming that
Tony Peden writes:
On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
Anything that has built in damping, air pressure controlled devices ect,
probably have no need to be sampled at anything greater then 5 hz
unless you are flying thru a tornado :-)
This won't be as true for aircraft
On Fri, 2002-12-20 at 19:22, Norman Vine wrote:
Tony Peden writes:
On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
Anything that has built in damping, air pressure controlled devices ect,
probably have no need to be sampled at anything greater then 5 hz
unless you are flying
Tony Peden
No matter how sophisticated the ECS may be, it can only react to changes
in the aircraft state ...
or sensor state :-)
Aside from all that whatever lags or damping may exist should be modeled
by the code for the individual instrument. It shouldn't arise from lack
of sample
I finally get my ISP straightened out and was able to update to CVS again (Ya!).
Unfortunately, I came across a couple of problems. First, the macro GLUT_H does not
seem to be defined anywhere. Where is that suppose to be (I stuck it in the
appropriate config.h)? Second, I got an error in
Jonathan Polley writes:
Second, I got an error in src/ATC/tower.hxx.
typedef list TowerPlaneRec* tower_plane_rec_list_type;
typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator;
typedef list TowerPlaneRec* ::const_iterator tower_plane_rec_list_const_iterator;
generates:
* [EMAIL PROTECTED] (Curt Olson) [2002.12.20 14:43]:
Erik Hofman writes:
I think I should have stated this a little more clear (In this case I
used the Dutch grammar to express an English sentence the wrong way, I
expect this might happen every once in a while in the feature).
To
Norman,
That change worked fine. It uncovered a similar problem in src\ATC\ATCVoice.cxx.
Making a similar change there was not successful.
unsigned char* FGATCVoice::WriteMessage had the following lines:
list string tokenList;
list string ::iterator tokenListItr;
which
There is no visibility culling whatsoever in FG. (other than maybe
back-face). FG depends upon distance culling instead.
I don't think BSP works very well outdoors, anyway :)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
$USERPROFILE on WinNT shold resolve to the root of the users home directory.
$SYSTEMROOT should resolve to the operating system root directory.
If I remember right, there is a portable way to find the my documents
folder. (ie, win9xnt, any language.)
I know the BZFlag project is able to find
How about having a small xml file for each 3d model, telling at what
offset the tip of the nose is?
Then, you could use the same aircraft definition file with a different
3d model without messing around with offsets too much...
--Brandon
___
Cameron Moore writes:
* [EMAIL PROTECTED] (Curt Olson) [2002.12.20 14:43]:
Erik Hofman writes:
I think I should have stated this a little more clear (In this case I
used the Dutch grammar to express an English sentence the wrong way, I
expect this might happen every once in a while
Brandon Bergren writes:
There is no visibility culling whatsoever in FG. (other than maybe
back-face). FG depends upon distance culling instead.
I don't think BSP works very well outdoors, anyway :)
FlightGear uses view frustum culling (and in most cases has back face
culling turned on as
Jonathan Polley writes:
Any more ideas?
maybe
$ cvs diff ATCVoice.cxx
Index: ATCVoice.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/ATC/ATCVoice.cxx,v
retrieving revision 1.2
diff -r1.2 ATCVoice.cxx
Norman Vine wrote:
sample rate will remain exactly the same with my proposed scheme
Actually if the proposed scheme has a higher fps the sample rate will
increase accordingly also
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
* [EMAIL PROTECTED] (Curt Olson) [2002.12.20 22:59]:
Cameron Moore writes:
* [EMAIL PROTECTED] (Curt Olson) [2002.12.20 14:43]:
Erik Hofman writes:
I think I should have stated this a little more clear (In this case I
used the Dutch grammar to express an English sentence the wrong
Gents,
I'm getting the following warning when running ./configure with CVS SimGear
on Cygwin/Win2k:
configure: WARNING: winbase.h: present but cannot be compiled
configure: WARNING: winbase.h: check for missing prerequisite headers?
configure: WARNING: winbase.h: proceeding with the
On Fri, 20 Dec 2002 20:02:51 -0800
Jonathan Polley [EMAIL PROTECTED] wrote:
I finally get my ISP straightened out and was able to update to CVS again
(Ya!). Unfortunately, I came across a couple of problems. First, the macro
GLUT_H does not seem to be defined anywhere. Where is that suppose
53 matches
Mail list logo
