Jim Wilson writes:
>
> Now when converting from mdl to ac3d using ppe (which _maybe_ isn't the same
> thing as just loading the mdl)
PPE just uses the conversion code from PLIB it does no additional massaging
ie it is the same as
ssgModelPath ( "data" ) ;
ssgTexturePath ( "data" ) ;
ssg
Andy Ross
>
> Can someone forward this to the plib list?
No need for anyone todo that it is already there !
> For whatever reason, none
> of my posts seem to get through there. Dunno if that's a sourceforge
> thing or what...
Sounds like a local problem as I see your posts to plib-devel from
Dave Perry writes
>
> Here is the gdb text after the model is complete to the segfault:
>
> > leave NewTgtAirportInit()start of fgInitProps()
> > end of fgInitProps()
> > [New Thread 8192 (LWP 1557)]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 8192 (LWP 155
Dave Perry writes:
>
> Norman Vine wrote:
>
> >please enter 'backtrace full' in the gdb window immediately after
> >gdb reports the Segmentation fault and post the results
> >
> >
> >
> Dave Perry writes:
> Here is the bactrace.
>
>
-o mdl2ac convert.cxx -lplibssg -lplibsg -lplibul -lopengl32 -lgdi32 -lwinmm
*
* This assumes that the model to convert is in a subdirectory 'model'
* and the textures are in a subdirectory 'textures'
* This is the commom directory structure for FS2000 models
*
* Norman Vin
David Megginson
>
> Norman Vine writes:
>
> > > but what worries me is how to translate a chunk of binary data
> > > into perl variables ... probably easy once you know the tricks.
> >
> > http://www.swig.org
>
> Last time I looked at
Curtis L. Olson writes:
>
> I think the ultimate solution is that plib is going to have to either
> add support for hpux, or at least fake it and do nothing.
Yes that is the *ultimate solution* but
It should be relatively easy to update the conditional compilation
of the sound code if the
Jim Wilson writes
>
> Two things we really need for doing real 3D instrument work is texture
> transforms and text for things like radio, gps and atari ferrari displays.
not sure I follow you here
texture will just transform with the underlying geometry
and text is just another texture
norman
_
David Megginson
> Norman Vine writes:
>
> > > Last time I looked at swig, it was for creating bindings for native
> > > libraries from include files.
> >
> > Not really sure what you mean by that David but SWIG is designed
> > to extend scr
David Megginson writes:
>
> Norman Vine writes:
>
> > > Two things we really need for doing real 3D instrument work is texture
> > > transforms and text for things like radio, gps and atari ferrari displays.
> >
> > not sure I follow you here
&g
Jim Wilson writes:
> Norman Vine <[EMAIL PROTECTED]> said:
>
> > David Megginson writes:
> > >
> > > He means texture animations (moving the UV coordinates around).
> >
> > Probably easier to use pbuffers or the equivalent on those platf
Jim Wilson writes:
> Norman Vine <[EMAIL PROTECTED]> said:
>
> > Jim Wilson writes:
> >
> > > Then what does ssgTexTrans:: support?
> >
> > It controls the texture transform
> >
> > google( "glMatrixMode GL_TEXTURE" )
>
Norman Vine wrote:
>
> In the case of a 3D cockpit there may be a good use for this
> in building the texture up but the main problem I see is still
> going to be polygon offset related, so I am suggesting that
> a better approach might be to bind to textureObjects rather
&
Curtis L. Olson writes:
>
> Norman Vine writes:
> >
> > This method should also be *considerably* faster then the current
> > Panel code in that the actual updating of the instruments can be
> > done on a round robin basis reducing the work done per pass as
>
David Megginson writes:
>
> Norman Vine writes:
>
> > If we can half the frame rate hit of the Panel using this kind of scheme,
> > and I expect even a better boost, then we could render half the instruments
> > one frame and the other half the next and stil
Andy Ross writes:
>
> Norman Vine wrote:
> > This method should also be *considerably* faster then the current
> > Panel code in that the actual updating of the instruments can be
> > done on a round robin basis
>
> I'm not sure this will work as well as you t
rm writs:
> >
> can anyone give me some advice on where to look to figure out
> how to pull information about airports' runways out of FG's data
> files?
I personally reccomend building one of the script interfaces to
metakit then you can explore the database interactively
The 'C" code that bu
> rm writes:
> > > >
> >also, does anyone know of a reference regarding making
> > corrections for true north
I missed this one
see SimGear / magvar
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listin
Andy Ross writes:
>>
> Remember that the "slow" thing your trying to fix is the fill rate
> penalty of rendering all the panel layers; the panel layers don't have
> significant geometry to speak of, they're slow because of all the
> texture reads. Fixing that problem with a fill-rate-intensive
>
David Megginson writes:
>
> Norman Vine writes:
>
> > The main speedup will come not from the method that the instrument
> > texture is constructed but from the side effect in that most of the
> > time most of the instrument textures will not need to be
> >
Tony Peden writes:
>
> I think you'll find that once turbulence is introduced, this won't be
> true at all. Maintaining straight and level flight in even light
> turbulence requires the pilot (or autopilot) to constantly scan the
> instruments and make adjustments.
That won't affect oil pressur
David Megginson
> It's hard to picture any
> situation (other than parked with the engine off) where the main six
> and the mag compass won't need updating every frame.
I respectfully disagree
I think you would be surprised at how steady some gauges
are when sampled at 30 hz and displayed at th
David Megginson
>>
> You can spot a
> trend with a needle much faster than you can read an absolute value,
> and to fly steady, you really have to work hard to damp out the
> movement.
I agree and with my proposal you would see a deflection once
the required 'delta' was reached. I am assuming
Tony Peden writes:
>
> On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
> >
> > Anything that has built in damping, air pressure controlled devices ect,
> > probably have no need to be sampled at anything greater then 5 hz
> > unless you are flying thru a tornado
Tony Peden
>
> No matter how sophisticated the ECS may be, it can only react to changes
> in the aircraft state ...
or sensor state :-)
> Aside from all that whatever lags or damping may exist should be modeled
> by the code for the individual instrument. It shouldn't arise from lack
> of samp
Jonathan Polley writes:
>
> Second, I got an error in src/ATC/tower.hxx.
>
> typedef list < TowerPlaneRec* > tower_plane_rec_list_type;
> typedef list < TowerPlaneRec* >::iterator tower_plane_rec_list_iterator;
> typedef list < TowerPlaneRec* >::const_iterator tower_plane_rec_list_const_iterator;
>
Jonathan Polley writes:
> >
> Any more ideas?
maybe
$ cvs diff ATCVoice.cxx
Index: ATCVoice.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/ATC/ATCVoice.cxx,v
retrieving revision 1.2
diff -r1.2 ATCVoice.cxx
96
Norman Vine wrote:
>
> sample rate will remain exactly the same with my proposed scheme
Actually if the proposed scheme has a higher fps the sample rate will
increase accordingly also
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED
Paul Deppe writes:
>
> I'm getting the following warning when running ./configure with CVS SimGear
> on Cygwin/Win2k:
>
> configure: WARNING: winbase.h: present but cannot be compiled
> configure: WARNING: winbase.h: check for missing prerequisite headers?
> configure: WARNING: winbase.h: proceed
David Megginson writes:
>
> Luke Scharf writes:
>
> > Where would I find documentation about code-layout of FGFS? I did a
> > quick scan of flightgear.org and I didn't see a document that looked
> > like it addressed "this object does this and relates to the other
> > objects like that" quest
David Megginson writes:
>
> Norman Vine writes:
>
> > A worthy project indeed but IMHO an even worthier project
> > would be to collect all of the various "properties" into a single
> > document that included
> >
> > 1) a short descriptio
Paul Deppe writes:
> > >
> > > When compiling CVS simgear/sky/clouds3d I am getting numerous warnings:
> > > "WIN32 redefined", "initialization from int to float", "... is
> > implicitly a
> > > typename", and many others, and finally the following error
> > when compiling
> > > SkyTextureState.cp
Michael Selig
>
> As it relates to documenting things, I'd like to ask this again: Is this
> file property-api.html still around somewhere? This doc described the
> property tree. It was a draft from Curt I believe.
>
> It seems to me like the property stuff is the most important part of
>
Michael Selig writes:
>
> At 12/22/02, Norman Vine wrote:
> >Michael Selig wrote:
> > >
> > > It seems to me like the property stuff is the most important part of
> > > FGFS. If one does not understand how to use this and code for it (both in
> > &
Paul Deppe writes:
>
> I found that Cygwin installs TWO copies of gl.h:
>
> opengl package installs: /usr/include/GL/gl.h (which declares
> glActiveTextureARB) and w32api package installs:
> /usr/include/w32api/GL/gl.h, (which does not).
>
> The w32api gl.h is dated later but does not declare gl
Paul Deppe writes:
> > I think the problem stems from being included before "extgl.h"
> >
> > Note and both include so "extgl.h" must
> > precede these also
> >
> > Norman
>
> I inserted the following in SkyTexture.hpp at line 36:
>
> #ifdef WIN32
> # include "extgl.h"
> #endif
>
> ... and
Jim Wilson writes:
>
> Is there a way to copy a block of properties
#include
copyProperties (const SGPropertyNode *in, SGPropertyNode *out)
But AFAIK this requires that the 'out' nodes exist
i.e. this copies but does not construct the nodes
I think the easiest way to 'clone' a branch is to writ
David Megginson writes:
>
> Norman Vine writes:
>
> > > Thanks. That's pretty handy. I notice that this does not seem
> > > to include all of the property information in some files, eg
> > > sound.xml (and several other .xml files seen when
Erik Hofman writes:
> >
> This is a heads up for everybody to know that I am working on the STL
> part of SimGear. Instead of using defined STL_* macros I will supply a
> bunch of header files which would, at the end, make life easier for
> everyone.
>
> I have the feeling that the MipsPro com
David Megginson writes:
>
> Norman Vine writes:
>
> > IMHO - If at all possible we don't want *more* headers to slow the already
> > overly long compile times :-(
>
> The best way to speed up compile times is to reduce unnecessary
> interdependencies. Right
Jon S Berndt writes:
< >
>
> VALUE="{property|value}">
> {property} {conditional} {property|value}
> ...
>
> VALUE="{property|value}">
> {property} {conditional} {property|value}
> ...
>
>...
>
>
> This is a request for developer community comment :-)
>
Jonathan Polley writes:
> The latest updat to src/Main/main.cxx is generating the following errors for MSVC
>6.0 (and I assume for all Windows compilers).
>
> c:\fgdev\flightgear\src\main\main.cxx(749) : error C2065:
>'GL_DISTANCE_ATTENUATION_EXT' : undeclared identifier
> c:\fgdev\flightgear\
Curtis L. Olson
>
> You forgot to include the TerraGear source (without which there would
> be no scenery to look at.)
I think PLIB should be included too !
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailm
Ivo writes:
>
> It reminded me of something. A few weeks ago, I tried using the jpg-httpd
> part of FG and mencoder to capture flying in realtime. I used a looped wget
> to 'download' the images as fast as possible. The problem I stumbled upon,
> was the very low download speed I got. Around 3-
Erik Hofman writes:
>
> Andy Ross wrote:
> > Erik Hofman wrote:
> >
> >>There is a compiler directive:
> >>
> >>#if BYTE_ORDER == BIG_ENDIAN
> >>#else
> >>#endif
> >
> >
> > I've never heard of this one. Is it a standard thing, or a common
> > extension?
>
> It should be supported by all comp
Andy Ross writes:
>
> Curtis L. Olson wrote:
> > I believe that plib has some endiannes tests. Also simgear, have a
> > look at simgear/io/lowlevel.hxx (towards the end)
>
> Right. But those are runtime tests. What Nasal needs to modify is a
> structure order, which can only be done at compile
Curtis L. Olson writes:
>
> David Megginson writes:
> > Yes, reset and save/restore are a bit broken in FlightGear right now. I'll
> > try to fix them when I have a chance, but it will require a bit of
> > refactoring (removing Curt's initial-state stuff, for example).
>
> I definitely need th
Brandon Craig Rhodes writes:
>
> I am positive; the coordinates in the stars file were simply wrong,
> and fixing them repaired the constellations. Orion before:
>
> http://www.rhodesmill.org/tmp/orion-before.png
>
> Orion after:
>
> http://www.rhodesmill.org/tmp/orion-after.png
P
Jon S Berndt writes:
>
> Can anyone point out a flag for Slovenia?
google("flags of the world")
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon S Berndt writes:
Can anyone point out a flag for Slovenia?<>___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I just stumbled apon http://livarot.sourceforge.net/
which looks as if it probably has some useful stuff for those
building airport layout tools.
Specifically it appears to have code for building polygon buffer objects
ie given a polygon create another polygon either larger or smaller by
some
Erik Hofman writes:
>
> Jim Wilson wrote:
> > >
> > Your suggestion sounds interesting, but those screen shots are way too blue.
> > We get a lot of those dry polution free days here in Maine. And it doesn't
> > look like that. Keep in mind that your optical sense can be a tricking thing.
> >
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
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 lo
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 *global
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 fro
http://perthon.sourceforge.net/
:-)
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Andy Ross writes:
>
>
> Again, IMHO it's a realism thing. Computer monitors don't have the
> spacial resolution that an eye does, so we have to allow for zoom.
> But pilots don't usually have telescopes in the cockpit, so it should
> by default be limited to something approximating real life.
T
David Luff writes:
>
> I couldn't find the date the photo's were taken during a cursory search,
If you click on the info button when in the interactive mode
you will get some meta-data to include the 'date' of the photos
For example
Image Info
Info: Digital Ortho-Quadrangles (digitized and oth
Melchior FRANZ writes:
>
> BTW: reverting the last patch and going back to revision 1.2 fixes
> the bug. But it does still not explain the "client" zombie.
The client is constructed in pol() at the end of the file
___
Flightgear-devel mailing list
[E
http://www.boston.com/news/galleries/2003/domeplane/01.htm
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Andy Ross writes:
>
> Problems with the existing LaRC code:
>
> + It's slightly wrong. I don't quite know when it happened, but the
> sg_geodesy files have incorrect numbers for the WGS84 equatorial
> radius.
Yes, this was written before the 'standard' was adopted and we just
adopted it
Curtis L. Olson writes:
>
> Andy,
>
> Why don't we go ahead and commit one of these since both sound a lot
> better than what we have now. Then we could do some timing tests and
> see if we need to consider trading precision for faster performance.
Note this will cause a 'shift' with respect to
Norman Vine wrote:
>
> Curtis L. Olson writes:
> >
> > Andy,
> >
> > Why don't we go ahead and commit one of these since both sound a lot
> > better than what we have now. Then we could do some timing tests and
> > see if we need to consider trad
Andy Ross writes:
>
> But the error isn't very large. It's not like the old code was
> horribly wrong. On the surface, it disagreed by about a meter or so.
> Scenery buildings probably aren't placed that accurately anyway.
AFAIK the geoid error is an order of magnitude or so greater then
then
Looking around on the UNB site I discovered this gem
http://einstein.gge.unb.ca/tutorial/precision_navigation.htm
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
David Luff writes:
>
> I've been having a poke about at the scenery and material managers with a
> view to attempting to get dynamic scenery texture paging working at some
> point.
> There's two things that the scenery management code can't (I don't think,
> anyway) do now, that I'd like it to
Andy Ross writes:
>
> My requirement isn't accuracy, it's precision. The difference is
> subtle:
I understand, and that is *exactly* why I never worried about the slight
differeance between the Ellipsoid that FlightGear inherited and WGS84,
On another note while we are redoing the geodesy cod
Andy Ross writes:
>
> Using the Toms algorithm would work, but it would require care to make
> sure that the number of operations on geodetic numbers stays small.
Ah ... a basic philosophical difference
One should only ever have to-do the geodetic transforms once for
any given position.
Once
Curtis L. Olson writes:
>
> But personally, I don't mind if
> FlightGear runs on top of proprietary operating systems or drivers
> such as Mac OS, sgi, windows, solaris, or a binary nvidia driver on
> linux. There needs to be a balance between idealism and pragmatism.
Taking the paragmatic route
David Luff writes:
>
> On 12/19/03 at 8:52 AM Norman Vine wrote:
> >
> >Ah.. the light shines in Britain too :-)
> >http://baron.me.umn.edu/pipermail/flightgear-devel/2002-August/009981.html
> >
>
> LOL, I seem to have come up with an almost word for word
David Megginson writes:
>
> I understand how velocity affects that (a plane twice as
> fast needs twice the time and four times the space to make the same change
> in direction with the same load factor), but I don't understand how inertia
> plays into it.
Good way to gain intuition on this i
Andy Ross writes:
> >
> An even better addition would be libjpeg integration for texture
> files.
I doubt if that will ever happen
http://sjbaker.org/steve/omniv/jpegs_are_evil_too.html
But I agree we shoul dbe using texture compression
Best would be a OpenGL supported format like S3TC but old
FYI - seen on Slashdot
http://science.slashdot.org/science/04/01/03/1733231.shtml?tid=134&tid=160
The Maestro Team writes "NASA has released Maestro, a public version of the primary
software tool used by scientists to operate the
Mars Exploration Rovers from the Jet Propulsion Laboratory. Anyone
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"
FW
Melchior FRANZ writes:
>
> The server is working, but it seems to suffer from overload and rejects
> every other connection. Just do this:
>
> $ while true; do cvs up && exit; sleep 1; done
>
> And then wait a minute. :-)
I just love this logic
A server is overloaded
Launch a mini DOS attac
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. O
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 l
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 th
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 t
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 <<
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 dir
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
http://vrmlworks.crispen.org/tools.h
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 fra
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
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 release
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
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
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
___
F
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
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.
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
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
http://www.spamabus
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]
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,
There is a conflict between and s
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 rea
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 PROT
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.htm
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
Jim Wilson writes:
>
> Norman Vine <[EMAIL PROTECTED]> said:
>
> > Jim Wilson writes:
> > >
> > > > >
> > > > > What we need is something that looks ahead and makes adjustments based on
> > > > > fu
501 - 600 of 1464 matches
Mail list logo
