FYI
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Sriram
Rallabhandi
Sent: Wednesday, December 07, 2005 5:53 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [gts-general] New Project Annoucement - TriAero
All,
I am pleased to announce
Steve Hosgood writes:
Makes me wonder whether there's an excuse for some new thinking on the
subject of UI design, regardless of whether a cockpit is 3D or 2D.
Here's what I propose - please be kind with your comments, I'm not
trying to dictate terms or tread on anyone's toes:
Flightgear
Jon Berndt writes:
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box.
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm
trying to get
some answers out of the card and driver manufacturer, but if anyone here has
any
Steve Hosgood writes:
Agreed, but if we've got a better scheme, why keep the dialog boxes?
Every disjoint aspect to the GUI is just another thing waiting to go
wrong, as with the Cessna autopilot where the dialog box is invisibly
disconnected from the real autopilot.
Steve
Apparently I
Mathias Fröhlich writes:
On Samstag 05 November 2005 17:21, Vassilii Khachaturov wrote:
With either jsbsim or yasim aircraft, when is in the vicinity of the
(North) pole, the AGL (as seen in the HUD) goes into 2*10^7 ranges. You
can either start up with --lat=90 (and any longtitude you
Melchior FRANZ wrote:
I thought it might be advisable to make Ctrl-q the key for exiting
from fgfs (like it's standard in almost all GUI apps I know), and Esc
the key for canceling/dismissing/closing dialogs.
Alt-F4 is the key used for the this on the *vast* majority of programs :-)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dave Culp
Sent: Sunday, October 30, 2005 7:55 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] wish list for next release
Ow, that I'm not sure of.
I guess it would be
Erik Hofman
David Luff wrote:
Fair point. Do you know if HUGE is part of a standard anywhere that
definately should be supplied by Cygwin, or is it simply available from
everyone else by unwritten convention?
According to the IRIX header file it would be an ANSI definition.
IRIX
Erik Hofman writes:
Martin Spott wrote:
So: However somebody is going to design a new airports description
format we always should have a method to merge Robin's updates.
Additionally we need someone who tracks these updates on a regular
basis because we don't want to loose a nifty
Erik Hofman writes:
Martin Spott wrote:
Additionally we need junctions if the plan should make sense. Junctions
like this one:
When carefully designed this could be done with the quad approach
(although it would not be easy). So the data should be quad based.
It is up to the
The problem is I need to change the font that is showing on my HUD
to make it larger (and brighter). I cannot figure out where this is done.
It seems to refer back to properties in some way, but I can't find where
the lever is. If I change the sizes in the programs in Cockpit, nothing
Jon Berndt writes:
I'll likely be relatively sparse on the Internet for the next week or so -
perhaps much,
much longer depending on how things go in League City, due to Rita. I'm about
14 feet
above sea level, about a mile inland from Galveston Bay.
Anyone else look like they're
Martin Spott wrote:
Does osgPlanet allow for contour lines for elevation data instead of
DEM's ?
No
FYI osgPlanet questions better asked on the OSSIM list.
http://mailman.remotesensing.org/mailman/listinfo/ossim
___
Flightgear-devel mailing
You should find everything you need to replace the objectional
code here
http://www.stjarnhimlen.se/comp/sunriset.c
/* +++Date last modified: 05-Jul-1997 */
/*
SUNRISET.C - computes Sun rise/set times, start/end of twilight, and
the length of the day at any date and latitude
Curtis L. Olson writes:
If it helps motivate someone, he might be able to come up with a small
amount of $$$ to do the job, but in this case, if he's spending his own
money, he wants to own the result.
soap box
I suggest mentioning the Free as in beer analogy might get
the itch solved more
Melchior FRANZ writes:
* Patrick Quirk -- Wednesday 06 July 2005 21:50:
In file Main/viewer.cxx, in function MakeVIEW_OFFSET(...), on line ~118
where the third matrix is being made, there is the following line:
[...]
Since this is making the third matrix from the third angle, shouldn't
Martin Spott writes:
Ralf Gerlich wrote:
I don't see why we need to store elevation data for the whole world in
the database anyway. I wouldn't think elevation data would be a typical
subject for user-submitted modifications related to wide areas. If more
detailed structures are
Ralf Gerlich writes:
My point was that we don't have to store the DEM data in raster format.
As long as there is no PostGIS support for raster data, we either need
to store the raster data outside of PostGIS or store it as vector data
such as contours.
I agree you don't have to but there
Ralf Gerlich writes:
Hello,
Martin Spott schrieb:
[SNIP]
Actually, I _do_ agree that having preprocessed scenery
_is_ an advantage. But it does have disadvantages as well:
1.) At the current state it appears (to me) nearly impossible to inject
user-contributed additions into
Martin Spott writes:
By definition you can transform the current VMAP0 data, which comes in
the so called VPF format, into shapefiles. In order to achieve this you
need OGR and the OGDI VPF driver (Norman, please correct me if I'm
wrong).
The same set of tool scan be used to go directly to
Martin Spott writes:
Norman Vine wrote:
Because it has only recently been released see
http://radar.oreilly.com/archives/2005/06/os_gis_conferen.html
Yep, I talked to Jan-Oliver Wagner who attended your presentation and
was deeply impressed ;-)
It is a neat 'toy' (1) and should run
Harald JOHNSEN writes:
Apparently there is no stencil in 16 bpp mode.
Can someone check if there is an alpha channel in 16bpp mode and how
many bits in it ?
There is a 5 5 5 1 where 5 bits per color and one bit alpha mode
GL_RGB5_A1
#define GL_UNSIGNED_SHORT_5_5_5_1 0x8034
Erik Hofman writes:
Are you calling readXML while another call to readXML is in progress?
Can't be done unless this other call is in a different thread :-)
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
I have placed a compiled tarball of yesterdays OpenAL CVS files @
http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz
you might want to test these against the current FGFS before
blindly overwriting your currrent installation
Norman
___
Vivian Meazza writes:
Jon Berndt wrote:
I'm finally getting around to reinstalling FlightGear after a hard drive
crash a couple
months ago. I have this as a place to get OpenAL for Cygwin:
http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz
Is this still the latest/best
Erik Hofman writes:
bass pumped wrote:
Well, I submitted it. Alas, it didn't go well. You can follow the
flame war here:
http://cygwin.com/ml/cygwin/2005-05/threads.html#01305
I just read that... that guy certainly has a problem!!!
Tell me about it, I've worked with such an
Vivian Meazza writes:
Andy Ross wrote:
Erik Hofman wrote:
Norman Vine wrote:
FWIW I think these apply here
http://www.catb.org/~esr/faqs/smart-questions.html#id3001405
http://www.catb.org/~esr/faqs/smart-questions.html#keepcool
These two contradict (You can't offend
Martin Spott writes:
Richard Bytheway wrote:
Would it be possible to have a compiled form stroed on disk, which is
automatically regenerated on startup of FGFS based on rules similar
to make. If the ASCII version is newer than the compiled version,
rebuild the compiled version.
Martin Spott writes:
Norman Vine wrote:
Just use the source Luke :-)
Yes, I do right on the track to figure how much effort it would
be to 'port' CWXML to IRIX/MIPSpro. Apparently they rely on having GCC
as compiler on _every_ supported Unix platform.
You mean gcc isn't
Andy Ross writes:
Here's another startup speed patch (against plib this time) for
windows users to try.
Nice one Andy :-)
Anyway, let me know if this produces any appreciable speedup under
windows, and we can start the, ahem, bureacratic process of getting
this into plib. :)
submit
On Thursday 26 May 2005 22:48, Andy Ross wrote:
Attached is a patch that pre-reads the directory contents ahead of
time (currently that is a list of length zero) to avoid having to hit
the kernel (twice!) for every airport.
Under Linux, this doesn't provide much speedup. But Windows
Gerard ROBIN writes:
Durk Talsma wrote:
Another issue that has been brought up a number of times is the ascii vs
binary file format disussion. While I absolutely believe that ascii/xml
files
are ideal for development work, combined they may have a pretty big impact
on
Vivian Meazza writes:
Drew wrote
FlightGear takes nearly a minute to start up from my Windows build,
and I'm just wondering if there's an easy way to shorten this if I'm
not using all of flightgear's features. Is there one particular task
that takes particularly long?
Only a
* Drew -- Tuesday 24 May 2005 07:54:
FlightGear takes nearly a minute to start up from my Windows build,
and I'm just wondering if there's an easy way to shorten this if I'm
not using all of flightgear's features. Is there one particular task
that takes particularly long?
Because
BONNEVILLE David writes:
That is the problem ;-)
I am diving into SG code, but if Norman or somebody helped by Norman know
where
i could find it, feel free to post a maessage :D
I haven't kept current with the code but AFAIK the elevation routines
live in FGFS / src / scenery /
Jim Wilson writes:
I think the real issue is that SimGear shouldn't be installed anywhere ever,
because it isn't a shared library (and
doesn't need to be). It seems like it should be possible to fix the fgfs
build setup so that it just links libraries
right from the SimGear build
Erik Hofman writes:
Another thing is that it seems to depend on glut functions which need to
be resolved for SDL users also.
Hmm... a quick grep of the directory yields
f:\tmp\fgfs\SimGear\simgear\scene\sky\bbcache.cxx: #include SG_GLUT_H
Not sure if I have pointed this out before or not
http://www.cert.fr/CERTI/
Currently Unix only but HLA would make a great addition
to FGFS
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross writes:
Vivian Meazza wrote:
I used the power form because it is easier to read, but if the other
form produces a performance advantage, then of course we must use
it.
It's actually not so much about performance, really. Readability can
mean different things. The problem
Curtis L. Olson writes:
Hmmm, I wonder if this is a way to hide the cursor so it doesn't
appear in the screen shots?
Bingo !
Cheers
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Vivian Meazza writes:
Andy Ross wrote:
Vivian Meazza wrote:
I have the same problem with Main/renderer.cxx. Your solution (or
one very like it) solves the problem. I guess near/far are reserved
words in Cygwin?
Goodness, that brings back memories. The near and far keywords are
and account for this. Again I point
out the
myriad of image formats that demonstrate that you can successfully pass
structures over the Net.
Cheers
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Norman
Vine
Sent: Sunday, March 27, 2005 9:29 AM
Frederic Bouvier writes:
Quoting Andy Ross:
* Hopefully in a CPU-friendly way. I know that older versions of
the NVidia drivers did this by spinning in a polling loop
inside the driver. I'm not sure if this has been fixed or not.
From my experience, the latest non-beta Windows
Curtis L. Olson writes:
First let me explain what I need to do. I need to configure an
asymmetric view frustum.
..
For what it's worth, I think the same issue is happening with the TR
tiled rendering routines that generate the ultra-highres tiled screen
shots ... that code
-Original Message-
From: Ben Discoe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 4:58 PM
To: [EMAIL PROTECTED]
Subject: [vtp] FW: Announce: Forum on Open Geodata, London, April 14th
I'm forwarded this announcement for those of you in the UK who are not on
the
Geoff Air writes:
I use msvc7, in XP, cygwin not installed, so also do not
use pthreads ...
FYI you do not need Cygwin to run with pthreads on Windows
see
http://sources.redhat.com/pthreads-win32/
Norman
___
Flightgear-devel mailing list
Frederic Bouvier writes:
John Wojnaroski wrote:
Started building a CVS version and bombed out in Simgear with the
following:
RenderTexture.cpp: In method `RenderTexture::Render
RenderTexture.cpp:151: `GLX_RENDER_TYPE_SGIX' undec
RenderTexture.cpp:1774: `GLX_SGIX_pbuffer'
Giles Robertson writes:
In case anyone's interested, I have at times had to add -lwsock32 to
LIBS to get some compiles working under mingw (with network programs).
I forget if that's currently the case for FlightGear.
please use '-lws2_32' it is a better library
Vivian Meazza writes:
Now Flightgear won't compile - stops as following:
/usr/lib/gcc-lib/i686-pc-
cygwin/3.3.3/../../../libplibjs.a(jsWindows.o)(.tex
t+0
5c9):jsWindows.cxx: undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
make[2]: ***
Vivian Meazza writes:
I'm having a problem compiling Simgear-cvs under Cygwin. The compiler stops
with the following error:
In file included from soundmgr_openal.hxx:50,
from xmlsound.hxx:40,
from xmlsound.cxx:38:
/usr/local/include/AL/alc.h:39: error:
: Wednesday, February 02, 2005 5:55 AM
To: 'FlightGear developers discussions'
Subject: RE: [Flightgear-devel] Simgear-cvs
Norman Vine wrote
Vivian Meazza writes:
I'm having a problem compiling Simgear-cvs under Cygwin. The compiler
stops
with the following error:
In file
Jim Wilson writes:
Norman Vine said:
Jim Wilson writes:
As far as the reason the existing alpha-blend code doesn't work may be
related
to an update in 1.8.4 that was described in ChangeLog as smaller and
cleaner
scene graphs. That's just a WAG, but it seems
Jim Wilson writes:
As far as the reason the existing alpha-blend code doesn't work may be related
to an update in 1.8.4 that was described in ChangeLog as smaller and cleaner
scene graphs. That's just a WAG, but it seems that this function would be
better accomplished through an API
Manuel Massing writes:
It could be worthwhile looking into if we need to store large images.
The SDK with source code is available at http://www.ermapper.com
The terrain engine also supports the jasper JPEG2000 library. Unfortunately,
the last time I tested, JPEG2000 decoding performed
Geoff Air writes:
Those who 'regularly' use system.fgfsrc, like I do,
to control each run of FG, and use 'panel-less'
aircraft, like ufo, have probably been 'adding' this
patch to fg_init for 'years' ;=))
Oooh it is not just me then who doesn't just 'use'
all the eye candy :-)
Cheers
Erik Hofman wrote:
The code to draw
untextured terrain has been removed some time ago.
Saddly :-(
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman
Sent: Friday, January 28, 2005 3:58 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Runway lighting
Ampere K. Hardraade wrote:
How about not rendering ground
Robicd writes:
I've found Geotrans Translator v.2.2.5 software; I tried using it for
converting from WGS84/NUTM33 to WGS84/Geodetic coordinates and I had
some not very good results.
I don't know if I am making something wrong with that software or the
starting coordinates are not
Andy Ross writes:
You're right, the picture shows a Projection field too. Complete infos are:
Datum: WGS84
Projection: NUTM33
Coordinate top left
x: 353620.2 y: 4225543.6
Coordinate bottom right
x: 354212.2 y: 4225976.1
Those are odd looking numbers.
These are UTM
Curtis L. Olson writes:
The terrain elevation system could stand to be looked at a bit. I think
there is still a lurking bug where the wrong elevation can be returned
under some circumstances immediately after a tile boundary is crossed.
There are some optimizations in the current
Durk Talsma writes:
What I am really looking for is a hint where I can find the code in
FlightGear
that actually does these calculations. I tried tracing back through the
functions that eventually set the value of
the /environment/ground-elevation-m property, but couldn't really figure
Erik Hofman writes:
Paul Surgeon wrote:
Can someone comment on how FLTK works under OpenGL?
Would it be possible to use FLTK and all it's nice widgets in FG and drop
the
rather crude PUI toolkit?
To be honest, I did some small first steps in developing using fltk
recently and
Curtis L. Olson writes:
Stewart Andreason wrote:
Jim Wilson wrote:
There are a couple bugs or at least they were there a week or so
ago. One is
just a mapping typo where latitude goes into both latitude and
altitude. The
other is under linux the fg-root and fg-scenery
Curtis L. Olson writes:
This is kind of off today's topic, but I have an unrelated question.
Working in 2d space, given 3 points, I know how to compute a circle
(center/radius) that passes through those three points. Now I need to
compute the direction of curvature of the 3 points. In
maybe something like
static void fgIdleFunction ( void ) {
// printf(idle state == %d\n, idle_state);
if ( idle_state == 0 ) {
// Initialize the splash screen right away
if ( fgGetBool(/sim/startup/splash-screen) ) {
Martin Spott writes:
Martin Spott wrote:
The tools to not only import VMAP0 data but GSHHS shorelines as well
into a PostGIS database are already present. I think you also can use
these tools to export back into VMAP0 or any other format.
BTW, does anyone know which sort of agreement
Martin Spott writes:
Norman Vine wrote:
PostGIS can be used to serve a WFS or WCS that is built on top
of the UMN Mapserver which will handle 'z' values just fine.
Right, but this doesn't picture all the required features in this case.
If we would erect a repository for manual scenery
Paul Surgeon writes:
On Wednesday, 12 January 2005 10:29, Martin Spott wrote:
One other possibility you might wanna consider is allowing uploads/
dloads of terrain (e.g. tiles modified through fgsd).
This is not as easy as it sounds because you'd have to redo the tiles
on every
Martin Spott writes:
Does anyone have experiences with portable GPS recievers ? Do they tend
to increase the precision of their coordinate output if you remain at
a location for several minutes ?
It depends but usually to some degree yes
It is a worthwhile experiment to plot the position of
Chris Metzler writes:
I've been working
on making a site in Zope that one can upload to/download from, with the
intent of having pictures, a description, download links, and a comment
log for each item.
Cool !
Are you familiar with ZMapServer ?
http://zmapserver.sourceforge.net/
If you
Manuel Massing wwrites:
Sent: Monday, January 10, 2005 7:33 AM
To: flightgear-devel@flightgear.org
Subject: [Flightgear-devel] alternative terrain engine integration
Hi,
I want to start to integrate an alternative terrain engine
with flightgear
Manuel Massing writes:
I want to start to integrate an alternative terrain engine
with flightgear
(http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html)
For this, I need to adapt flightgear to use an abstract terrain API, which
will encapsulate the current
Manuel Massing writes:
I think an abstract Terrain API is a great idea however please
keep in mind that FlightGear uses a round earth model and that
this should be reflected in any FGFS Terrain API
Is this methodology you want to integrate ?
Norman Vine writes:
In the paper this appears to be based on a 'flat Earth' model
i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y
ooops ...
i.e. lon lat are taken to be simple X, Y or Cos(medianY)*X,Y
___
Flightgear-devel mailing list
Norman Vine wrote:
Manuel Massing writes:
Is this methodology you want to integrate ?
http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf
yes, that's it.
another interesting read from this project :-)
http://cg.cs.uni-bonn.de/docs/publications/2004/harabasz
Arnt Karlsen writes:
On Sat, 08 Jan 2005 14:47:20 +0800, Ivan wrote in message
[EMAIL PROTECTED]:
G''day all.
I''ve written a client that drives FG using the native-fdm I/O
mechanism.
For the ''time'' variable, I've tried entering zero, and then entering
the value returned
Jon Stockill writes:
Yes, they do need fixing - I can see terrain through the furthest hangar
where you're looking through the mesh of the door runners. Anyone know
how to fix this? Is it just an object ordering problem?
Probably you are only using one-sided polygons and the walls are
FYI
http://infothecary.org/jordan/mailman.html
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Martin Spott writes:
Dave Martin wrote:
How about a simple set of links on the same page to applications which can
handle tar.gz on Windows.
ftp://ftp.uni-duisburg.de/Windows/Win32/apps/powarc61.exe
$ untarka
untarka v0.34: super untar + untar.Z + untar.gz
contains code (C) by
Paul Surgeon writes:
Yeah I know about off screen rendering to textures but I don't know of anyone
who is willing to implement it for us.
There are at least two places this is already done in FGFS
that can be used as examples of different ways of doing this
3D Clouds and the jpeg server.
attached find my home grown Makefile
to use copy it into $OPENAL/win
and excute make
You will have to figure out how to install it
dll(s) go into $BIN
.a(s) go into $LIB
$OPENAL/include/AL/*.* go into $INCLUDE/AL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Erik Hofman writes:
David Luff wrote:
I tried out the real weather fetch option for the first time yesterday.
It's absolutely excellent! It just worked,
with no setup or bother, and gave the correct weather in Chicago according to
the forcast, and the correct weather in
Nottingham
Erik Hofman writes:
Norman Vine wrote:
Yes lots of people helped for example
http://jeremy.zawodny.com/perl/Geo-METAR/
http://www.schwarzvogel.de/software-pymetar.shtml
This sounds as if you think the METAR data is fetched only once. In fact
it isn't, it's fetched ever 30 sec
Curtis L. Olson writes:
Our terrain data comes from SRTM which has a few warts and missing
areas. I haven't started to think about how to blend data to address
this. I was hoping that at somepoint someone would release a fixed
SRTM based data set. I haven't heard of anything yet. For
[offlist]
On Sat, 25 Dec 2004 19:02:47 -0500, Norman Vine wrote:
Excuse me Curt but
This is bordering on FUD
Exchange formats are designed to capture common information for many
different uses; proprietary formats, like PLIB's SSG, are optimized
for a single app or library
David Megginson writes:
Anyway, my original point was that whether you agree or disagree, you
were being a little loose with the accusation of FUD against Curt.
He's making a legitimate point, not trying to mislead people into
doubting plib.
If you reread my original post you will note I
Chris Metzler writes:
No kidding. It's really surprising that plib supports several proprietary
3d modellers, but doesn't support the one really powerful and popular
open source modeller.
PLib was written *before* blender *was*
A plib loader for .blend would, IMHO, be an incredible boon
James Turner writes:
On 25 Dec 2004, at 14:43, Chris Metzler wrote:
A plib loader for .blend would, IMHO, be an incredible boon for FG.
This is absolutely the wrong approach; the .blend file (like the .3ds
format) is a very, rich, complex format that evolves with Blender
releases.
This is just to good not to pass along
http://norvig.com/21-days.html
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Erik Hofman writes:
Norman Vine wrote:
If someone was to do this I would suggest exporting to
the native .ssg binary format :-)
If they could fix the .ssg endianness problem in the process I'm all for it.
Hi Eric,
[EMAIL PROTECTED] Intel really messed the world up didn't
Matthew Law writes:
Personally, I'd prefer to see a nice OpenGL based GUI like some of the
other simulators and, dare I say it, games. With this method you can
throw out native look and feel and just have a very nice looking
functional user interface that works on any platform with OpenGL
Jon Berndt writes:
Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately,
in this
case, I appears that I did not consider all the needs of the animation
system. Neither one
should have to be designed to make up for something the other doesn't do. So
I think the
#include stdio.h
#if defined(WIN32) !defined(__CYGWIN__)
#define snprintf _snprintf
#endif
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of John
Wojnaroski
Sent: Friday, December 17, 2004 11:33 AM
To: FlightGear developers discussions
Subject:
Curtis L. Olson writes:
I am involved with a project where we are going to setup a multi-channel
visual system running flightgear. (3 PC's, 3 monitors.) We can budget
about $150-200 for the graphics cards, but the landscape has changed so
much since I last shopped I'm not sure what to
Jim Wilson writes:
Jon Berndt said:
Do 3D models use a normalized range to model aerosurface rotation, or
actual degree
magnitude? I've been looking at the JSBSim flight control code and the
addition of the
code that normalizes aerosurface (elevator, aileron, etc.) rotation
positions
Jon S Berndt writes:
Absolutely. And JSBSim is used by more than FlightGear - which leads
to part of the concern I have. FlightGear should not require the FDM
to massage values that it should be massaging itself.
Just need a translation layer
IIRC 'Normalized Control Units' have been in
Vivian Meazza writes:
Perhaps some of our longer standing developers can shed some light on the
background to this important decision.
This was the easiest way to implement the system at the time insuring that
only 'sane' values were ever passed. ie 'clamped'
An alternative method would be
Curtis L. Olson writes:
Jon S Berndt wrote:
Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot
be seen. Neither Amps nor fluid pressure are reported on a zero to one
scale. Aerosurfaces can be drawn and seen, and that's not done on a
zero to one basis either.
Curtis L. Olson writes:
I think we are limiting the discussion here to only flying control
surface positions, i.e.
As you point out those are only a small subset of the
Control class abstaction.
So specialize these if esired but
IMO the 'slippery slope principal' is in play here
BTW
Jon S Berndt writes:
This is irrelevant, also - at least for JSBSim.
That is an excellent observation
FGFS is more then JSBSim though :-)
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
1 - 100 of 1238 matches
Mail list logo
