Roland Häder writes:
On Saturday 10 January 2004 10:33 am, mat churchill wrote:
Worrying times though,
A Google search for publicly available maps revealed this article:
http://www.govexec.com/dailyfed/0901/092501p1.htm
hmm
Big Brother Is Watching Us
FWIW when someone
Melchior FRANZ writes:
* Norman Vine -- Saturday 17 January 2004 13:06:
If you want the latest PLib just grab the nightly tarball
http://plib.sourceforge.net/dist/current.tgz
Does it contain the CVS infrastructure? Then it is certainly an
option. Otherwise not.
Currently it doesn't
Melchior FRANZ writes:
But what does it take to be considered a plib developer?
Requesting on the PLib list to become one is a good start :-)
http://sourceforge.net/project/memberlist.php?group_id=382
Cheers
Norman
___
Flightgear-devel mailing
Christopher S Horler writes:
In the last few weeks only outsiders improved plib, while official
developers mostly played dead. :-P
That's what happens when you don't pay... and when you pay sometimes.
Wait a minute in all fairness
If you go back and review the history of the
Curtis L. Olson writes:
Christopher S Horler wrote:
I don't use many cvs commands, but one I use a fair bit is log. However
I've never figured out how to make it only display the last e.g. 5 log
entries or from a certain date... if it doesn't do it it should...
I don't know if there is
Erik Hofman writes:
I've committed a patch that simply checks whether 'dot' is greater than
1.0 and then prints an error message and set 'dot' to 1.0
Should do the less then case too :-)
if (dot 1) {
SG_LOG( SG_ASTRO, SG_WARN,
Dot product = dot is
Tim Jelliffe writes:
I have a general question regarding the creation of a model.
http://members.optusnet.com.au/~tjelliffe/Learjet55.jpg
Nice :-)
The file size is around 2 Mb, and the frame rate drops from ~20 to ~2 fps.
I have also tried using the demo version of AC3D, and saving
Tim Jelliffe writes:
You can download a time limited version of Rational Reducer
http://www.sim.no/
I had a look at this. However the demo version doesnt let you save anything! Anything
similiar for linux that anyone knows of?
Should find something here
Lee Elliott writes:
On Thursday 22 January 2004 22:54, Curtis L. Olson wrote:
Lee Elliott wrote:
I've been giving quite a bit of thought to look-ahead algorithms for
terrain following. The most straight forward way would be to take a
number of look-ahead samples each frame, and
Lee Elliott writes:
On Friday 23 January 2004 00:34, Norman Vine wrote:
Lee Elliott writes:
I've been giving quite a bit of thought to look-ahead algorithms for
terrain following.
I thnk the fastest way todo this will be to use the Graphics hardware.
i.e. render only
Jon Berndt writes:
FYI there are some neat images and movies posted today on the Mars Rover web
site:
http://marsrovers.jpl.nasa.gov/home/index.html
There is also a new and recent update on the condition of Spirit.
FYI http://www.lyle.org/mars/
Easy access to all images released by
Frederic Bouvier writes:
Christopher S Horler wrote:
I've just spent the last hour looking for a function in the clouds3d
source, I didn't find it.
The 3d cloud is made from cloud particles, each instance of these
particles has a position set with SetPosition(). These look like
David Culp writes:
Thanks, I've been trying to find more sources of Rover news. The usual
sources have been pretty bad (except CSPAN coverage of the Rover team's press
meetings).
comprehensive links page
http://www.marsmissionlinks.com/
All released imagery
pseudo true color images and
David Megginson writes:
Since Blender can use Python scripts for output (it exposes its internal
data structures to Python), a Blender reader/writer should be no harder to
write than a plib reader/writer.
Probably easier :-)
Norman
___
Erik Hofman writes:
Norman Vine wrote:
David Megginson writes:
Since Blender can use Python scripts for output (it exposes its internal
data structures to Python), a Blender reader/writer should be no harder to
write than a plib reader/writer.
Probably easier :-)
It depends
David Megginson writes:
Erik Hofman wrote:
You need version 2.x.x of Python just after you have downloaded
version 1.x.y stable because it was needed by some other package.
I assume you tried finding an updated version of this 'package' or
running your package that required 1.5 with
Curtis L. Olson writes:
I have some really old, as in ancient ventura publishing files that I'd be
interesting at cracking open and at least extracting out the important
stuff in order to convert to some more modern tool.
I'm seeing extensions like .WP and .WS which is probably text in
David Megginson writes:
Thanks for checking. For anyone else who wants the check the host, the best
thing to do is send yourself an e-mail message then view the full headers
(Outlook probably has a menu item for that) --
reading e-mail headers when using OutLook
Curtis L. Olson writes:
Sent: Saturday, January 31, 2004 2:40 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Autopilot update.
Curtis L. Olson
Sent: Saturday, January 31, 2004 1:32 PM
To: FlightGear developers discussions
Subject: [Flightgear-devel] Autopilot
Roy Vegard Ovesen writes:
I get this error when compiling src/Autopilot/route_mgr.cxx:
/usr/include/c++/3.2/limits:942:22: macro min requires 2 arguments, but
only 1 given
In file included from /usr/include/c++/3.2/bits/locale_facets.tcc:43,
sigh
There is a conflict between windows.h
David Megginson writes:
Roy Vegard Ovesen wrote:
No, not more respinsive than possible, but I thought that the damping in
FlightGear _and_ in real world was only for display purposes. So maybe
there would be a possiblility to get the signal before it was damped.
After reading the
Someone interested in Eye Candy might be able to use this technique
http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/R046.pdf
to make much nicer Water and Cloud textures for FGFS
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL
Jim Wilson writes:
What we need is something that looks ahead and makes adjustments based on
future error in order to avoid overruns due to the momentum of the aircraft.
http://baron.flightgear.org/pipermail/flightgear-devel/2003-July/018510.html
http://autopilot.sourceforge.net/kalman.html
Jim Wilson writes:
What we need is something that looks ahead and makes adjustments based on
future error in order to avoid overruns due to the momentum of the aircraft.
this is one approach using the Kalman filter
http://icat-server.mit.edu/Library/Download/102_ICAT-99-5.pdf
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
What we need is something that looks ahead and makes adjustments based on
future error in order to avoid overruns due to the momentum of the
aircraft.
this is one approach using
Jim Wilson writes:
There's no doubt in my mind that PID's will do the job, even for hovering
helicopters. I'm just looking to tweak them a bit.
My guess is that at some point Kalman filters with revolutionize FlightGear's
simulated control systems very much like they have revolutionized
Curtis L. Olson writes:
Norman Vine wrote:
My guess is that at some point Kalman filters with revolutionize FlightGear's
simulated control systems very much like they have revolutionized control
systems in the 'modern' world :-)
Kalman filters are generally for filtering noisy
Jon S Berndt writes:
Is anyone aware of a RAM disk utility or feature under Unix
(specifically, IRIX)? When running a simulation on IRIX we are
finding that the disk access is taking too much time at various phase
boundaries. It is thought that the use of a RAM disk might help.
On
Vivian Meazza writes:
I remain disconcerted that the visual model appears to roll through 180 degs
vertically on the up and down legs of a loop when in chase or helicopter
view. Not the end of the world, but lacking realism.
Yes this is a short coming of the math method used.
Note that the
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Put simply the matrix math used supports a 'restrained' cylindrical viewer
That is a problem, but it isn't the issue here.
There is a singularity in the math model which in effect snaps the orientation
of the model 180* when
Russell Suter writes:
I don't think that's what he means. I took him to mean that the visual
model
origin is translated to the CG every frame. If that's what you mean,
you really
don't want to do that. That's a matrix transform for every vertex in
the model.
This is boils down to
Russell Suter writes:
Jon S Berndt wrote:
I don't see any advantage to your approach.
By your responses, you give me no indication that you even understand
what I'm saying.
I seem to be alone in my dissent anyway... What you are planning will
work just fine.
Russell
You are not
Lee Elliott writes:
On Friday 13 February 2004 22:27, Jon S Berndt wrote:
Any chance of modeling wingtip vortices (when CL is high enough above
some threshhold) and rocket engine exhaust?
Another possiblity would be some sort of particle object handling where
temporary objects could
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Please try to configure your mailer to not quote raw e-mail addresses in
your replies. Let's not make the spam harvesters' life any easier...
Russell Suter writes:
By your responses, you give me no indication that you even
Curtis L. Olson writes:
Tony Peden wrote:
PS. I'm just wondering if you have any thoughts on my earlier question, i.e.
whether what's being patented has to be something non-obvious?
Amazon: One-click ordering.
I think the answer is no.
Even if it's something that has to be
Curtis L. Olson writes:
Norman Vine wrote:
I certainly hope you are not planning on publishing the 'position' as reported
by the FDM for things like collision detection and related instrumentation
such as a radar display with out some kind of 'adjustment'
No-digging-necessary'ly-yr's
Jim Wilson writes:
Norman Vine said:
Thanks for making the mailer fix :-)
I certainly hope you are not planning on publishing the 'position' as reported
by the FDM for things like collision detection and related instrumentation
such as a radar display with out some kind of 'adjustment
Jim Wilson writes:
Russell Suter said:
I suspect these properties are applied anyway -- even if they are zero. I
don't know if these are applied per frame or if they are applied once to
the model. In the latter case, you can ride the toll road all day and only
have to pay the
Norman Vine wrote:
Jim Wilson writes:
Exactly.
From sgLoad3DModel (in SimGear/simgear/scene/model.cxx):
Yup, something like that is how it's supposed to work but ...
I remember your asking about how to set this up and that you didn't like
the axis angle form that we were using
Curtis L. Olson writes:
Honest, I'm not writing a windows virus here. :-)
I am working on an fltk app to make it easier to install / uninstall 10x10
.tar.gz scenery chunks. I have the install part mostly working (via libtar
/ libz) so now I am looking at uninstalling.
For unix I can
Norman Vine wrote:
Curtis L. Olson writes:
I forgot to point out the necessay nonstandard Windows headers though
#include io.h
_unlink( const char * )
#include direct.h
_rmdir( const char * )
Norman
___
Flightgear-devel mailing list
[EMAIL
Mathias Fröhlich wwrites:
On Sonntag, 15. Februar 2004 10:49, Erik Hofman wrote:
Jon Berndt wrote:
I give up. Sort of.
I hope you don't!
No need to IMHO. I think we now have an excellent solution.
Could someone file a patent request for this?
There are some gotcha's involved which
Mathias Fröhlich writes:
Norman Vine wrote:
Also I can not find in the code the mechanism that will rotate the AirCraft
about any point other then the point returned by
Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP
which appears to be set at Model load time
Jon Berndt writes:
Could this be solved if the camera viewpoint looked at the CG instead of
the VRP? What is being done, now?
The camera viewpoint need not necessarily be either or any fixed point
i.e. the camera should be free to look around :-)
What is required is that the 'center of
Mathias Fröhlich writes:
What you need to report to flightgear is the orientation and position of the
visual reference frame relative to the earth fixed frame (lat/lon/h +
angles).
Agreed
And all required 'corrections' that the model does not rotate around the nose
but around the dynamic
Russell Suter writes:
The IG shouldn't be used to position the 3D model. If it being used,
that's wrong.
By IG I am assuming you mean Image Generator, and you have to
understand how the things are drawn or else you are bound to get
surprised at least occassionally :-)
Cheers
Norman
Jim Wilson writes:
Norman Vine said:
Here is where I get confused and ... I am probably missing the obvious but
See 3. Ummm...think about how rotation in 3D space really works for a minute.
Easier to just wait for all this to get coded up and then see it live on the monitor
Russell Suter writes:
Norman Vine wrote:
Simply stated the problem is that inorder to rotate an object about an arbritrary
point you *must* do the equivalaent of the following
1) translate object so that it's 'rotation point' is at the 'point of rotation'
2) rotate the object
3
Jim Wilson writes:
David Megginson said:
Roy Vegard Ovesen wrote:
The GPS instrument does this in the same way as you suggest (as do most
real gps devices), take a look at the gps.cxx source file to see the
details. I believe the actual formula can be found someplace in
Hmm...
DLists use to work...
Try the untested patch below
Also looking at leaf.cxx
there appears that a duplicate statement has snuck in
norman
$ cvs diff obj.cxx
Index: obj.cxx
===
RCS file:
Jim Wilson writes:
Probably best to do a running average of the FDM value too so as
to 'smooth' it a little
Hmmm...yeah that is pretty heavy.
Actually the geodetic method being used isn't very smooth either. In fact I
would guess that since the lon/lat is the direct result of the
Erik Hofman writes:
http://www.dinkumware.com/conform_c.html
Hmm.. that document is not really upto date
at least with respect to MingW32
as there are many changes well over a year old that
correct some of the 'deficiencies' reported
note some of the things reported still hold though
David Megginson writes:
Jim Wilson wrote:
I wonder if this could be incorporated (or interfaced) to the current waypoint
management code. And, for the pilots on the list, do some GPS units also
calculate elevations to plug in for VNAV operation, fuel estimation, etc?
Every GPS I've
David Megginson writes:
Norman Vine wrote:
This is because GPS positioning is *NOT* acurate with out a ground based
signal to augment it !
It's much better than it used to be before they turned off selective
availability.
Yes this makes a difference but DGPS or WAAS is *MUCH
Erik Hofman writes:
David Megginson wrote:
Erik Hofman wrote:
Sounds good, implement first, optimize later.
The standard Unix developer's rules (from memory):
1. Make it work.
2. Make it right.
3. Make it efficient.
I've worked as a consultant on too many projects where
Curtis L. Olson writes:
David Megginson wrote:
Curtis L. Olson wrote:
A simple list of id's of metar stations. We can use this list to mark
which airports have corresponding metar data so we don't flood the
noaa site
with bogus queries.
It might be a good idea actually to
Melchior FRANZ writes:
* Curtis L. Olson -- Monday 23 February 2004 18:27:
Any one know where we can get current and definitive information?
Here is a list of weather stations with ICAO ids. But it's not obvious
if all of these do also provide metar reports:
Lee Elliott writes:
On Monday 23 February 2004 14:16, Norman Vine wrote:
What I was pointing out is that elevation from GPS even DGPS is by it's
physical nature mathematically not as accurate as the horizontal position.
One of the things about GPS units is that the accuracy depends
Martin Spott writes:
Erik Hofman wrote:
Too often companies don't really understand the power of
Freeware/Open-Source software. If they don;t like the way the netFDM
structure is maintained it is easy to create a network protocol for
FlightGear that suits their needs.
Please
Roy Vegard Ovesen writes:
I'm making an EFIS instrument, but I'm having trouble with a long
pitchladder texture. It's a long texture that contain the entire
pitchladder from -90 to 90 degrees. My problem is that it enxtends beyond
the instrument:
Erik Hofman writes:
Roy Vegard Ovesen wrote:
Basically you would move the texture offsets rather than the surface
itself.
Is this possible with 2D instruments too?
Sure it is jsut OpenGL underneath
I don't think so. About everybody want the 2D instruments gone ...
There will
Erik Hofman writes:
Norman Vine wrote:
I don't think so. About everybody want the 2D instruments gone ...
There will always be a place for a 2D instrument panels
For Instructor panels and as the texture for flat 3D panels
No need the 2D panel code for both of them. I'm not sure why
David Megginson writes:
Fixing #2 (mouse actions)
will be a bit harder -- it's quite doable in plib (PrettyPoly did it), but
no one has been able to give me any practical information on how to
accomplish it, besides pointing me to entirely unhelpful code fragments in
plib and ppe.
I noticed that these have been recently updated
http://www.ati.com/support/drivers/linux/radeon-linux.html
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jonathan Polley writes:
Plasma TVs tend to be 1280x1024 at a 16:9 aspect ratio, rather than
the 4:3 (or 1:1) that it would normally expect. I am assuming that I
can just adjust the field of view, but will that only adjust the
horizontal field or will it adjust the vertical as well?
Jon Berndt writes:
Are there any reasons to choose one method over the other in the declaration
of local variables that are used each frame?
Here are some examples. Note that this hypothetical routine would be called
each pass through the EOM (for example):
following use local
David Megginson writes:
Andy Ross wrote:
Honestly, I think you might be fooling yourself on the 2D/3D
performance issues. There's no secret sauce in ssg that makes it
faster; my guess is that the existing 3D cockpits are faster than the
2D ones because they use fewer and smaller
David Megginson writes:
Norman Vine wrote:
My not so WAG is that the newer code draws MUCH less then the old approach.
i.e. All of the 2D Panel was drawn as was all of the scenery that it obscured.
In the new approach SSG is clipping those instruments not seen and the occluded
Jim Wilson writes:
Currently it is
possible to control all aspects of the camera position and angle through the
property tree (in the /sim/current-view path),
I see 'heading' and 'pitch' but not 'roll'.
I guess I must be missing something ?
Best
Norman
Jim Wilson writes:
Norman Vine said:
Jim Wilson writes:
Currently it is
possible to control all aspects of the camera position and angle through the
property tree (in the /sim/current-view path),
I see 'heading' and 'pitch' but not 'roll'.
I guess I must be missing
Orthonormalize writes:
does anyone know why i can't compile the following program?
for some reason gcc doesn't like plib/ul.h.
$ cat test.c
#include plib/ul.h
int main()
{
return 1;
}
$ gcc -I/cygdrive/c/cygwin/usr/include test.c
PLib is a c++ library and gcc doesn't know that,
Erik Hofman writes:
Frederic BOUVIER wrote:
Erik Hofman wrote:
Modified Files:
glut_shapes.c glut_shapes.h
Log Message:
Further refinement of the Cygwin problem as suggested by Frederic.
Well, I had the impression that the code was originally good but the
configure step was
Norman Vine wrote:
so something like
#if defined(__CYGWIN__) # !defined(USING_X)
#define WIN32
#endif
#if defined(WIN32) # MINGW and MSC predefine WIN32
# include windows.h
#endif
HTH
Arrgh ... of course I meant something like
#if defined(__CYGWIN__) /* !defined(USING_X
Jim Wilson writes:
Norman Vine said:
Jim Wilson writes:
snip
Oops...that is a bug. The interface is there, at least partly...something is
missing though. I think with the mouse and keyboard manipulation we're only
using two of the axes which might explain why that one snuck
Erik Hofman writes:
Norman Vine wrote:
This is still wrong windows.h needs to be included *before* gl.h
inorder for the the WINDOWS GL extensions and not the GLX extensions
to be recognized
How do you explain that the extensions code does work this way.
If it works
Erik Hofman writes:
Norman Vine wrote:
If it works then it is getting WIN32 predefined from someplace other
then the compiler itself which will break a Cygwin compilation for
GLX X windows OpenGL which is a separate issue
AFAIK the *only* Windows compiler that does not #define
Curtis L. Olson writes:
2. We have a *lot* of aircraft in the base package.
I suggest we limit the base package to 2 or 3 aircraft at most
IMHO better if this is only 1 aircraft though and have a supplemental
aircraft package(s) for the rest
Note I am concerned about the size of the
HTH
Norman
$ cvs diff -u configure.ac
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.57
diff -u -r1.57 configure.ac
--- a/configure.ac 16 Mar 2004 20:19:07 - 1.57
Jonathan Polley writes:
That seemed to fix my problem. Off to finish the build.
Great :-)
Attached find complete file for easier inclusion into the CVS
Cheers
Norman
On Wednesday, March 17, 2004, at 11:30AM, Norman Vine wrote:
$ cvs diff -u extensions.hxx 21 | tee diffs
Erik Hofman writes:
Seamus Thomas Carroll wrote:
Does anyone know of a way to save the glbuffer as a jpeg? Currently the
images are saved as a ppm but this requires a lot of space. A hint on
what library to use might be enough for me to figure out the rest.
There is already a
Steve Baker writes:
Fay John F Contr AAC/WMG wrote:
Absolutely! My comments were based on what I downloaded this morning as
last night's tarball ... but I will take your word for it that they are
fixed.
The only thing I'm not sure about is the MacOSX joystick code. But if
that's
FYI
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steve Baker
Sent: Saturday, March 20, 2004 1:51 AM
To: [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Plib-users] ANNOUNCING PLIB Version 1.8.0
ANNOUNCINGE PLIB Version 1.8.0
Athanasios Mantes writes:
Martin Spott wrote:
Martin Dressler wrote:
So I am asking for a way, or technique so as when rendering an object
after another, to avoid rendering the part of the object that is
vertically (same x,z coords) covered by the previous object, so as to
avoid
Frederic BOUVIER writes:
Vivian Meazza wrote:
Frederic BOUVIER wrote
Vivian Meazza wrote:
So to make it short, it seems to work ok. What this change does
not address yet is the fact that we can see the ground over
overcast layer through the exhaust beam of the
Curtis L. Olson writes:
I'm seeing a last minute flurry of people trying to get final model
tweaks into the base package (which is good--great work guys![1]), but
haven't heard any other complaints about the pre2 release. Are we
getting pretty close to making this release official so we
Andy Ross writes:
Alex Perry wrote:
[...]
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so:
undefined reference to `glXChannelRectSGIX'
[...]
Never mind. It looks like Debian Testing has managed to temporarily
have insufficient dependency constraints. It is currently
Arnt Karlsen writes:
Norman Vine wrote:
Please configure your email program so as not to
include email addresses in replies.
AFAIK a PLIB maintenance release is imminent
..plib-1.8.2?
Yes
Norman
___
Flightgear-devel mailing list
[EMAIL
Jim Wilson writes:
Jon Berndt said:
David Megginson wrote:
I agree with Curt. There are two basic strategies for releasing:
2. Release often, testing every release only lightly.
I think that #2 works better for most cases
One way of looking at it is this: The goal isn't
Andy Ross writes:
Does anyone understand what is going on in src/Input/mouse.cxx
AFAIK mouse.cxx is not in the current CVS
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Andy Ross writes:
Does anyone understand what is going on in src/Input/mouse.cxx with
the {X|WIN32}_CURSOR_TWEAKS preprocessor defines? I'm having a hard
time figuring this out. Right now, it looks like the windows and X11
builds actually have different/incompatible behavior for the mouse
Martin Spott writes:
An outsider's view: Wouldn't it make sense to roll all these nifty
hacks into PLIB so everyone can make use of them or is PLIB too
restricted to make this a realistic vision ?
AFAIK - PLIB is already OS and Windowing system agnostic
If it wasn't Andy wouldn't have been
Jon S Berndt writes:
Two general application / programming / automation questions:
1) Image conversion
Is ayone aware of a program that does on-the-fly image conversion that
will run under Cygwin from the command line?
There are many :-)
ImageMagick is available via the Cygwin setup
Andy Ross writes:
OK, I've just commited the hard part of deglutification. All glut
dependencies in the source tree are now isolated in Main/fg_os.cxx.
This file (header attached) defines a really tiny wrapper API around
the subset of glut we actually use. Think of it as yet another OS
Jon Berndt writes:
ImageMagick works great. I batch-converted my .pcd files to .png. It's got
lots of features. Very nice application. Is this the one you used to do the
lyle.org Mars stuff?
both of these sites are automated by just a few lines of Python
http://www.lyle.org/mars/
Curtis L. Olson writes:
Andy Ross wrote:
Norman Vine wrote:
I see that you removed gamemode support :-(
This means that Windows users only have 'slow' windowed
mode available now. :-(
Is game mode support actually configurable? I looked around, and
couldn't find
Norman Vine wrote:
FYI the snippet below which I have posted before seems to work nicely
for toggling btween an un-decorated fullscreen window and a decorated
one and should be easy enough to port to the 'new' OS methodology
untested but I think this will work as an alternative to game-mode
FYI
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert Osfield
Sent: Thursday, April 01, 2004 4:50 PM
To: [EMAIL PROTECTED]
Subject: [osg-user]Handling whole earth databases
Hi All,
As I write this, my other machine is churning away
Erik Hofman writes:
Oliver C. wrote:
The Alt+Tab key kombination is also generally used for Window Manager/Desktop
Environment specific things.
KDE uses Alt+Tab for example to switch beween Applications, but you can't
switch the Application from a fullscreen mode into a real Desktop
Jon S Berndt writes:
1) Is anyone aware of a database of the lunar surface exists that
FlightGear could use?
Clementine perhaps ?
http://pds-geosciences.wustl.edu/missions/clementine/gravtopo.html
Norman
___
Flightgear-devel mailing list
[EMAIL
Andy Ross writes:
Is SDL something we want to commit to?
FWIW - I don't see what this gets us but .
since we are now agnostic as pertains to the lowlevel
OpenGL initialization routines I don't see why the choice
of OpenGL toolkit used couldn't just be an option
i.e. since all of the
901 - 1000 of 1238 matches
Mail list logo
