RE: [Flightgear-devel] Lighting
Curtis L. Olson writes: The problem only seems to happen when the 3d model is in the view. To me, that would point to a problem with the model, or a problem with plib's handling of the model. For instance if the 3d model tickles some material or lighting feature that plib doesn't normally handle or doesn't handle at all. But, I would be (maybe very) surprised to find such a bug in plib that no one else has discovered previously. It might be informative to dump out or use gdb to look at the the actual OpenGL state values being used i.e the ambient, emissive, specular ect in the pre and post callbacks for the 3d model If one of these is being 'tromped on' then funny things are bound to happen ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Website updates
David Megginson writes: Erik Hofman writes: It might be usefull to rearrange the website, to let the Table of Contents show up first on the page. It would be a good idea to add the News and Project Overview sections to the table of contents then. I'd suggest that starting with screenshots is a better idea -- we don't want to waste a lot of screenspace or bandwidth, but we do want to give a first-time visitor an idea of why it's worth spending more than 3 seconds looking at FlightGear. The pictures show the current state of the project much more efficiently than text could. FWIW IMHO pictures do not belong on the main page at all !!! I am in complete agreement with Eric's suggestion that 'index.html' should be just our Logo, Table of Contents, Search Form, Counter and Credits. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Lighting
Norman Vine writes:
Curtis L. Olson writes:
The problem only seems to happen when the 3d model is in the view. To
me, that would point to a problem with the model, or a problem with
plib's handling of the model. For instance if the 3d model tickles
some material or lighting feature that plib doesn't normally handle or
doesn't handle at all. But, I would be (maybe very) surprised to find
such a bug in plib that no one else has discovered previously.
It might be informative to dump out or use gdb to look at the
the actual
OpenGL state values being used
i.e the ambient, emissive, specular ect
in the pre and post callbacks for the 3d model
If one of these is being 'tromped on' then funny things are
bound to happen !
Not really sure what all it means and / or how they get there but ...
There are some 'interesting values in the file this generates
void
FGAircraftModel::init ()
{
_aircraft = new FGModelPlacement;
string path = fgGetString(/sim/model/path, Models/Geometry/glider.ac);
try {
_aircraft-init(path);
} catch (const sg_exception ex) {
SG_LOG(SG_GENERAL, SG_ALERT, Failed to load aircraft from path);
SG_LOG(SG_GENERAL, SG_ALERT, (Falling back to glider.ac.));
_aircraft-init(Models/Geometry/glider.ac);
}
_scene-addKid(_aircraft-getSceneGraph());
_selector-addKid(_aircraft-getSceneGraph());
globals-get_scenery()-get_aircraft_branch()-addKid(_selector);
#if 0
FILE *fp;
fp = fopen(model.ascii, wt);
_aircraft-getSceneGraph()-print(fp);
fclose(fp);
#endif
}
e.g.
ssgVtxTable: Name=NoName
Userdata = 0x0
Num Parents=1
ssgSimpleState: Name=NoName
Userdata = 0x0
Translucent = True
ExternalProp = 0
Don't Care = CULLFACE
Enabled = TEXTURE2D COLOR_MATERIAL BLEND LIGHTING
TexHandle= 3
TexFilename =
'/home/nhv/FlightGear/Aircraft/c172/Models/c172-01.rgb'
Shade Model = 7425
Shininess= 2.00
AlphaClamp = -0.326197
ColourMatMode= GL_AMBIENT_AND_DIFFUSE
Ambient : (-0.455241,-0.326197,0.526312,-0.455241)
Diffuse : (-0.326197,-0.468420,-0.832415,-0.326197)
Specular : (0.00,0.00,0.00,1.00)
Emission : (0.00,0.00,0.00,1.00)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: lighting
Curtis L. Olson writes:
Ok, that was definitely helpful. If you go to src/Model/model.cxx,
line #248 and comment out the Load panels section of code, the C172
becomes shaded again and the objects no longer glow at night.
Good one !
Looks like we need something like
void
FGPanel::draw()
{
glPushAttrib( GL_ENABLE_BIT | GL_POLYGON_BIT | GL_COLOR_BUFFER_BIT |
GL_LIGHTING_BIT ) ;
.
glPopAttrib();
}
Not sure if I got them all
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Website updates
Norman Vine wrote: FWIW IMHO pictures do not belong on the main page at all !!! Instead IMHO we should present a 'well organized' entry point that is viewable on one page so as to impress our visitors with our 'professionalism' FWIW - One of my favorite sites is http://www.google.com Which I believes demonstrates well that a 'minimalist' front page can be quite successful as it is the 'content served' and 'navigational ease' that is most important to a projects popularity and usefulness. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] tdfx fog
Melchior FRANZ writes:
Here's why my tdfx v3 doesn't show fog any more[1]: it's the
glPolygonOffset() in the 3D-panel code. And I remembered that
Andy had commented on this problem a while back in the already
mentioned thread ...
snip
Index: panel.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.75
diff -u -3 -p -r1.75 panel.cxx
--- panel.cxx 22 Jul 2002 19:09:42 - 1.75
+++ panel.cxx 23 Jul 2002 18:59:07 -
@@ -423,6 +423,7 @@ FGPanel::draw()
// restore some original state
glPopAttrib();
+ glPolygonOffset(0, 0);
glDisable(GL_POLYGON_OFFSET_FILL);
}
Does this slightly different code work for you
void
FGPanel::draw()
{
// In 3D mode, it's possible that we are being drawn exactly on top
// of an existing polygon. Use an offset to prevent z-fighting. In
// 2D mode, this is a no-op.
glPushAttrib( GL_COLOR_BUFFER_BIT | GL_ENABLE_BIT | GL_POLYGON_BIT |
GL_LIGHTING_BIT
| GL_TEXTURE_BIT | GL_PIXEL_MODE_BIT );
..
// glDisable(GL_POLYGON_OFFSET_FILL);
glPopAttrib() ;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [PATCH] tdfx fog
Curtis L. Olson writes: Up until recently glPolygonOffset() was an vendor extension to the official spec, perhaps that's why it's not included in glPush/PopAttrib()? Hmm... Looking at the NEW 1.4 OpenGL spec it appears as if glPolygonOffset() has been included in the spec since v1.1 1992 ? and whether the current offset is applied or not depends on the the following flags POLYGON_OFFSET_POINT POLYGON_OFFSET_LINE POLYGON_OFFSET_FILL which I believe should be settable with pushAttrib() following URL all one line http://www.opengl.org/developers/documentation/Specs/glspec1.1/node58.html#S ECTION00655000 Oh well -- what we have works as is :-)) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds progress : screenshot
David Megginson writes: Curtis L. Olson writes: I don't know a lot about the 3d clouds, but I was under the impression that you could define different cloud shapes and complexities. We are just running with the cloud layout from Mark's demo. Understood. The demo is meant to look stunning, of course, but as with terrain and 3D models, we will have to compromise a lot to make things work in a flight simulator: I expect that the final clouds will be a lot coarser, but still nice. As I said when Mark first released this demo This is enough to make 'diehard' Linux types install Windows We are just trying to get to it run as well inside of FGFS there-are-many-kinds-of-compromises though'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds progress : screenshot
John Wojnaroski writes: Curtis L. Olson writes: David Megginson writes: I'm wondering if we can make everything a bit simpler -- smaller textures, fewer particles, etc. We'd still get 3D clouds, but they wouldn't hit the GPUs as hard. I don't know a lot about the 3d clouds, but I was under the impression that you could define different cloud shapes and complexities. We are just running with the cloud layout from Mark's demo. There is an editor program Mark wrote for adding and editing clouds. source and Win32 exe @ http://rockfish.net/~nhv/fgfs/SkyEditor.tgz This is Win32 specific and there is no Makefile but it is a REAL simple application and is really is just an textmode interface to the 'portable' SkyArchive class The SkyArchive probably wants to be modified to use XML properties instead of its binary files - at first glance this seems as if it would be quite easy todo :-) I suppose running the HUD, panel, clouds, random-objects, models, etc, etc will slow everyone down, but lets not design for the LCD and assume everything has to be on. Rather the user should have the option. dumbing down the clouds penalizes those who chose to not enable other graphical features in FlightGear. Let's first get it running, see if we can improve on Mark's design, and go from there. I agree and FWIW except for the occasional sputter, similar to paging in tiles it seems to have about the same 'hit' then having either the Panel or a Plane displayed Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another automake victim
The Bergrens writes: Sounds like you need the perl module called strict to be installed. Or maybe your perl installation is hosed. You can get perl modules from cpan.org, I think. There was a bug in Cygwin Perl that 'can' be triggered by automake when running on a project on a 'text' mounted drive. The cure is to do all of your work on a 'binary' mount Since I discovered the problem I have never tried automake on a text mount so I am not 100% that this bug still exists BUT if you are working on a 'text' mount HTH Norman - Original Message - From: William Earnest [EMAIL PROTECTED] To: Devel Flightgear [EMAIL PROTECTED] Sent: Tuesday, September 10, 2002 10:38 PM Subject: [Flightgear-devel] Another automake victim Hello all, Came back from vacation to find the new release and lots of discussion. Read everything (I think), and managed to get CVS caught up, including the new SimGear path. Updated plib without problem, then went to SimGear to continue. At the autogen.sh step, got the following pile of errors, which has me rather puzzled. Supposedly have automake 1.5 installed, as well as autoconf 2.52. Any suggestions? [wde@hulk SG]$ ./autogen.sh Can't locate strict.pm in @INC (@INC contains: /usr/share/automake /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/bin/automake line 39. ./autogen.sh: test: -lt: unary operator expected Host info: Linux i686 Can't locate strict.pm in @INC (@INC contains: /usr/share/automake /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/bin/automake line 39. automake: () Running aclocal Running autoheader /usr/bin/m4: configure.in: No such file or directory ERROR: autoheader didn't create simgear/simgear_config.h.in! -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds progress : screenshot
Michael Basler writes: maybe on windows all is OK and problem is related to linux? Don't worry, on windows (cygwin), SimGear does not even compile - yet, despite all the patches ;-) - I think Norman is working on that, though. Things were going rather well for me on Windows then I decided to try merging the latest stuff from CVS and I suddenly had problems I didn't see before. Spent way to much time trying to decipher what is happening and need to get some real work done so I tarred up my files with tar -czvf clouds.tgz \ FlightGear/src/Main/main.cxx \ FlightGear/src/Main/fg_init.cxx \ SimGear/configure.ac \ SimGear/simgear/sky/clouds3d/*.cpp \ SimGear/simgear/sky/clouds3d/*.h* \ SimGear/simgear/sky/clouds3d/*.c and put the tarball at http://rockfish.net/~nhv/fgfs/clouds.tgz so others could play too. This should build on Windows and Unix, I didn't add the necessary Mac changes but I think Jonathan has that covered Back up your original files !! Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds progress : screenshot
Curtis L. Olson writes:
Jim, Norman,
I'm getting the following compile error:
fg_init.cxx: In function `void fgInitView()':
fg_init.cxx:667: no matching function for call to `FGViewer::get_LOCAL ()'
oops ... forgot one :-)
I was doing a little sanity checking
// $FG_SRC / Main / viewer.hxx
virtual const sgVec4 *get_LOCAL() { if ( _dirty ) { recalc(); } return
LOCAL; }
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Removed simgear/interpreter/
David Megginson Curtis L. Olson writes: The MSVC work spaces are generated automatically whenever I run make dist. I have taken care of this. Thanks for handling that. If the files are autogenerated, we might want to yank them out of CVS. Most MSVC users probably don't have Perl installed so in this case I think we should make an exception Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d cloud rendering problems
Curtis L. Olson Norman Vine writes: I think you are on to something ! That would explain the lightening of the clouds with each pass. BUT this only started after I updated my code the other day !. Also I never had the 'text' texture Right now I'm wondering if it is related to the use of glColorMaterial()? The curious thing is that the 'coloring bug' and the the texture 'jitter' just appeared recently and I can't see what changed to cause it. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another automake victim
Curtis L. Olson writes: I don't think anyone has sent me a copy of extgl.h to add to the cvs repository. It is in this tarball http://rockfish.net/~nhv/fgfs/clouds.tgz Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS build problem, was Another automake vi ctim
Boslough, Mark B writes: I just tried that and unfortunately I get exactly the same problem. OK I know what the problem is I am going to try again from scratch. Try changing SimGear\simgear\sky\clouds3d\Makefile around line 99 to read like this EXTRA_WIN32_SOURCES = extgl.c #EXTRA_WIN32_SOURCES = I do have a question. How do I keep the two CVS branches separated? When I do a make install for simgear on the stable branch, does that not overwrite the simgear for the devel branch? I'm just wondering what is the best way to keep the branches totally isolated from one another. Sorry if this has been answered elsewhere (as I am sure it has). The trick is to install the packages into different Sandboxes The easiest way for me is to use the --prefix=$PATH option when configuring a package HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Curtis L. Olson writes: We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. The Impostors are generated with regular OpenGL calls just like everything else and then read out of the back buffer into a texture which then serves as an 'impostor' for the real OpenGL object. eg you are substituting a glQuad for the entire set of calls that were made to draw the object initially. hence the name 'impostor'. You can see the impostors getting created after you find and follow the directions in this line in SkyCloud.cpp // Uncomment this swap buffers to visualize cloud illumination computation. Whatching these things get created gives you a GOOD ideaof how much work the 'impostor' is saving you Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modeling wing twist animation
David Megginson writes: Wolfram Kuss writes: PLIB is AFAIK able to do that with a technique called tweening. There is even an example of it, where a ball is tweened to a star and vice versa. I'm not sure how that would work with the loaders, though -- do we have to guarantee that they vertices are in exactly the same order? it tweens between points with the same index in the tween arrays so I guess the answer is yes depending on what you want todo have you looked at the examples ssg tween_test program Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still can't build devel CVS
Jon S Berndt writes: Just to be sure: can you see the clouds ?? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still can't build devel CVS
- Original Message - From: Boslough, Mark B [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 5:40 PM Subject: RE: [Flightgear-devel] Still can't build devel CVS That is correct. mark Part of the problem is I can not connect to CVS so I am not really sure of what the state of the files are but if you bear with us we will get this compiling so just to be sure we know what is happening please do a cvs up -Pd for both SimGear and FlightGear then in SimGear do a % make uninstall % make distclean % ./autogen.sh % ./configure % make 21 | tee make.log % make install cd to FlightGear % make 21 | tee make.log If you still are having linking problems cd to SimGear % make clean % CFLAGS=$CFLAGS -DWIN32 ./configure % make 21 | tee -a make.log % make install cd to FlightGear % make 21 | tee -a make.log Thanks Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anybody seeing this ?
Frederic Bouvier writes: http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-prop.png Any idea ? Yep, This is a known problem so Don't do that or disable the propellor node in the model when you are in a 3D cockpit of a plane with a propellor norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] jigdo (Jigsaw Download) - a download manager for CD images
Does anyone have any experience with this ? It looks as if it could be quit useful http://home.in.tum.de/~atterer/jigdo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiler/OS Version Question
Curtis L. Olson writes: Jonathan Polley writes: I have a few questions brought about by some recent experiences, but what they boil down to is Are we going to reestablish the minimun system requirements for FlightGear. First, due to deficiencies in the compiler, it is becoming more and more difficult to build FlightGear under MSVC 6.0. Does MS have something newer people can migrate to that works better? I hear VERY good things about STLPort and MSVC6 I also hear that MSVC 7 fixed most of the 'non standard' mscv'ism's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still can't build devel CVS
Curtis L. Olson writes: Usually my common mistaek is to statr reversing letter piars when I get really tired or overly pumpde up on caffiene, and I remember taking about 4 tires to type that in before I got it right. Srory about that. Good one :-) this is currently $(EXTRA_SOURCES) and needs to be changed to $(EXTGL_SOURCE) as above so that estgl.o is acually included in the library ^ Happens to the best of us :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: I've tried the request in two places: 1. When the *.stg file is first parsed and the OBJECT_SHARED directive is found. 2. When the deferred model is actually loaded. Both gave no intersection. BUT does the Terrain Graph contain the tile you are trying to determine the AGL from ?? This is a prerequisite and AFAICT currently this is not gauranteed to be the case until AFTER the 'load function' leaves the select switch for the OBJECT_SHARED case !!! chicken-and-egg'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Curtis L. Olson
Norman Vine writes:
BUT does the Terrain Graph contain the tile you are
trying to determine the AGL from ??
This is a prerequisite and AFAICT currently this is not gauranteed to
be the case until AFTER the 'load function' leaves the select switch
for the OBJECT_SHARED case !!!
What we need is the ability to specify the branch of a scene graph to
intersect with which in theory isn't too hard, but as I recall a lot
of the transforms are wired in at a pretty low level and a branch
won't necessarily be positioned correctly in the flightgear world if
we don't have the transforms above it.
AFAIK The only thing hardwired in is the scenery_center
and this is only in the high level fgCurrentElev() calls
The hitlist stuff is pure SSG code and should work in
any SSG Graph ,
// ==
void FGHitList::Intersect( ssgBranch *scene, sgdVec3 orig, sgdVec3 dir ) {
sgdMat4 m;
clear();
sgdMakeIdentMat4 ( m ) ;
IntersectBranch( scene, m, orig, dir );
}
// ==
void FGHitList::Intersect( ssgBranch *scene, sgdMat4 m, sgdVec3 orig,
sgdVec3 dir )
{
clear();
IntersectBranch( scene, m, orig, dir );
}
and since distance from a point to a surface is invariant
withrespect to orientation either of these routines should
work as is providing you can determine the 'dir' vector
straight down .
This is a little complicated in that we are on an ellipse but ...
following untested - this is a WAG only - and is not
completely thought out at all
I guess one could use something like this for the
derivation of 'dir'
// given a point in dir_cosine form
// return WGS84 tangent plane normal
// use CAREFULLY if you don't fully understand the magic
void
Normal_WGS84(sgdVec3 point, sgdVec3 normal)
{
normal[0] = point[0] * (1/40680631590769.0);
normal[1] = point[1] * (1/40680631590769.0);
normal[2] = point[2] * (1/40408299984087.0);
sgdNormalizeVec3(normal);
}
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: Norman Vine writes: BUT does the Terrain Graph contain the tile you are trying to determine the AGL from ?? It should, because the OBJECT_STATIC directive occurs only in *.stg files, which are parsed when the tile containing the object is loaded. This is a prerequisite and AFAICT currently this is not gauranteed to be the case until AFTER the 'load function' leaves the select switch for the OBJECT_SHARED case !!! I tried loading all of the required info into the deferred-model structure and doing the intersection later in the program when the model made its way to the front of the queue for loading; still no intersection. Well if the tile is REALLY loaded then .. my guess is that your parameters are based on the wrong 'scenery_center' try setting up a 'phony teleportation' to where the scenery_center and absolute_position are in the same tile as the point that you are requesting the elevation for. I am still not convinced that your tile is actually loaded though and don't really know the 'best' way to check for that given the 'lazy' loader. Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: Norman Vine writes: BUT does the Terrain Graph contain the tile you are trying to determine the AGL from ?? It should, because the OBJECT_STATIC directive occurs only in *.stg files, which are parsed when the tile containing the object is loaded. Are you testing the loaded flag for the tile entry you are testing against? IIRC that is the last thing done by the loader. Take a look at the end of the mainloop (approx line 1155 in main.cxx) to see how I'm getting an AGL for the FDM's location when it is not in the current view. It uses the high level tilemgr methods, but if you follow the values you should be able to see what you are missing. Yes, this is demonstrates nicely the method I outlined in my last post try setting up a 'phony teleportation' to where the scenery_center and absolute_position are in the same tile as the point that you are requesting the elevation for. Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D-clouds and HUD markers
Martin Spott So to reiterate what Curt This isn't quite ready for general consumption but some of us are working on it Sorry, I didn't mean to hurt anyone. No problem, just wanted to make sure everyone realizes this is still in development :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fw: [vtp] Elevationdata of the Alps?
A source for non-US 30 meter DEM's I believe that for those areas already processed and on line these are still free. We would have to build a new DEM reader to handle these but that should not be too dificult in that they are in a 'well known' format Norman - Original Message - From: Roger James [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 7:06 AM Subject: Re: [vtp] Elevationdata of the Alps? You can view the current coverage at http://edcsgs7.cr.usgs.gov/aster/dem_map.html If it is not on this then you have to order it yourself. Expect a 9 month lead time for relative DEMs but only a few days if you can provide GCPs and request an absolute DEM. To generate the GCPs you will need the L1A dataset, this will now cost you but not a lot. Roger - Original Message - From: Peter Guth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 5:06 AM Subject: Re: [vtp] Elevationdata of the Alps? I am looking for 10-30m elevation data of the Alps. You could also try the ASTER DEM from NASA/USGS: http://edcdaac.usgs.gov/aster/ast14dem.html They have data worldwide, but not complete. You also have to deal with holes To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] defaults
Curtis L. Olson wwrites:
David Megginson writes:
Curtis L. Olson writes:
The preferences.xml file specifies the c172 as the default. It
appears that even if you request a different aircraft as the default,
the c172 config files get loaded first anyway, then the alternate
config file is loaded with the correct aircraft. This means that if
the c172 specifies any defaults such as aileron trim that isn't
specified in the desired aircraft config, it will inherit the c172
settings (i.e. they won't get overwritten, unless done so
explicitely.)
Is this what we want the behavior to be?
No.
Ok, good to know.
I'm guessing it got this way for a reason, but I'm not sure we want
things to act this way.
It's almost certainly an initialization-order problem. We want the
aircraft settings to take precedence over preferences.xml and the
command-line options to take precedence over the aircraft settings.
Feel free to fix it, if you can think of a way to.
I haven't actually looked into it beyond observing that an addition to
the c172-set.xml file shows up no matter what aircraft I choose. So,
I haven't dug into the code at all to see what is actually going on.
Hmm... maybe this would help
untested - but it 'looks' like this will fix 'this' problem,
don't thin it will cause any new ones
// Read in configuration (file and command line)
bool fgInitConfig ( int argc, char **argv ) {
// First, set some sane default values
fgSetDefaults();
// Read global preferences from $FG_ROOT/preferences.xml
SGPath props_path(globals-get_fg_root());
props_path.append(preferences.xml);
SG_LOG(SG_INPUT, SG_INFO, Reading global preferences);
readProperties(props_path.str(), globals-get_props());
SG_LOG(SG_INPUT, SG_INFO, Finished Reading global preferences);
// Attempt to locate and parse the various config files in order
// from least precidence to greatest precidence
// Check for $fg_root/system.fgfsrc
SGPath config( globals-get_fg_root() );
config.append( system.fgfsrc );
fgParseOptions(config.str());
#if defined( unix ) || defined( __CYGWIN__ )
char name[256];
// Check for $fg_root/system.fgfsrc.hostname
gethostname( name, 256 );
config.concat( . );
config.concat( name );
fgParseOptions(config.str());
#endif
// Check for ~/.fgfsrc
char* envp = ::getenv( HOME );
if ( envp != NULL ) {
config.set( envp );
config.append( .fgfsrc );
fgParseOptions(config.str());
}
#if defined( unix ) || defined( __CYGWIN__ )
// Check for ~/.fgfsrc.hostname
gethostname( name, 256 );
config.concat( . );
config.concat( name );
fgParseOptions(config.str());
#endif
// Parse remaining command line options
// These will override anything specified in a config file
fgParseArgs(argc, argv);
// Read the default aircraft config file.
string aircraft = fgGetString(/sim/aircraft, );
if (aircraft.size() 0) {
SGPath aircraft_path(globals-get_fg_root());
aircraft_path.append(Aircraft);
aircraft_path.append(aircraft);
aircraft_path.concat(-set.xml);
SG_LOG(SG_INPUT, SG_INFO, Reading default aircraft: aircraft
from aircraft_path.str());
try {
readProperties(aircraft_path.str(), globals-get_props());
} catch (const sg_exception e) {
string message = Error reading default aircraft: ;
message += e.getFormattedMessage();
SG_LOG(SG_INPUT, SG_ALERT, message);
exit(2);
}
} else {
SG_LOG(SG_INPUT, SG_ALERT, No default aircraft specified);
}
return true;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER DEMs
Roman Grigoriev writes: I downloaded ASTER DEM and play with it Nice resolution (30m) but there are so many holes to use it So fightgear/terragear gurus maybe you tell me is there in dem library some tools to approximate aster dem data with gtopo30 data to eliminate holes? It is currently commented out but see src / lib / dem interpolate() It may still work and in any case shouldn't need much to fix there is also an Interpolate in the Lib/Array class also commented out Another question: now we have tile size = 1/8 degree. but when you deal with this high resolution data you have to load smaler tiles to have good frame rate where should I search terragear/flightgear code to have tile size 1/16 or 1/32 degree. The US scenery is made with 30 meter DEM's so things should work OK the least squares fit process removes many points and is 'tunable' if need be Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] Re: Windows binary (fwd)
Jim Brennan jjb writes: Can anyone provide this for me? http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz Note this does not have LaRCSim or UIUC support as there is a namespace clash with the beta MingW gcc compiler I am using. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Re: Windows binary (fwd)
Michael Selig writes: At 9/26/02, Norman Vine wrote: Jim Brennan jjb writes: Can anyone provide this for me? http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz Note this does not have LaRCSim or UIUC support as there is a namespace clash with the beta MingW gcc compiler I am using. I recall reading some prior email from you on the namespace problem. In that email you seemed to suggest that this was a fairly general problem and not specific to your compiler. Is there something that we can do here at UIUC to resolve this compile issue? YES - it is a bit of work, but I think that it should be done at somepoint The problem is all the #defines in ls_generic cause namespace clashes. M$oft is half to blame here in that they assume you are in a Windows enviroment and insist on bringing in almost the entire header tree when you might only need one structure. I believe the proper thing todo is eventually move LaRCSim into a C++ class and use namespaces. This however is a fair amount of work. BTW this all stems from the libstdc++ that ships with the gcc-3.X compilers which enables the WIN32 threading model. Currently this is still a beta release and trying to find a good solution to this namespace pollution is one of the things keeping gcc3.X beta for WIN32, so this problem may disappear on the MingW32 compiler but having all tose defines exposed is just 'begging for trouble'. I think we have just been lucky that we got away with them as long as we have. Also, does the Windows binary from www.flightgear.org support the LaRCsim/UIUC stuff? Yes, I am sad to say :-( I will work on correcting this by reverting to the older 2.95 compiler when I get a chance should be within the week as I have discovered that I still need it for some other projects too. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flightdeck-UI Project Homepage.
FYI http://openlight.com/fdui/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Curtis L. Olson writes: Yes, if you use an int and track time in increments of 1 / 1,000,000 then you get about 30 minutes before you hit an anomaly. This bug caused problem in the past such as radio station searches to only happen every other 30 minute period, or panel text to stop updating. You have to be very careful to think through the amount of possible time accumulation when doing the math. This is a subtle bug because when you are developing code, you rarely test for more than a few seconds at a time. That said, I haven't looked closely to see if any of these problems are in the latest code ... but it's something to keep in mind when dealing with time sensitive code. Yep there is a problem if you try to run a FGFS session on a Windows box much over 49 days :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Curtis L. Olson Norman Vine writes: Yep there is a problem if you try to run a FGFS session on a Windows box much over 49 days :-) I wouldn't know anything about that, and far be it from me to blatantly bash windows, but if you manage to have your windows box run that long, I'd definitely recommond that you also consider buying lottery tickets, ask your boss for a big promotion, and try googling for britany spear's home number; that kind of luck just doesn't come around every day. :-) Hmm... I can''t rememeber crashing this box in a long time and if it wasn't for needing to reboot in order to access the CVS ... Oh right I don't need to do that anymore :-) So remind me to send you one of these in a cople of months :-) 510 src $ cat /proc/uptime 263847.38 237946.24 511 src $ uname CYGWIN_NT-5.0 Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Curtis L. Olson I actually have a rcs/sccs book sitting on my shelf (good thing I proofread my messages ... I originally wrote sitting on myself which is close, but doesn't quite convey the same thing.) I bought it because it advertised a cvs section, but the cvs info turned out to be only a beginner level intro and nothing that useful for me. The best things are sometimes free http://cvsbook.red-bean.com/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external model positioning
Curtis L. Olson writes: I am working on interfacing an external flight model to FlightGear via the network. This particular code reports an altitude of zero/0.0f when the wheels are resting at sea level. The c172 3d model is drawn so that it's center of gravity is at the reported altitude. Also the pilot view point is also relative to this altitude. This means that on the ground, the out-the-window view point is just a few inches above the pavement. And also the 3d model is sunk into the ground. What do I need to do to get the pilot view point and the center of the 3d model up to the correct altitude? It used to be --prop:/sim/model/z-offset=offset in meters but I guess it's --prop:/sim/model/offsets/z-m=X now, but I am not sure if this info is actually available At least I couldn't find it with the httpd interface the closest thing I got was the path name to the model tempting-to-say-data-should-actually-be-in-C'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error compiling FG 0.80
Sydney Weidman writes: I was just trying to compile the latest release of FG, but I got a bunch of errors. I notice the errors involve gcc 3.2 stdc++ headers, so maybe I have used an unsupported version of gcc. Some compiler error messages follow. Thanks for this entertaining and interesting software. Regards, Syd. Making all in Airports make[2]: Entering directory `/home/gnome2/working/FlightGear-0.8.0/src/Airports'g++ -g -O2 -L/usr/X11R6/lib -o gensimple gensimple.o libAirports.a -lsgdebug -lsgmisc -lsgxml -lmk4 -lz -lm libAirports.a(simple.o): In function `FGAirports::FGAirports[not-in-charge](std::basic_stringchar, std::char_traitschar, std::allocatorchar const)': /usr/include/c++/3.2/bits/basic_string.h:781: undefined reference to `c4_Storage::c4_Storage[in-charge](char const*, int)' libAirports.a(simple.o): This indicates that is not picking up the metakit library -lmk4 Is it installed Is your installed version compiled with g++ 3.2 The C++ ABI changed with this release Be sure to read http://www.flightgear.org/Docs/FlightGear-FAQ.html#5.1 HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: Norman Vine writes: I am still not convinced that your tile is actually loaded though and don't really know the 'best' way to check for that given the 'lazy' loader. I can think of two options: 1. we can attach a separate deferred model queue to each deferred tile, so that the queue is not run until the tile is actually loaded; or 2. we can add an option to force tile loading. Option #1 is probably more efficient, but option #2 could be useful for other types of requirements (such as determining the elevation of a distant ground station). I take it you have determined that the tile is not actually loaded ?? Knowing this is important in that there may be a flaw in the hitlist routines if they are in fact loaded !! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: I would like to make it possible to specify the elevation of static and shared objects AGL as well as ASL, but for that, I need to know the elevation ASL at a specific location (not the current view position). I have taken a look at the fgCurrentElev() functions in hitlist.cxx and (I think) supplied the right parameters, but I'm getting no intersection. The problem location is tileentry.cxx -- search for OBJECT_STATIC to find the right chunk of code. Somehow, there, I want to be able to determine what ground elevation is at the lon/lat supplied. this doesn't directly answer your question but Seems to me that all OBJECT_STATIC information can and should be determined at scenery creatation time not during Flight Time. ie STATIC objects should be created with offline tools This is probably easiest to do by just adding a variation of the magic-carpet mode to teleport to the positions listed in a file and to create a new file with the information requested If you use a 'minimal' visibility this will be quite fast. One could turn off all the actual rendering too but I think that the visual feedback night prove useful This could even be extended to where this new mode read a list of scenery files to read which needed the 'elevations' plugged in and rewrote these files in a batch operation Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ASP PHOTO GALLERY
FYI http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Documentation
Jon Berndt writes: Jon S Berndt writes: Does anyone have any experience with moving from Doc++ to Doxygen? I'm thinking of making the move. Doxygen seems to be what I had hoped Doc++ would become, but seems to have stalled. It looks like many of the identifiers are the Doxygen started life as Doc++ so just % doxygen -g see below before running this command % doxygen Doxyfile ... ... I take it you have used Doxygen? Nope :-) I guessed that given it's lineage the standard invocation proceedure might 'just work'. and it did ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] STL and vectors
Erik Hofman writes: David Megginson wrote: Erik Hofman writes: Can someone explain me how to erase a member from an STL vector? I've tried several things, but it looks like it isn't removed anyhow. You need to use erase(), passing in an iterator (yes, I know, I hate STL iterators too -- another idea that was just a little too clever). Is there an easy way to get an itterator from an indexed value (e.g. value[1]), or do i need do to everything with iterators then? how about vector v; v.erase(v.begin()+index); Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Looking for property list - Q#4
David Megginson
Norman Vine writes:
But there are many Fixed Lists of properties for example
PitotSystem::init ()
{
_serviceable_node = fgGetNode(/systems/pitot[0]/serviceable,
true);
_pressure_node = fgGetNode(/environment/pressure-inhg, true);
_density_node = fgGetNode(/environment/density-slugft3, true);
_velocity_node = fgGetNode(/velocities/uBody-fps, true);
_total_pressure_node =
fgGetNode(/systems/pitot[0]/total-pressure-inhg, true);
}
and I can't add to this list without creating another 'C' variable
You will soon, however. We need to be able to support multiple
systems (like vacuum pumps), so once we have all of the initial
versions running, you'll be able to specify what input and output
properties each instantiation of a system (or instrument) uses.
Sure, but I am willing to bet that each of those systems will have
a 'hardwired' set of 'possible' nodes and that there will be a vector
of the system's instances so will still be a 'C' interface definition.
We should have documentation as to what these HARD CODED terms are.
Using the 'property browser' is a great way to inspect a running
instance of FGFS but is a poor excuse for the 'Official
Documentation' of the 'properties'
I think that's a great idea, as long as we recognize that it will be
perpetually a work in progress.
In what way is this any different then the 'C' code ??
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ASP PHOTO GALLERY
Alex Perry writes: Norman Vine writes: http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html Of course, for the non-free images which are dirt cheap on a per airport basis (given the scripting above), I note the absence of any licence comments on the site ... leading to the question of whether I could give my custom scenery patch to others afterwards. You should definately check the license info before purchasing but in general the 'purchaser' of a US product has full rights to the product after purchase unless specifically stated otherwise. FWIW - I was involved in a 'minor' investigation 10 years or so ago concerning my distributing source for a program I had purchased from NASA and it was 'deemed' that I was completely within my 'rights' in that NASA had placed no 'restrictions' on redistribution This is 'doubly' true for 'map' related data as it has ALWAYS been a policy of the US that freely available map data is in the national 'economic' interest. Note this is a MUCH different philosophy then other countries. Recently due to cost issues the US has started to charge a 'distribution fee' for data gotten from government agencies but this does not change the basic US philosophy about free map data being 'good' for the economy Also note this does not apply to 'classified military map data' but only that data which is 'officially distributed' either from non military sources or is expressly designated as 'non-classified' AFAIK it would take an act of congress to change this 'basic' philosophy as it was an act of congress that established this policy 200+ years ago Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] VASI
Curtis L. Olson writes: What I'm looking for is somethingn to the effect that a VASI light bar is a row of n lights spaced x meters apart. VASI light bars are spaced y meters apart along the length of the runway. And if I'm really lucky I'd get the difference in degrees in alignment between the two/three light bars. I.e. bottom bar turns red at 3 degrees, top bar turns red at 3.25 degrees (or something like that.) These should all be governed by federal standards, and those standards should be online somewhere. maybe this would help http://www.faa.gov/aim/Chap2/aim0201.html#2-1-1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] VASI
Curtis L. Olson writes Norman Vine writes: Curtis L. Olson writes: What I'm looking for is somethingn to the effect that a VASI light bar is a row of n lights spaced x meters apart. VASI light bars are spaced y meters apart along the length of the runway. And if I'm really lucky I'd get the difference in degrees in alignment between the two/three light bars. I.e. bottom bar turns red at 3 degrees, top bar turns red at 3.25 degrees (or something like that.) These should all be governed by federal standards, and those standards should be online somewhere. maybe this would help http://www.faa.gov/aim/Chap2/aim0201.html#2-1-1 That gives a good overview of how the VASI works from a pilot's perspective, but it still doesn't show exactly how the vasi bars are positioned relative the threshold, the runway edge and each other. And it doesn't show details of the bar itself. I assume a VASI bar is a row of individual lights, but how many? How far apart are the individual lights in the bar placed? I am not sure that there is a 'regulation' that states this exactly my reading of the above link indicates that things vary on an airport by airport basis in that local conditions vary and it is the overall 'effect' of the lights and the 'pathway' they mark that is regulated My reading of this australian document seems to confirm this http://www.casa.gov.au/download/CAAPs/drome/89t_1.PDF here is a link for aeronautical survey related documents http://www.ngs.noaa.gov/AERO/aerospecs.htm#FAA405 these are the surveys that must be made in order to get FAA approval for an airport there are photographs of several different 'conforming types' linked at the bottom of this page HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] environment mapping question
Christian Mayer writes: Curtis L. Olson wrote: Here's a question I'll throw out to the list on my way to bed. I'm working on VASI/PAPI type lights tonight and am running into a problem. I'm using environment mapping with the normal aligned along the desired approach path. This almost works as expected except for one major problem. The texture coordinate that is generated is ***highly*** dependent on the object's position on the screen. Thus, on approach, simply pitching up or down radically changes the color of the vasi light, even though the relative view position changes very little. Something to take cara about with environment mapping is the orientation of the normal vector. If you've got it wron (i.e. pointing away from you not towards you) you'll see the singularity - and thus quite possibly rapid changes. I haven't played much with enviroment mapping yet but I was wondering if there needed to be a transform on top of each light that in essence moved the lookat vector to point directly at each light instead of being aligned with the normal FGFS lookat vector. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
David Megginson writes: That's a good point. The other option would be to cut down the Hz for the AIs -- how low could we make it before the autopilot lost control -- 10Hz? 2Hz? you can easily experiment for yourself by playing with the /sim/model-hz value good luck ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
David Megginson David Luff writes: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. fgfs --fdm=magic --disable-panel --enable-hud --fdm=ufo Its nice to have reverse Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
Curtis L. Olson writes: David Megginson writes: David Luff writes: I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. fgfs --fdm=magic --disable-panel --enable-hud There was a time when if you paused the sim, it would dump the local lon, lat, elev to the console so you could copy/paste that into some other file you were working on, but I don't think that feature has survived the peer review process. re-Invention-is-a-wonderful-thing-to-behold'ly yrs norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Init-order problem fixed for *-set.xml files
Curtis L. Olson writes: David Megginson writes: I just checked in changed to fix the init-order problem for *-set.xml files. My solution was blunt but effective. I simply parse all of the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice -- once before loading the *-set.xml file, to make sure the correct aircraft is picked up, and once afterwards, to allow the command-line to override anything that was changed. The problem manifested itself when other aircraft (such as the 747) picked up the default aileron trim setting for the JSBSim 172. By the way, does anyone still use a system.fgfsrc, or can I remove that old code? I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. PLEASE DO NOT REMOVE the .fgfsrc option until such time has we have a 'options editor' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold FWIW - I put a LOT of effort into getting the navigational parts of FGFS working this included a lot of 'gentle nudging' and a lot of code and I RESENT having been force to used COOKED variables when I might not always always want to. FYI there was a time when Curt and I were probably the only two people that understood at least 90% of the code and we spent a LOT of energy and time trying to teach and/or explain to others how it all worked. I certainly didn't do that expecting those whom we 'enlightned' to change the code such that it was nigh onto impossible to use it in ways that I wanted too. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross Curtis L. Olson wrote: Just a couple thoughts to consider. We are looking at 16-20,000 airports so we couldn't stuff them all in a single directory. Even splitting them into subdirectories by first letter probably isn't enough. There are 17073 airports in the current database. Splitting on first letter only, the largest is (no surprise) 'K', with 2161 airports. On a lark, I created such a directory containing all the US airports. The creation process was relatively slow -- 20 seconds or so. But once the files are there, access to them is very fast (a few tenths of a second). This was true even after I was careful to flush the buffer cache by cat'ing a different disk to /dev/null, if the stuff is in the cache, of course, access is milliseconds at most. If you think about it, 2000 is about the same number as the number of device files in /dev, and no is complaining about performance issues there. And remember, we can split on the first two bytes (K/S/KSFO.xml) without any more difficulty (one extra line of code) and the whole problem goes away. Also, consider that with zillions of tiny files, much space is wasted on the file system which hits people in the windows land the hardest it seems because they often have a very large minimum file size. This is a good point, actually. Almost all the Linux filesystems use a 4k block as the minimum allocation unit*, and I presume NTFS is similar. Still, though, 4k per airport is still a tiny fraction of the size of the scenery. Remember that with a file per airport, there is no need to have the whole airport database in the base package. You can download the airports along with the scenery. The windows issue is, I think, true only on very old FAT32 variants. I'm pretty sure the block size limitation went away at the same time the 2G limit did, no? Everything from Win98SE on should be fine, I believe. Any windows users want to comment? Certainly anyone running XP won't have this problem. For the Index I reccomend making a single trie on the airport name that stores the bucket of the actual airport data file which lives in the same spot as it currently does. Then In each 10x10 degree directory I propose that we have a KD-tree spatial index of the positions of each airport in that block. This 2 tiered approach should give lighning fast lookups to both airport by name and what airports are near by. The indexes should be binary and we should distribute the tools that rebuild them when they change which won't be that often nor take very long. The indexes chould be able to dump themselves as XML files to facilitate rebuilding them and for easy inspection. With such a scheme we should be able to access any airport and determine which airports are within some sane distance in much less then a few tenths of a second order of manitude less at least Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross writes: Norman wrote: [ ... indexing scheme involving spacial partitions and trees ... ] With such a scheme we should be able to access any airport and determine which airports are within some sane distance in much less then a few tenths of a second order of manitude less at least My point was that a really simple one-file-per-airport scheme (you basically can't get any more maintainable than that) would work with adequate performance for typical usage. My scheme also uses one file per airport PLUS two fairly advanced yet relatively simple indexes for lightning quick seaches. I hope you note that I used a trie which is just a binary implementation of the individual file basd method that you proposed http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Trie.html And there is a performance issue here with searching radio frequencies for stations within range hence the spatial index for each 10x10 degree block. I believe that my proposal is a 'Dr Pangloss' type solution * Well, and that it involves a 3rd party C++ library that insists on installing itself as a shared library % cd $metakit % ../unix/configure --disable-shared % make core % make install best-of-both-worlds'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Init-order problem fixed for *-set.xml files
David Megginson Norman Vine writes: I think preferences.xml and the aircraft-set.xml files pretty much cover any functionality that was intended to handle. PLEASE DO NOT REMOVE the .fgfsrc option until such time has we have a 'options editor' I have not suggested doing so; I'm suggesting only system.fgfsrc Apoplogies, I should have said system.fgfsrc also FYI - is the the equivalent thing as ~/.fgfsrc for Windows users Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson writes: Norman Vine wrote: To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. Yes thank you for finally making doable but it did take a lot of simulated aluminium just _raining_ out of the sky ... and a lot of rewriting code that just plainly ignored the the 'true' values that were there but enough cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson Norman Vine writes: I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Sure, and we make both available through the property tree. If you want to know the exact true heading, look at /orientation/heading-deg; if you want to know the indicated compass heading, look at /steam/whatever, soon /instrumentation/magnetic-compass/indicated-heading-deg. No one took away information that you had before, and the HUD still displays the exact heading if you're interested. On the other hand, it's just silly to build a control panel that looks like a real one and not have it act that way -- why waste all the texture memory to simulate analog gauges when the HUD can do the job better? Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold I have no objection to a new autopilot module if someone wants to build it; the current one is fine but it's showing its age a bit. That said, it shouldn't be hard to make it configurable to use different property sources for specialized applications like your (Norm's) GIS work. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FWIW
Cameron Moore * [EMAIL PROTECTED] (Norman Vine) [2002.10.13 00:02]: but FWIW I just cheat http://www.crazy-compilers.com/bridgekeeper/ Interesting stuff. I can't help but point out that bridgekeeper is written in perl. ;-) But of course !! It has to parse a Perl program :-)) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson Geoff Reidy writes: The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), This most likely relates to freeing tile memory (i.e. moving old tiles out of the cache and reclaiming their memory.) This was never a fast process and could result in frame rate glitches. When David added random ground cover objects, the problem got *really* bad because the scene graph structure of a tile got a lot larger. David and I worked really hard to optimize that, and I further worked on a partial tile free-er so we could spread the load out over multiple frames. This should have been all fixed by version 0.8.0 so that you should see very little frame rate impact when you cross a tile boundary. What version of flightgear are you running? The same thing happens for me with both Cygwin gcc 2.95.2 and MingW gcc 3.2 both using Doug Lea's malloc routines which I believe is what most Linux distributions use CVS version of Cygwin Implemeting the thread support seems to make this even worse but this is a totally unscientific observation FWIW This is bad enough so that any flight covering more then 1000km or so is futile for me as once the condition starts it reoccurs quite frequently Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson writes: Norman Vine writes: The same thing happens for me with both Cygwin gcc 2.95.2 and MingW gcc 3.2 both using Doug Lea's malloc routines which I believe is what most Linux distributions use It might be worth verifying that my partial tile free-er routine is actually running. If it's not running or is being bypassed some how, then the condition you are reporting is very understandable. If it is being run, then it's not doing it's job correctly and should be looked into. You can also tune how much of the tile is deleted per frame. I have twiddled the amount freed each time before but I see the code has changed a little since the last time I tried this. FWIW - I ended up assuming that my poor little 256 meg machine just wasn't big enough to run FGFS anymore under Windows as it appears to be memory related disk thrashing that is killing me. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wright flyer
Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: Your Wright flyer model is really starting to look sharp! Good work. :-) It looks great -- this is the first time I've tried it. With the mouse, at least, it's also quite easy to fly -- I had to work hard to make it overrotate. Thanks. It's getting there. I'm still trying to figure out from Orville's description how the elevator mecahnism works (for animation). Might need to go down to Owl's head again to take a another look at their replica. Still thinking about wing warping... (hints to the animation code guru :-)) look at the PLIB exposer demo for how the bones go together :^) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Boeing Unveils Bird of Prey Stealth Technology Demonstrator
FYI http://www.boeing.com/news/releases/2002/q4/nr_021018m.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
Andy Ross writes: John Check wrote: main.cxx:153: void (*glPointParameterfvEXT)(unsigned int, const GLfloat*) /usr/X11R6/include/GL/gl.h:2520: glPointParameterfvEXT(unsigned int, const GLfloat*)' OK, this one looks kinda wrong. Our code is defining its own copy of the glPointParameter function pointers, when they've already been declared as regular functions in gl.h. What's the purpose here? All of the declared extensions are supposed to be defined in the ARB glext.h header, I believe. User-level code shouldn't have to play this kind of game anymore. This is true in the non-windows world, but since the distributed M$oft OpenGL is version 1.1 this is a major pain to do easily in a cross platform way. FWIW making this transparent is what the extgl package in the Clouds3D directory is trying to do. Perhaps it is time to bring up cross platform OpenGL extension handling on the PLIB list. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry Alex Perry writes: I am not aware of a GPS unit that is able to report heading rather than track, but as far as I know, only cost is the driving factor there. http://www.intnlind.com/trimble/ms860.html I should have said aviation approved. Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). AFAIK You don't need DGPS for heading I understand that this kind of instrument might not be desirable in a Flight Training Device yet but there is certainly no reason not to model it in a general purpose flight simulator as it is the future and I bet it or its equivalant is in the air already if for no other reason then to gather data inorder to get 'aviation certification'. Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). Norman responded: AFAIK You don't need DGPS for heading I don't see how you'll manage heading reliably without going differential. The two links you pointed out, for example, were differential systems. The more separation between the antennas the better but a 'relative to each other' a multiple antenna system locked to the same 'clock' for each satelite is its own differential system with respect to the differance in the SAME signal recieved at the two locations. Not this is only valid for the relative 'position difference vector' which just happens to the directional vector between the antenae eg heading :-) absolute measurements such as position and/or elevation are a different story in other words since all antennas are receiving the same error the error is nullified in relative position calculations cheers norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson Norman Vine writes: IMHO we should take advantage of our existing bucketing by fans and put the LOD nodes at the 'leaf's branch' level instead of the individual triangle level. Just doing this would save us LOTS of nodes and should speed things up a bit and not require YAN set of branches :-) It's not a bad idea, but a single leaf can cover a very large area; using the individual triangles cuts out at least some of the popping effects. If anything I would think that this would cause objects to be drawn earlier hence decreasing the popping effects Also even though we probably would be drawing more objects I wouldn't expect much of a hit in that there would be lot fewer culling operations Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes: Norman Vine writes: How big is the hit if you simply delete a higher-level node and let plib delete all of the branches and leaves underneath automatically? My guess is that we would gain more by having the random objects connected to the leaf rather then to the individual triangles. Well a leaf by definition is the end of the line. If there were more kids connected to a leaf, then it wouldn't be a leaf, it would be a branch. Only leaves can contain geomotry, and only branches can have kids attached to them. Sorry .. of course I meant the Leaf's branch :-) Ultimately, what we need to do is deepen the stucture. Rather than having 1 parent with 4000 kids, we need a parent with say 50-100 sub branches, and each of those sub branches has 50-100 leaf nodes. Each ground cover object needs to be placed an oriented so it needs an individual transform node above it. Things like trees are also rotated to face the viewer so they need an additional cutout node (i.e. billboard) to do this. This is a lot of additional work, but one idea would be to divide up a tile into 8x8 or 10x10 smaller chunks. Each chunk would have a branch node under the top level node (64-100 sub branches.) Then each random object would get tossed into the appropriate sub branch based on it's location in the tile. This would keep the kid list sizes from becoming insanely large and would also benefit things like view frustum culling. This is basically what I was suggesting Currently there is a LOD node for every material for every triangle :-( IMHO we should take advantage of our existing bucketing by fans and put the LOD nodes at the 'leaf's branch' level instead of the individual triangle level. Just doing this would save us LOTS of nodes and should speed things up a bit and not require YAN set of branches :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes:
David Megginson writes:
What I meant is that you use your scheduler a little higher up the
scene tree. The dynamic objects, for example, are under separate
branches for each scenery triangle; just deleting the top-level
triangle branch should be good enough, rather than recursing right to
the bottom of the tree and picking off the individual leaf nodes.
Unfortunately, plib doesn't work quite as you'd hope/expect. If to
remove all kids it does:
void ssgBranch::removeAllKids (void)
{
ssgEntity *k ;
while ( ( k = getKid ( 0 ) ) != NULL )
removeKid ( k ) ;
}
This means that the code finds the pointer to the first kid and
removes it individual (requiring a linear search for each element.)
here is some experimental code I have been playing with
which I think works and should help a biit
maybe others could test, and improve it etc.
before I submit it to PLIB
PLIB / src / ssg / ssgList.cxx
#define NHV_TEST
#ifdef NHV_TEST
void ssgList::removeAllEntities ()
{
while ( total 0 )
removeEntity ( (unsigned int) (total-1) ) ;
}
void ssgList::removeEntity ( unsigned int n )
{
--total;
if(total-n)
memmove ( (entity_list[n]), (entity_list[n+1]), sizeof(ssgEntity
*) * (total-n) ) ;
if ( next = n )
next-- ;
}
#else
void ssgList::removeAllEntities ()
{
while ( total 0 )
removeEntity ( (unsigned int) 0 ) ;
}
void ssgList::removeEntity ( unsigned int n )
{
memmove ( (entity_list[n]), (entity_list[n+1]), sizeof(ssgEntity *) *
(total-n-1) ) ;
total-- ;
if ( next = n )
next-- ;
}
#endif
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Andy Ross writes: David Megginson wrote: How big is the hit if you simply delete a higher-level node and let plib delete all of the branches and leaves underneath automatically? Probably equivalent. The overhead is usually in all the per-chunk bookeeping, not the function calls. We could try playing games with operator new, I suppose. We know for a fact that all these objects will be deleted at the same time, so we can in theory do much better than a general purpose allocator. FWIW - I started looking into this a while ago and was thinking of having a specialized 'Pool allocator' that never really deleted the random objects but placed them on a 'freelist' from which they could be doled out. I think that this would be a big gain but probably not worth the energy until we have stabalized on a 'better' chunked data structure Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: setting the heading indicator from a GPS
David Megginson writes: I little while ago, I made a posting asking how a pilot in the Canadian far north (where magnetic compass readings are not useful) could reset the heading indicator in flight using a single GPS receiver. The answer is actually fairly simple, if you don't mind a brief course excursion: turn the plane until the ground speed reading on the GPS receiver maximizes or minimizes, and then the GPS track will be almost identical to your heading since you'll have a pure headwind or tailwind. To allow for lags in the GPS, Nit -- to allow for lags in the GPS computer's track computation Most GPS's have a 'track' and a 'heading' feature. Where the 'heading' is usually determined from a piece of the 'track' This is computed from the X most recent locations or after at least X distance has been traveled. The 'X' values above are ususlly 'user tunable' even in the cheapest of sets these days. Note that as someone who made a living relying on precise navigation for many years the GPS 'heading' determined in this way is to be trusted when autopilot is engaged ONLY after a considerable period of time or distance was traversed and no course changes were made Also note in my experience that this reading is NOT to be trusted when not under autopilot control unless you have a GOOD visual target at a distant range to help manitain a constant course. Also note that the heading from a GPS I was refering to previously is an entirely different beast and will give an instantaneous accurate reading YMMV but the prudent navigator . Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes: Curtis L. Olson writes: However there is still an issue to worry about. The random ground cover code can create thousands of objects which means a branch node in our scene graph with thousands of kids. plib is not exactly efficient at deleting kids and even if you know the index, it converts this to a pointer and then later needs to do a linear search to find the index again. I've submitted a patch to the plib list to help with this, but I've never had good luck getting any plib code to change. How big is the hit if you simply delete a higher-level node and let plib delete all of the branches and leaves underneath automatically? My guess is that we would gain more by having the random objects connected to the leaf rather then to the individual triangles. This would mean that the culling would not be as fine grained but the bookeeping overhead would be a LOT less. Of course the actual result of this change would vary depending on processor speed and GFX card but as the GFX cards are always getting better I believe this would eventually always be a WIN as long as we stay with our 'tri-fan' vs a 'tri-strip' approach in that 'fans' are usually 'optimium' for culling etc. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: setting the heading indicator froma GPS
Tony Peden writes: Hmm, curious. How can you get anything but ground track from a single receiver with a single antenna? You can't, but ... your ground track is a 'heading' if ... you keep a steady course. This is not as hard as it sounds with a GPS because most units allow you to program in a waypoint and then will give you a 'cross track error' updated at every fix so you can adjust things. Yes this begs the question as to what about wind and drift so I guess I should qualify that as to be 'course made good' instead of 'heading' but in practical terms it is the 'course made good' that matters apologies for the 'nautical' terminology and reference but this is an excellent read and 'current' for a ship has the same effect as the wind on a 'plane' when considering heading http://www.irbs.com/bowditch/ wish I knew of a book that covered using a GPS as well as this does a sextant that I could point at Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AECHELON TECHNOLOGY - IMAGE SERVER
FYI http://www.aechelon.com/media/images_psi.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 13.49 Maneuvering and Control of Surface and Underwater Vehicles, Fall 2000, Co
FYI A lot of good stuff here much of it is directly applicable http://ocw.mit.edu/13/13.49/f00/index.html The book though aimed at the marine enviroment should be a good read for any control-simulation engineer Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: Curtis L. Olson writes: I think Norman was talking about some sort of automated magic carpet mode. Exactly That would be slow, use minimal visibility and turn off any calls that actually render anything, ssgCullAndDraw, pre(post)RenderSky ect, and it should be 'quite fast'. but it would work at first. The problem is that we'd have to rerun the whole thing whenever the base scenery changed. Hmm.. Reruning the static scenery tools when the static scenery changes almost seems like a logical thing todo It will be a lot more flexible and simpler to allow placing objects on the ground automatically, once we work out some of the problems. David - You still haven't answered my question about your problem Is the points containing tile loaded when you are trying to get it's elevation ?? If it isn't then you just need to load it before making your query to the elevation routine and then it should just work using a similar method to what Jim uses for Tower placement If there is still a 'chicken / egg' problem then I guess you will need yet another queue similar to the 'defered model queue' but I suspect that just adding the dynamic objects into the DM queue might suffice hard to tell with out actually seeing the code you are trying to use But IMO this is static scenery and should be processed offline when at all feasable as we already have a 'stutter' issue and FGFS itself with proper tuning as above is IMO the logical 'filter' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
David Megginson writes: Instead, we should set the appropriate switches to 'on' in preferences.xml or c172-*-set.xml so that the user can override. For the starter, a default to 'on' is clearly not what we want. NIT *-*-set.xml so that the user can override. The Sim is more then a C172 simulator Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
David Megginson writes: Please remember that FlightGear is not just a visualizer for batch-mode aero runs -- people use it to fly interactively. NIT: Please remember what it says on our Home Page The FlightGear project is working to create a sophisticated flight simulator framework for the development and pursuit of interesting flight simulator ideas. We are developing a solid, basic sim that can be expanded and improved upon by anyone interested in contributing. OOPS -- I see that this has changed too. The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing. Can't find the CVS log entry but it is relatively recent http://web.archive.org/web/20020124173417/http://www.flightgear.org/ Hmm... Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson Norman Vine writes: I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. http://gps.faa.gov/Programs/WAAS/waas.htm Norm, Norm, Norm -- I'm very disappointed. You're the one who has spent the most time drilling into everyone's head that GPS receiver readings are *not* the same as true values. David David David You rewrite history well all the best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Simon Fowler writes: What about simply putting all the airport files in the scenery, and having a script that searched through the scenery directories for all the *-apt.xml files and built/updated a set of indexes from them? That keeps the files in the right place, and gives the indices needed to get fast lookups based on whatever criteria are needed. Sounds good to me Now we just need to figure out what we want for indices The way I see it we have two radically different needs 1) Search by name 2) Search by location 1) is easy and we could just use metakit or any other disk based indexable file I have suggested using a trie 2) is a little more complicated but we allready have a good start if we leverage the Scenery directory structure I suggested using a quadtree for each 10x10 degree block but there are spherical indexing methods that might be better in that there is no cos(lat) shrink factor to account for when doing range lookups. Here is a link to a good one http://www.sdss.jhu.edu/htm/implementation.html note this package is near optimum for a show all points within X distance when on a sphere and should be great at keeping an updated list of radio frequencies that were within range at 'altitude'. This is not a trivial task Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
David Megginson writes: Norman Vine writes: 2) is a little more complicated but we allready have a good start if we leverage the Scenery directory structure Agreed. I suggested using a quadtree for each 10x10 degree block but there are spherical indexing methods that might be better in that there is no cos(lat) shrink factor to account for when doing range lookups. Remember Knuth's (?) warnings about premature optimization, FWIW IMHO We really should move the entire scennery DB into a spherically oriented scheme. It would be quite easy using the spherical indexing method in the link that I posted and then we wouldn't need any index other then the directory tree and-you-could-fly-over-poles'ly Norman Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross Right. But this indexing of nearby objects can be done in memory (since the set of nearby objects is already available via the tile set). There's not need for anything fancy on disk. FGFS should be able to answer simple flightplan questions like I am leaving from KSFO flying to KLGA show me all airports that are large enough to handle a 747 within 100 miles of my flightpath. Indexing makes this trivial Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some little bugs report from an enthusiast new user...
David Megginson Tommygio writes: 1) The swtch --cloud-disable disables the default cloud layer, but not the puffy effect at the layer altitude. OK, I've just fixed that -- the changes will appear in CVS shortly. 2) In the chase view with the default airplane, the cockpit's textures can be seen throught the wings. I think this problem started when the 3D clouds were added, but I'm not sure. If we are refering to the 'opaqeness' when flying through a 'layer's altitude', then this has been a long standing issue. That I kept meaning to look into Thanks Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wright Flyer
Jim Wilson writes: Hmmm... I did a google on spirit level wright flyer and nothing came up. Any idea what it looks like? Probably like one oops two of these one aligned with the wing and one aligned with the body http://www.stanleylondon.com/inclinometer.htm Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Numeric Terminology
David Megginson writes: Are there simple technical terms to distinguish the digits on the left side of the decimal point from those on the right? whole part . decimal part ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt I've got a few minutes to spare this evening, so I'm going to try again to build the latest development flightgear. Questions: 1) I plan on using the latest bleeding edge flightgear sources from development CVS. Which base package do I download? 2) Does the base package from #1 (above) work with the latest simgear and plib? 3) Any issues with Cygwin and trying the above approach? If you are using a VERY recent cygwin which BTW is VERY GOOD make sure you do this first % export CC=gcc-2 % export CXX=c++-2 so as to use gcc-2.95.2 There are some issues with the STL3.2 that is shipping with WIN32 I believe most easily solved by adding #if (__GNUC__ == 3 __GNUC_MINOR__ = 2 __CYGWIN__) # include iostream #endif to the top of simgear/compiler.h Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: OK, I *finally* got a chance this weekend to sit down and crank on FlightGear code. It's been a while. Attached are three patches for review. Complete files for Curt are available at: http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz. The first is just a port of an old 3D HUD patch to the new view code. This pans the HUD with the view, by pasting it onto a quad fixed in front of the viewer. Andy Your scrollable HUD is GREAT but can you make this a 'preferences' controled option so that we can keep the older HUD as there are many reasons for having a 'fixed' fullscreen HUD too. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Norman Vine wrote: Your scrollable HUD is GREAT but can you make this a 'preferences' controled option so that we can keep the older HUD as there are many reasons for having a 'fixed' fullscreen HUD too. There is a need for a 3D view-dependent HUD that mimics the behavior of HUDs in real aircraft. This patch is at least a hacked-up start in that direction. I submit that your patch is an additional mode and should be presented as such rather then BREAKING existing behaviour as IMHO is all to often what happens when someone decides to get involved with a piece of the code. Please don't take me wrong I think your 3D HUD is a valuable contribution but there are many reasons for a fixed 2D HUD. If you find that some of the existing 2D HUD code works for your 3D HUD great otherwise please write your own modules rather then breaking the existing ones Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
David Megginson writes:
Curtis L. Olson writes:
We artifically raise the lights a bit to attempt to avoid zbuffer
fighting. The formula is based on the altitude above ground and the
distance away ... however, it's rough and imperfect ...
I'm still working on understanding the code. First, you have
point_list geod_light_nodes
= calc_elevations( root, light_nodes.get_node_list(), 0.5 );
That means that the base elevation for each light is already 0.5m
above the runway. Does FlightGear have ssg do further elevation
adjustments at runtime?
void FGTileEntry::prep_ssg_node(
{
if ( gnd_lights_transform ) {
..
if ( general.get_glDepthBits() 16 ) {
sgScaleVec3( lift_vec, 10.0 + agl / 100.0 + dist / 1 );
} else {
sgScaleVec3( lift_vec, 10.0 + agl / 20.0 + dist / 5000 );
}
...
if ( rwy_lights_transform ) {
...
if ( general.get_glDepthBits() 16 ) {
sgScaleVec3( lift_vec, 0.0 + agl / 500.0 + dist / 1 );
} else {
sgScaleVec3( lift_vec, 1.0 + agl / 20.0 + dist / 5000 );
}
if ( lightmaps_transform ) {
..
if ( general.get_glDepthBits() 16 ) {
sgScaleVec3( lift_vec, 0.0 + agl1 / 2000.0 + dist1 / 1 );
} else {
sgScaleVec3( lift_vec, 0.0 + agl1 / 20.0 + dist1 / 5000 );
}
...
}
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
'Johnny' wrote:
Now, what broke?
The 2D HUD
You still haven't answered what it is you want,
The functionality of the 2D HUD
Seriously, name your requirement
Seriously, The functionality of the existing 2D HUD
and we can try to meet it.
Thank you very much for the offer but since the requirement is
nicely met by the existing code, there is nothing 'we' need to do
The 3D HUD code patch on the other hand needs to implement
the vestigial if(1) {...} in the patch to make the HUD display
a 'properties' controlled option between the 2D and the 3D
versions or provide an alternative method of getting the existing
2D HUD displayed.
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Norman Vine wrote: Andy Ross wrote: You still haven't answered what it is you want, The functionality of the 2D HUD Seriously, name your requirement Seriously, The functionality of the existing 2D HUD Norman, this isn't constructive. Andy The code used to draw the 3D HUD is by line count 99% the same as the 2D HUD yet you do nothing but berate the 2D HUD code IMHO - This is not constructive and clouds the issue which is You have stated that you have a hook in place that could be used to make a switch as to draw the 2D or the 3D HUD hased on a property yet you apparently have no interest in using it, in stead you continue to berate the 2D HUD code Note my initial message to this thread Your scrollable HUD is GREAT but can you make this a 'preferences' controled option so that we can keep the older HUD as there are many reasons for having a 'fixed' fullscreen HUD too. This is constructive And instead of saying Sure all you have done is berate me and and the code base that you are almostly completely adopting. Please tell us why you have objections to having a 2D and a 3D HUD since obviously they are very similar and would not take much effort to implement. constructive'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
David Megginson writes:
Andy Ross writes:
Norman, this isn't constructive. Here are some things I'm quite
certain you don't want:
+ A velocity vector that doesn't point where the aircraft is going
see the discussion about the horizon below as to part of the problem
+ HUD scaling that breaks with changes of aspect ratio
The scaling does NOT break with respect to aspect ratio
The display is designed to maintain 'local aspect ratio'
+ HUD scaling that breaks with changes of resolution
see preceeding comment
+ A horizon line that doesn't lie along the horizon
The horizon is in the middle of the screen
which is where the 'neutral' horizon should be
Someone has added a downward component
to the default 'Look Direction' which causes this
This is deflection is I believe a property thus tunable
Perhaps the best solution will be to fork between the actual HUD
(which should be 3D) and a screen-oriented 2D overlay module that uses
the same configuration code to display things like frame-rate,
network-connection status, etc. The beauty of configurability is that
if Norm still wants to see the HUD ladder, etc. in 2D, it should be a
simple matter to whip up an XML configuration file for it.
Yes the preexisting HUD code has been optimized to be just that a
screen-oriented overlay module and IMHO we do not want to lose
this module
Fortunately there is no need to fork
Someone just has to add a property as indicated below
void fgUpdateHUD( void ) {
//if(1) { // replace me with a property
if(fgGetBool(/sim/hud/use3d) {
fgUpdateHUDVirtual();
return;
}
* aside *
I submit that in general the 'proponent of a change' that will break
'long established' fgfs behaviour should consider ways to augment
rather then preclude the previous behaviour esp. in the case where
the vast majoriity of the code of the new behaviour is still the original
code such as this case.
FYI
The 2d HUD code is MUCH quicker then the Panel code and has
almost ZERO impact on framerate and IMHO should be kept intact as
the mechanism of choice for displaying general overlay information
either on the primary screen or on an external monitor. It is very useful
when using fgfs in 'magic mode' to inspect the scenery and I would
expect it to be the HUD of choice for other things like FDM monitoring,
flight reconstruction, inspector consoles etc.
Note this in no way precludes using Andy's 3D HUD patch which BTW
should also have ~zero impact on frame rate since all the real work is
still being done by the underlying screen-oriented module which hasn't
changed
Regards
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt writes: The simgear CVS retrieval still hangs. It is a known problem that using compression with the Cygwin cvs executable will cause an apparent hang FYI What actually happens is a failure to return after the operation has finished, this is indistinguishable from a hang from the client end cvs compression is the -z option Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I've got a few minutes to spare
David Megginson writes: Here is the approach they were flying (I think): https://www.americanflyers.net/ap/default.asp?t=downloadf=L\011L$100.PDF Here is a good mapping engine for the site http://www.dnr.state.mn.us/maps/landview_dhtml.html?mapsize=largezoomsize=2mapext=526604.2253058585+5243958.337905331+549193.77469 41415+5260891.662094669layers=lakes+dlgstln2+roads+gnisxpt3_ppl+none Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault
Michael Selig writes:
I am trying to compile and run the latest version of fgfs, but I have
hit a problem. When I run it I promptly get the error message
Segmentation Fault
There are no other messages.
(gdb) run
Starting program:
/home/m-seligSim/www-flightgear-org/./FlightGear/src/Main/fgfs
[New Thread 1024 (LWP 21926)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 21926)]
__strtol_internal (nptr=0x8833618 , endptr=0x85ccee0, base=139597448,
group=1065353216) at eval.c:36
36 eval.c: No such file or directory.
in eval.c
(gdb) bt
#0 __strtol_internal (nptr=0x8833618 , endptr=0x85ccee0, base=139597448,
group=1065353216) at eval.c:36
#1 0x0834b82a in SkyTextureState::SkyTextureState (this=0x8833618)
at SkyTextureState.cpp:47
Michael
Try protecting the call to sgClouds3d-Resize() in main.cxx
void fgReshape( int width, int height ) {
.
if ( fgGetBool(/sim/rendering/clouds3d) ) {
sgClouds3d-Resize( viewmgr-get_current_view()-get_h_fov(),
viewmgr-get_current_view()-get_v_fov() );
}
}
You will still need to run with the --disable-clouds3d option
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Not quite. The big change was making it resolution, FOV, and aspect ratio independent. I figured that if it had to be changed anyway, I might as well invert it to mean what it says. There is no way to keep the old scaling scheme and be view-independent at the same time, sadly. If this is true then there is no way we can maintain a 2D overlay, library which is what the existing HUD code is, with Andy's changes So the question is Is someone going to write a 3D HUD package, or am I going to have to rewrite a 2D overlay engine again. My guess is that whoever works on implementing a true 3D HUD would be better off starting with a new OO design much like the Panel code rather then kludging YAN hack onto the aged 2D hacks that comprise the existing 2D HUD code which BTW is no where near as bad as Andy's colorful language makes it out to be grin other-wise-he-woudn't-be-using-it'ly yr's / Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD
Jon Berndt writes: Is the HUD configurable at all? I mean via a config file or something? Symbology is different in the various aircraft -particularly spacecraft. If one wanted to modify the HUD symbology is this possible to modify without code, like the panel instruments? what in docs / README.xmlhud don't you understand :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: XML Question
Jonathan Polley writes: My end goal is to use XML to define the configuration files for a series of applications. The first application may have the most complicated configuration file. I need the file to contain type and instance declarations. I *think* that XMl may be a solution to my problem, but I don't have the experience that this group has. In the 30 seconds, or so, of free time that I have each day, I am reading through the O'Reilly book Python and XML (it is easier for me to do new things like this under python). If you are comfortable with Python You can define your objects in Python and then dump their XML representation :-) http://www-106.ibm.com/developerworks/xml/library/x-matters15.html?openl=810,t=grx,p=rpc Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
