Jonathan Polley wrote:
Oh, and it will not link because of the following missing symbols:
These are symbold from NetworkOLK. Did you rerun autogen.sh and configure?
Erik
BTW. The fixes are in CVS now.
___
Flightgear-devel mailing list
[EMAIL
Jonathan Polley wrote:
Oh, and it will not link because of the following missing symbols:
You will either have to do a make clean or remove the following files
by hand:
Cockpit/hud.o
GUI/gui.o
GUI/gui_funcs.o
Main/main.o
Main/options.o
Main/util.o
Erik
Hello Dev team,
Are there projects using FlightGear as the ``engine'' of a simulator
with cockpit mockup, multiple projectors, head down display and and
possibly a motion platform?
This would imply the need for
- multiple out-the-window views, most likely driven by multiple
rendering machines,
Gerhard Wesp wrote:
Hello Dev team,
Are there projects using FlightGear as the ``engine'' of a simulator
with cockpit mockup, multiple projectors, head down display and and
possibly a motion platform?
http://flightgear.org/Projects/RayChair/raychair.html
http://flightgear.org/Projects/
This would
Erik Hofman writes:
We have three FDM's of which two of them use windtunnel/flight-test
data and one is based on physical dimensions of the aircraft. The
latter is a bit less accurate but is easier to design a working
aircraft for.
To be fair, YASim is not necessarily less accurate,
Hi guys!
I'm implementing light lobes to flightgear using
per-pixel attenuation
I modified viewer.cxx in plib distribution and this
works fine but there are some problems for me here I totally confused model view
matrixes and plib so I need help
If someone intersted in I can send my
David Megginson wrote:
Erik Hofman writes:
We have three FDM's of which two of them use windtunnel/flight-test
data and one is based on physical dimensions of the aircraft. The
latter is a bit less accurate but is easier to design a working
aircraft for.
To be fair, YASim is not
http://flightgear.org/Projects/RayChair/raychair.html
http://flightgear.org/Projects/
Oops. Should have looked more closely on your homepage. Thanks!
We are a bit behind on this part. There is a project called OpenGC that
has been working with FlightGear, but I don't know the current
Yeah, but the windtunnel or flight-test data woudl include the
individual coefficients in one single value. This means that if there is
data for -180 ... +180 degree AOA and Yaw JSBSim (and UIUC) woudl be
more accurate compared to YASim.
That said, YASim is realy a good alternative for most
Gerhard Wesp wrote:
http://flightgear.org/Projects/RayChair/raychair.html
http://flightgear.org/Projects/
Oops. Should have looked more closely on your homepage. Thanks!
We are a bit behind on this part. There is a project called OpenGC that
has been working with FlightGear, but I don't know
Erik Hofman writes:
Yeah, but the windtunnel or flight-test data woudl include the
individual coefficients in one single value. This means that if there is
data for -180 ... +180 degree AOA and Yaw JSBSim (and UIUC) woudl be
more accurate compared to YASim.
Not really, because there
Gerhard Wesp writes:
Does jsbsim also take yaw angle into account (fuselage drag)? I.e., is
it possible to perform a slip (haven't had a real chance to try yet due
to lack of pedals). For yasim I take it it is possible.
Yes. The sideslip angle is called beta, and several coefficients
Jon Berndt writes:
I can think of a couple of situations where YASim would have advantages -
*at*present*:
- Calculating any force or moment that is a result of rotational motion
while the aircraft is at zero translational velocity.
- Clearly, any condition that is not covered by
On Thu, 2003-03-20 at 04:23, Gerhard Wesp wrote:
http://flightgear.org/Projects/RayChair/raychair.html
http://flightgear.org/Projects/
Oops. Should have looked more closely on your homepage. Thanks!
We are a bit behind on this part. There is a project called OpenGC that
has been
On Thu, 2003-03-20 at 03:22, David Megginson wrote:
Erik Hofman writes:
We have three FDM's of which two of them use windtunnel/flight-test
data and one is based on physical dimensions of the aircraft. The
latter is a bit less accurate but is easier to design a working
aircraft for.
On Thu, 2003-03-20 at 04:35, David Megginson wrote:
Jon Berndt writes:
I can think of a couple of situations where YASim would have advantages -
*at*present*:
- Calculating any force or moment that is a result of rotational motion
while the aircraft is at zero translational
Note that JSBSim would get all of this for free simply by allowing
coefficients to be (optionally) specified for individual surfaces,
each with its own orientation. All JSBSim would have to do is sum up
the moments and forces (mostly forces) for the collection of surfaces.
I think we all
Gerhard Wesp wrote:
http://flightgear.org/Projects/RayChair/raychair.html
http://flightgear.org/Projects/
Oops. Should have looked more closely on your homepage. Thanks!
This is actually the first time I've looked at this video, but it is
quite nice to see FlightGear in action this way:
I am working an update to the multiplayer code. The changes are to tidy up
the loading/unloading of models as players come and go, as well as some other
minor corrections. I will post the changes within the next couple of days.
Duncan McCreanor.
___
Duncan McCreanor wrote:
I am working an update to the multiplayer code. The changes are to tidy up
the loading/unloading of models as players come and go, as well as some other
minor corrections. I will post the changes within the next couple of days.
Good to see there is still active
Tony Peden writes:
How would we specify the characteristics of each of those surfaces?
Do you mean the position/orientation, the shape, or the aerodynamic
behaviour?
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
David Culp writes:
I need to at least 31 control nodes in FGControls in order to
handle turbines, and I see that it already contains 72 nodes. I
can see the number growing to 200 or more. It might be time to
organize with sub-nodes:
/controls/flight
/controls/gear
Erik Hofman writes:
1. 3D HUD code, written by Andy Ross and modified by Norman Vine.
I realy like this patch, but it requires aircraft to be repositioned. As
far as I know only the F-16 doesn't use a full-screen HUD, but
I'm not sure.
Does any object or can I go ahead?
Please
David Megginson writes:
The new scenery code is still rough, and some tiles fail to build at
all, but I am extremely impressed with Curt's recent work on TerraGear
combined with the better Canadian elevation data available through the
SRTM.
David,
Thanks for the kind words. Yes there is a
David Megginson writes:
The new scenery code is still rough, and some tiles fail to build at
all, but I am extremely impressed with Curt's recent work on TerraGear
combined with the better Canadian elevation data available through the
SRTM.
Yup Open Source 'collaboration' yields wonders
I just want to make a very brief statement with respect to what going
on in the world right now.
I don't think we should trivialize current world events here in the
FlightGear forums by pretending they aren't happening. I'm certain
that most of us have strong feelings and are very concerned
Jim Wilson writes:
This looks great! Is the bay area ready for the base package yet?
There are a couple open issues.
1. I'm using the 1km raster land use/land cover data set rather than
vmap0 land use.
2. I have yet built in roads, railroads, or streams.
3. There are some tile boundary
Curtis L. Olson writes:
I'm also pretty happy with the quality of the SRTM data. If/when 3 or
1 arcsec terrain data is released for the entire word, I'll need a 1
gazillion terrabyte HD to do all the processing and a 256 node super
computer cluster also wouldn't hurt. :-)
In the
I'm also pretty happy with the quality of the SRTM data. If/when 3 or
1 arcsec terrain data is released for the entire word, I'll need a 1
gazillion terrabyte HD to do all the processing and a 256 node super
computer cluster also wouldn't hurt. :-)
flightgear.distributed.net. :)
g.
David Megginson writes:
In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so
we can join the club.
Really? Where can I fetch it?
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Curtis L. Olson writes:
In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so
we can join the club.
Really? Where can I fetch it?
The same place as the U.S. data:
ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/North_America/3arcsec/
The 1 arcsec data covers only the
Gene Buckle [EMAIL PROTECTED] wrote:
flightgear.distributed.net. :)
If someone provides a portable distribution mechanism for distributed
scenery generation, then I think I can provide some horsepower for this,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends
Curtis L. Olson [EMAIL PROTECTED] wrote:
I'm also pretty happy with the quality of the SRTM data. If/when 3 or
1 arcsec terrain data is released for the entire word, I'll need a 1
gazillion terrabyte HD to do all the processing and a 256 node super
computer cluster also wouldn't hurt. :-)
Martin Spott writes:
Gene Buckle [EMAIL PROTECTED] wrote:
flightgear.distributed.net. :)
If someone provides a portable distribution mechanism for distributed
scenery generation, then I think I can provide some horsepower for this,
The big problem is that scenery building is much more
ok, i am not sure if this is correct but this way compiles cvs version of
Flightgear
--- src/Main/fg_init.cxx2003-03-20 14:33:11.0 +0200
+++ src/Main/fg_init.new.cxx2003-03-20 14:32:58.0 +0200
@@ -740,5 +740,5 @@
SG_LOG( SG_GENERAL, SG_INFO,
Curtis L. Olson [EMAIL PROTECTED] wrote:
For scenery building I'd love to have at least an 8-16 node cluster
with really high bandwidth/ low latency net between them, a terrabyte
of scsi disk space, [...]
A terabyte of disk space is quite affordable these days. When the necessity
becomes
Curtis L. Olson [EMAIL PROTECTED] said:
The big problem is that scenery building is much more slanted towards
data shuffling (i.e. reading and writing files is typically the
largest component of the task.) There is a computational component
but it is generally small in comparison. When you
Locally I have about 220Gb of HD space dedicated towards storing the
original raw data. The intermediate preprocessed form of the data.
The shared edge data. And the final scenery.
Oh. I didn't expect it to be that much...
If we get SRTM data for the whole world, that will have to jump up
I don't know that network-olk ever really worked, so if this new
multiplayer code has any sort of basic functionality we could probably
just remove the olk code. If any one needs it for anything, it will
always be available in past versions.
Regards,
Curt.
We actually did manage to
Martin Spott writes:
Has this project already be mentioned on this list ? Unfortunately it
appears to compile with certain compilers only:
http://www.opensg.org/
I can't say if it's been mentioned here or not, but I'm aware of it.
If people are starting new projects from scratch it
Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand
this does not depend on the tool chain:
make[2]: Wechsel in das Verzeichnis »/usr/local/src/FlightGear/src/Main«
g++ -DPKGLIBDIR=\/usr/local/FlightGear/lib/FlightGear\ -O3 -D_REENTRANT
-L/usr/local/lib -L/opt/gnu/lib -s
Major A writes:
Locally I have about 220Gb of HD space dedicated towards storing the
original raw data. The intermediate preprocessed form of the data.
The shared edge data. And the final scenery.
Oh. I didn't expect it to be that much...
I'm not maxed out yet, and occaisonally I keep
Wolfram Kuss writes:
Excellent answers already!
Dave, you did not say what you want to fly?
Well, so far I have experience only in the C150, C172, C177, and
PA-28. I wouldn't mind adding to that list, but I don't need to do
that in the same trip.
I plan on doing a flight in the UK in
Curtis L. Olson writes:
Martin Spott writes:
Has this project already be mentioned on this list ? Unfortunately it
appears to compile with certain compilers only:
http://www.opensg.org/
In terms of fancy new whiz-bang cool features, OSG tends to try to
track and support them quickly
* [EMAIL PROTECTED] (Curt Olson) [2003.03.20 14:40]:
Martin Spott writes:
Gene Buckle [EMAIL PROTECTED] wrote:
flightgear.distributed.net. :)
If someone provides a portable distribution mechanism for distributed
scenery generation, then I think I can provide some horsepower for this,
Norman Vine wrote:
Erik Hofman writes:
1. 3D HUD code, written by Andy Ross and modified by Norman Vine.
I realy like this patch, but it requires aircraft to be repositioned. As
far as I know only the F-16 doesn't use a full-screen HUD, but
I'm not sure.
Does any object or can I go ahead?
David Megginson writes:
Curtis L. Olson writes:
In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so
we can join the club.
Really? Where can I fetch it?
The same place as the U.S. data:
ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/North_America/3arcsec/
Ironhell3 . wrote:
ok, i am not sure if this is correct but this way compiles cvs version
of Flightgear
Shoot. You are right.
Funny I didn't catch that one.
Thanks.
Erik
--- src/Main/fg_init.cxx2003-03-20 14:33:11.0 +0200
+++ src/Main/fg_init.new.cxx2003-03-20
Martin Spott wrote:
Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand
this does not depend on the tool chain:
Did you already try this:
You will either have to do a make clean or remove the following files by hand:
Cockpit/hud.o
GUI/gui.o
GUI/gui_funcs.o
Main/main.o
Just an idea: how about using the HP TestDrive farm? They have some
nice computers there such as a quad 1GHz Alpha. It would be
necessary to ask for their permission first, but this being an
open-source project, I wouldn't think this would be a problem. We
can then give credit on the
On Thu, 20 Mar 2003 15:34:24 -0600,
Curtis L. Olson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Major A writes:
Locally I have about 220Gb of HD space dedicated towards storing
the original raw data. The intermediate preprocessed form of the
data. The shared edge data. And
On Thu, 20 Mar 2003 16:05:26 -0600,
Cameron Moore [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
PPS - I forget the company, but there's a back-cover ad in the most
recent Linux Journals where you can enter to receive a $50K research
grant by applying in this company's contest. Long
Major A writes:
I've just checked, the central file space is 160GB, which is about 50%
full right now. It's shared via NFS, unfortunately, so it's not that
good really. They still have impressive computing power, I've just
checked that they have a 4x800MHz Itanium and a 4x1GHz Alpha. The
Erik Hofman [EMAIL PROTECTED] writes:
Martin Spott wrote:
Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand
this does not depend on the tool chain:
Did you already try this:
You will either have to do a make clean or remove the following
files by hand:
David wrote:
I plan on doing a flight in the UK in summer as well, probably with a
Tiger Moth. You can do this without any flying license.
Really? In Canada, you need a license even for an ultralight or a
glider.
I probably formulated that very badly - it is like the introductory
flight
Curtis L. Olson writes:
But, to answer your question CPU speed does definitely help.
Generally I'm never memory bound on a 256 machine except for the one
time task of splitting up the world land mass data set into
tiles... it would have been nice to have 1Gb RAM for that.
Note that
Erik Hofman writes:
Norman Vine wrote:
Erik Hofman writes:
1. 3D HUD code, written by Andy Ross and modified by Norman Vine.
I realy like this patch, but it requires aircraft to be repositioned.
As
far as I know only the F-16 doesn't use a full-screen HUD, but
I'm not sure.
Does
Hello Erik,
Erik Hofman [EMAIL PROTECTED] wrote:
Martin Spott wrote:
Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand
this does not depend on the tool chain:
Did you already try this:
You will either have to do a make clean or remove the following files
by
Gene Buckle writes:
After a bit of experimentation, I see little benefit in the 1arcsec
data for our needs. We can't even come any where close to rendering
the full 3arcsec data. We are talking about preserving the top 1%
most important data points from the 3 arcsec data. For the
From: Major A [EMAIL PROTECTED]
Sorry for the lame question, but how far are the sample points apart
from
each other in feet with the 3 arc second data? How far is it for the 1?
24 arc hours = 44000km (roughly the perimeter of the earth)
1 arc hour = 1833km
1 arc minute = 30.55km
1 arc
1 arcsec = approximately 30 meters = approximately 100 feet.
3 arcsec = approximately 90 meters = approximately 300 feet.
The points are on the lat/lon grid lines so the horizontal spacing
becomes smaller as you get further away from the equator.
Ahhh, damn, I should have thought a little
Hmmm, are you sure ?
from my understanding :
360 degres = 44000km
1 degre = 122.22km
1 minute = 2.037km
1 second = 0.033km
That's what I just realized. I think it's bedtime.
Andras
===
Major Andras
e-mail:
Hello Curt,
Curtis L. Olson [EMAIL PROTECTED] wrote:
But, to answer your question CPU speed does definitely help.
Generally I'm never memory bound on a 256 machine except for the one
time task of splitting up the world land mass data set into
tiles... it would have been nice to have 1Gb RAM
Richard Airlie wrote:
I am trying to draw an OpenGL quad at the very end of fgRenderFrame in
main.cxx, just before the glutSwapBuffers by doing:
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadIdentity();
[...]
This has worked on a few occasions, but not all the time.
If
On Thu, 2003-03-20 at 05:30, David Megginson wrote:
Tony Peden writes:
How would we specify the characteristics of each of those surfaces?
Do you mean the position/orientation, the shape, or the aerodynamic
behaviour?
The aero behavior. Coefficients are generally apply only to the
In my case, I don't want any of the multi-pilot code in my build. For
some reason, as of yesterday, src/MultiPlayer is required for the build
(--with-network is defaulted to yes). If it requires that I build with
--with-network-olk then this is a very bad thing (IMHO) because I don't
On Thu, 20 Mar 2003, Curtis L. Olson wrote:
Here are some more pictures taken in and around the Bay area:
http://www.flightgear.org/Gallery/Source/terrain1.jpg
http://www.flightgear.org/Gallery/Source/terrain2.jpg
http://www.flightgear.org/Gallery/Source/terrain3.jpg
On Thu, 20 Mar 2003, Gene Buckle wrote:
I'm also pretty happy with the quality of the SRTM data. If/when 3 or
1 arcsec terrain data is released for the entire word, I'll need a 1
gazillion terrabyte HD to do all the processing and a 256 node super
computer cluster also wouldn't hurt. :-)
On Thu, Mar 20, 2003 at 04:32:57PM -0800, Andy Ross wrote:
If you want to draw into screen space, you'll need to push the
identity matrix onto the *projection* stack as well. Otherwise the
coordinates you are using will end up drawing a 1m x 1m square
parallel to the equatorial plane at the
Frederic Bouvier writes:
from my understanding :
360 degres = 44000km
1 degre = 122.22km
1 minute = 2.037km
1 second = 0.033km
Let's keep it simple. 1 minute of latitude is one nautical mile --
that's its definition.
All the best,
David
--
David Megginson, [EMAIL PROTECTED],
Tony Peden writes:
The aero behavior. Coefficients are generally apply only to the whole
and complete aircraft (with the exception of a tail-off model). This
means its very hard to split them up arbitrarily.
I agree that the information is harder to find, and will require a
fair bit of
On Thu, 20 Mar 2003 21:36:13 -0500,
David Megginson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Frederic Bouvier writes:
from my understanding :
360 degres = 44000km
1 degre = 122.22km
1 minute = 2.037km
1 second = 0.033km
Let's keep it simple. 1 minute of
Sorry for the lame question, but how far are the sample points apart from
each other in feet with the 3 arc second data? How far is it for the 1?
1 arcsec = approximately 30 meters = approximately 100 feet.
3 arcsec = approximately 90 meters = approximately 300 feet.
The points are on
Gene Buckle writes:
Sorry for the lame question, but how far are the sample
points apart from
each other in feet with the 3 arc second data? How far is it
for the 1?
1 arcsec = approximately 30 meters = approximately 100 feet.
3 arcsec = approximately 90 meters = approximately 300
From: Arnt Karlsen [EMAIL PROTECTED]
On Thu, 20 Mar 2003 21:36:13 -0500,
David Megginson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Frederic Bouvier writes:
from my understanding :
360 degres = 44000km
1 degre = 122.22km
1 minute = 2.037km
1 second =
75 matches
Mail list logo
