Hi Guys
I know this has been discussed before but the VOR pointer
seems to malfunction.Sometimes 180 deg to the station sometimes
90deg and sometimes anywhere.
I am using the property radios/nav/radials/actual-deg.
There is a property for the ADF called needle-deg this property
works
Hi Guys
I am in the process of making some 2D panels and am wondering
if it would be possible to do some things.
1 Would it be hard to change the background texture so it is in the
foreground. That way all the instruments the parts like an enlarged
compass rose that would stick out the side and
On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote:
My understanding of systems that impliment these basic ideas is that
step 1) is to give up the idea of seamless, non-blurry textures in the
distance. Every system I have seen blurs the textures excessively as
you go further in the
Innis Cunningham writes:
Hi Guys
I know this has been discussed before but the VOR pointer
seems to malfunction.Sometimes 180 deg to the station sometimes
90deg and sometimes anywhere.
I am using the property radios/nav/radials/actual-deg.
There is a property for the ADF called needle-deg
[EMAIL PROTECTED] writes:
On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote:
My understanding of systems that impliment these basic ideas is that
step 1) is to give up the idea of seamless, non-blurry textures in the
distance. Every system I have seen blurs the textures
Paul Surgeon wrote:
Yeah that's because the scenery is pre-rendered. Who said we have to
pre-render the scenery? :)
Rendering in real time would only require a library of geodata which would be
similar in size to the current FG scenery.
In that case, it wouldn't look like TerraScene scenery --
Curtis L. Olson writes:
Andy Ross writes:
That was my thinking when I started, too. But your math is a little
off. Getting to a worst case resolution of 1 texel per screen-space
pixel with unique texturing requires *vast* amounts of memory.
Yup, I doubt if we get to the 1 texel -
On Tuesday 02 December 2003 13:57, Curtis L. Olson wrote:
[EMAIL PROTECTED] writes:
Couldn't we load the whole data into RAM before?
1 GB Ram are cheap today.
1. Threre is a big difference between having texture data loaded into
main RAM vs. having the texture data loaded into your
Oliver C. wrote:
Couldn't we load the whole data into RAM before?
1 GB Ram are cheap today.
It's not nearly that simple. If you want to draw something on the
screen, it has to get into the video card's memory at some point
during the frame. Even 256MB Übercards are going to thrash* with a
1GB
[EMAIL PROTECTED] writes:
1. Threre is a big difference between having texture data loaded into
main RAM vs. having the texture data loaded into your cards video
RAM. (There are probably a few exceptions, the only one I can
think of at the moment is the sgi O2 which has a
Thanks Curt
Curtis L. Olson writes
Can you report a specific location, heading, frequency, altitude,
etc. where you see a problem?
Everywhere. see below for details
Based on your description of the problem, you might not be aware that
the VOR needle does not point to the VOR station. Instead,
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph library that does the job you need it to
Innis Cunningham writes:
Yes I have got that system working perfectly.But what the list either
does not know or does not understand is that in commercial aviation
and probably many other areas they have what is called a RMI or ADF
VOR guage and on such guages there is two needles one for
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph library that
Thanks Curt
Curtis L. Olson writes
Ok, so this sounds less like a bug report with the current VOR's and
more of a feature request so you can impliment more complex
instrumentation, right?
That is correct
Looking in the code, if I understand your request correctly, you may
want:
Curtis L. Olson wrote:
Looking in the code, if I understand your request correctly, you may
want:
/radios/nav[%d]/radials/actual-deg
No, that is not the right solution. What he needs is a delta between the
inverse of the current VOR radial and the indicated heading on the RMI,
normalized to
Hi David
David Megginson writes
Curtis L. Olson wrote:
Looking in the code, if I understand your request correctly, you may
want:
/radios/nav[%d]/radials/actual-deg
No, that is not the right solution. What he needs is a delta between the
inverse of the current VOR radial and the indicated
On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote:
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph
On Fri, 2003-11-28 at 17:46, Julian Foad wrote:
Matthew Law wrote:
Speaking of which, would it be possible to change the texture above a
certain height AGL? We could have a texture with more detail for low
altitudes and a shinier, more gaussian texture for higher altitudes...
Just
Oliver C. wrote:
Does dumping plib mean that we can choose something like the SDL
library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut
dependency, but I believe that has been removed from current versions.
We can keep the plib parts that we use
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Andy
+++ props.nas 2 Dec 2003 16:25:49 -
@@ -33,10 +33,10 @@
# Static constructor. Accepts a
On 09:56 Tue 02 Dec , Curtis L. Olson wrote:
This is something that has been considered, but it will be a massive
amount of work to do this and preserve all the existing functionality.
Massive might be slightly overstated, but it probably means tearing
everything down and rebuilding it
David Culp writes
Assuming the T-38 in the base package is reasonably current, the VOR needle
works well, as far as I can tell. Make sure you set the radio:
From what I can see on the T38 the only thing that moves without being
adjusted is
the deviation bar.I dont see any pointer moving as
Gene Buckle writes:
I can imagine this would be a complex undertaking, but wouldn't it be the
best solution in the long run?
Sure, and it's on the todo list (or to investigate list) somewhere.
However, there is always a significant time shortage.
If it would be easier, why not just fork plib
On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote:
But when the data is allready in the RAM we wouldn't need
to load the data from the slow hard drive.
Right, but sending that much data across the AGP bus isn't fast
either, especially when you want/need to draw at 60hz. Sure,
[EMAIL PROTECTED] writes:
On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote:
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
From what I can see on the T38 the only thing that moves without being
adjusted is
the deviation bar.I dont see any pointer moving as I fly around a radio
station
Actually, the needle *should* stay still if you fly a circle around a station.
If you fly in some path other than that, then it
[EMAIL PROTECTED] writes:
On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote:
But when the data is allready in the RAM we wouldn't need
to load the data from the slow hard drive.
Right, but sending that much data across the AGP bus isn't fast
either, especially when you
The latest version of TaxiDraw is now up at:
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-w32bin.zip
- Windows Binary (statically linked) [322K]
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-src.tar.gz
- source and makefile for Linux [56K], requires wxGTK-dev.
Summary of
On Tuesday 02 December 2003 18:15, Curtis L. Olson wrote:
Ok, do you know any good documentation and information about this
particular real time rendering topic. That doesn't mean that i will
write such an engine, but i just want to read the basic stuff so
that i know what i am talking
Andy Ross wrote:
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
So, you got me FlightGear crashing every time I use the bo105?
;-)
It's fixed, thanks.
On Tuesday, 2 December 2003 19:15, Curtis L. Olson wrote:
If a person is working on some feature that won't be finished for 2
years, then I think it is reasonable to try to predict card
performance that far out and write to future hardware. In large part,
that is what we did when we started
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.)
Real-time Optimally Adapting Meshes.
--
Russ
Conway's Law: The structure of a system tends to mirror the
structure of the group producing it.
-- Mel
Andy Ross wrote:
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Hmm the problem of Nasal getting into an endless loop still exists. At
first I only
[Heh, this turned out longer than I expected when I started writing...]
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.) There are a lot of
spiffy demos out there. However, there are some non-trivial
Andy Ross [EMAIL PROTECTED] wrote:
Oliver C. wrote:
Does dumping plib mean that we can choose something like the SDL
library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut
dependency, but I believe that has been removed from current versions.
Erik Hofman wrote:
Andy Ross wrote:
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Hmm the problem of Nasal getting into an endless loop still
On Tue, 2003-12-02 at 12:33, David Luff wrote:
The latest version of TaxiDraw is now up at:
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-w32bin.zip
- Windows Binary (statically linked) [322K]
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-src.tar.gz
- source and makefile
Is there any guide to creating scenery models for FlightGear?
What is the max recommended texture size?
I'm using 128x128 pixels (without alpha channel/mask) which means 100 unique
models in a single scene would use less than 5 MB of video memory.
Is each model unit equal to one meter in FG?
* Maik Justus -- Monday 01 December 2003 19:25:
looks good. Maybe someone could add this to the bo105? (Melchior?)
Yes, I had it on my TODO list all the time. But I'll schedule
it for this week. I'm not sure, however, if having both fuselage
=and= rotor shadow will be possible in an acceptable
Simon Hollier writes:
With gcc3.2.2(Redhat 9), I had to rescope t[T]wy_list_iterator to
compile :
Oops, thanks for posting the fix, bit of an embarassing one that!
Another Linux gotcha I've found - Ctrl+L doesn't work to toggle the taxiway
centerlines on or off but grows the taxiways
Melchior FRANZ [EMAIL PROTECTED] said:
* Maik Justus -- Monday 01 December 2003 19:25:
looks good. Maybe someone could add this to the bo105? (Melchior?)
Yes, I had it on my TODO list all the time. But I'll schedule
it for this week. I'm not sure, however, if having both fuselage
=and=
* Jim Wilson -- Tuesday 02 December 2003 22:49:
Just keep the overlap down to about 1 pixel width on the edge and you should
have no trouble. In other words use a crescent shape instead of a disc for
the rotor shadow.
Sorry, but I'm afraid I don't understand. :-)
The effect that I don't know
Paul Surgeon writes:
Is there any guide to creating scenery models for FlightGear?
What is the max recommended texture size?
I'm using 128x128 pixels (without alpha channel/mask) which means 100 unique
models in a single scene would use less than 5 MB of video memory.
I would recommend
On Tuesday 02 December 2003 22:19, Melchior FRANZ wrote:
* Jim Wilson -- Tuesday 02 December 2003 22:49:
Just keep the overlap down to about 1 pixel width on the edge and you
should
have no trouble. In other words use a crescent shape instead of a
disc for
the rotor shadow.
Sorry, but
Paul Surgeon wrote:
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
Probably half, that, actually, since a lot of the trip is over ocean.
All the best,
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
You can buy 320MB of hard disk space for a mere USD 275 (GBP 160) if you shop
around. What sounds OTT
David Megginson writes:
Paul Surgeon wrote:
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
Probably half, that, actually, since a lot of the
Hi,
I have got the netChannel figured (thanks Bernie) out and the server is
accepting multiple
clients. The problem is if a client flightgear program is shut down the
server still tries to send it information and the server crashes. I tried
using netChannel::isConnected() but it returns
Seamus Thomas Carroll writes:
On the client side I thought about using netChannel::close to inform the
server that the socket is closed but the function is never
called. netChannel::close is called in the clients destructor but the
destructor is never called because FGGlobals *globals is
I put a cerr delete globals endl; where you have delete globals;
in the code below and when I exit flightgear delete globals is not
printed. Does the same happen for you?
Seamus
On Tue, 2 Dec 2003, Norman Vine wrote:
Seamus Thomas Carroll writes:
On the client side I thought about
Seamus Thomas Carroll writes:
I put a cerr delete globals endl; where you have delete globals;
in the code below and when I exit flightgear delete globals is not
printed. Does the same happen for you?
oops that what I get for not testing code suggestions
we are exiting from inside the
On Tue, 02 Dec 2003 20:40:51 -0500
Norman Vine [EMAIL PROTECTED] wrote:
Seamus Thomas Carroll writes:
On the client side I thought about using netChannel::close to inform the
server that the socket is closed but the function is never
called. netChannel::close is called in the clients
Melchior FRANZ [EMAIL PROTECTED] said:
* Jim Wilson -- Tuesday 02 December 2003 22:49:
Just keep the overlap down to about 1 pixel width on the edge and you should
have no trouble. In other words use a crescent shape instead of a disc for
the rotor shadow.
Sorry, but I'm afraid I don't
I brought my son to work for a day, and he had a wonderful time.
http://home.comcast.net/~davidculp2/kidsday.jpg
Dave
--
David Culp
davidculp2[at]comcast.net
___
Flightgear-devel mailing list
I'm going to have nightmares, now. :-)
Jon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David Culp
Sent: Tuesday, December 02, 2003 10:14 PM
To: flightgear-devel
Subject: [Flightgear-devel] (OT) Kid's day at work
I brought my son to work for
On Wednesday, 3 December 2003 01:19, Curtis L. Olson wrote:
Right now we just yell at people (semi-randomly) who we think might be
using up too much texture RAM. :-)
I suppose the people who have 64MB video cards start yelling before the ones
with 128MB video cards.
Using sound levels to guide
Paul Surgeon writes:
On Wednesday, 3 December 2003 01:19, Curtis L. Olson wrote:
Right now we just yell at people (semi-randomly) who we think might be
using up too much texture RAM. :-)
I suppose the people who have 64MB video cards start yelling before the ones
with 128MB video cards.
Reminds me of the time I was 4 years old and flying in a Catalina and
Are you serious? I'm jealous. One of my favorites.
went looking for the bathroom, because of course, all airplanes have
bathrooms (something I was very convinced of when I was 4.)
Did it?
Hi David
From: David writes
From what I can see on the T38 the only thing that moves without being
adjusted is
the deviation bar.I dont see any pointer moving as I fly around a radio
station
Actually, the needle *should* stay still if you fly a circle around a
station.
If you fly in some
Found the solution.
When the client is shutdown the server netChannel
still thinks the connection is valid and has a handle != -1. This causes
a SIGPIPE errors on a send or recieve making an assert to fail. To avoid
this problem MSG_NOSIGNAL is passed into the send or recv with this
Hi David
From: David Megginson writes
Innis Cunningham wrote:
Anything I ever saw in 707's thru to 767's looked pretty rock
solid to me. But I may be wrong.
It may have been driven by an FMS in that case, which would be taking input
from INS, LORAN, DME, GPS, etc. What's your experience in
63 matches
Mail list logo
