Re: [Flightgear-devel] Upcoming v0.9.8 release
On Sonntag 16 Januar 2005 18:33, Martin Spott wrote: Curtis L. Olson wrote: Now that plib-1.8.4 is released, I'd like to push forward with the FlightGear v0.9.8 release. Does anyone have any changes that need to get put in before the release? Now that Mathias' patch is part of PLIB release maybe it makes sense to reanimate the crease tokens in the Nimitz- and probably other models. Just an idea, Vivian prepares a *very* good new Nimitz model. I just put out the crease tokens together with the addition of the in cvs missing textures to get a state where all what is in cvs, is at least complete and works well with current recommended libs. ... to have a consistent state when the release happens. I won't put any further work in the the current Nimitz. So stay tuned, it will really look great! Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and SimGear-0.3.8-pre1
On Freitag 24 Dezember 2004 12:00, Ronny Standtke wrote: It would be great if as many people as possible could download this pre-release and give it a try and let us know if there are any problems. After a long time not using fgfs I tested this version and run straight into a small problem: transparent wings. (see attached screenshot) I wasnt running fgfs for almost a year now but I am very sure that this problem didnt exist in older versions of fgfs. It was introduced with Erik's display list patch at the time the crease patch came up. Do you use a radeon and/or r200 chipset with the dri drivers? Nobody other complained and it seems to work with the nvidia closed source drivers. So I *guess* that this is a driver problem with the radeon/r200. But anyway, at the moment the c172 does not work either with the current data directory. From the data directory Aircraft/c172p/Models/c172p-int-02.rgb seems to be missing? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] includes in brackets ?
Hi, On Mittwoch 29 Dezember 2004 19:54, Martin Spott wrote: As you know I have limited C/C++ knowledge, but I thought I'd have at least a little bit ;-) Here comes While I'm digging through the sources in the hope to find the cause for some mislead header includes I wondered about notation of several include statements. To my knowledge system includes should be bordered by brackets: #include stdio.h and your own, private header files by quotation marks: #include atis.hxx Could someone please explain to me what is different for example in FlightGear/src/ATC/atis.cxx: #include simgear/compiler.h This is definitely not a system include because it stems from your very private SimGear installation. What did I miss ? Like Andy tells, that is a bit unclear. But you might look at that in the following way: You need to install SimGear as a prerequsite to flightgear. When you install a library the includes get typically installed into /usr/include (I assume --prefix=/usr) Once the library is installed, it is available on this system as well as system libraries and their includes. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Crease patch is in plib
Hi, The 'crease' patch to plibs ac3d loader is now in plib's cvs tree. Thanks to Wolfram Kuss! Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Carrier
Hi, Part of the carrier code is sent to Erik. The code seems to trigger a bug on irix. Therefore I have choosen to split the changes into smaller ones, which might be a good idea anyway. On *top* of the patch sent to Erik (I expect that to go in :), the following updated set of patches is available from ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier-20041121 Apply carrier-operations.diff to flightgears source directory. Put JSBSim-dropin.tar.bz2 into the JSBSim subdirectory. Apply data.diff to the data directory. Use the slightly updated FA-18.tar.bz2. For completeness, the patch sent to Erik is available with the groundcache.tar.gz on the same ftp server. User visible changes are: Mostly keybindings. Since H/h are already used for the hud. The h'O'ok is now controlled via O/o. To arrest the aircraft's launchbar at the cat user the L key (applying the brakes is no longer suffucuent). To arrest the aircraft the aircrafts velocity wrt the carrier needs to be zero. You will notice that the aircraft is fixed at the cat by a slight pitching of the aircraft. As usual apply flaps and thrust. Then pressing C will launch the aircraft. Non user visible changes: Much cleanup/code documentation. Put the groundcache into its own class. Little changes in the way the launchbar/holdback is modeled. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Small patches ...
Hi Erik,
I think we can go there step by step. And I have several additional patches
floating around here which might be worth anyway.
ai-jump-fix.diff:
The moving ai models will jump around realtive to the moving aircraft model.
I can see that with the carrier but others have noticed that too with ai
aircraft before.
The reason is that all SGSystems are called with a dt value which is not
necessarily a multiple of 1/hz.
In contrast, most FDM's use the _calc_multiloop function from FGInterface
which forces the time update to be a multiple of 1/hz for the FDM aircraft.
As a result, in the worst case, the FDM aircraft has moved nearly 1/hz seconds
further than the rest of flightgear (1/120sec*300kts that is about 1.3m).
That patch forces the time update to be a multiple of 1/hz.
carrier-controls.diff:
Add some controls required for carrier operations:
/controls/gear/launchbar
should be 1.0 if the launchbar is lowered, that means the aircraft should now
be arrested at the catapult.
/controls/gear/catapult-launch-cmd
Should be set to 1.0 when the aircraft should be launched from tha catapult.
Erik, could you please apply these?
Thanks!
Greetings
Mathias
--
Mathias Frhlich, email: [EMAIL PROTECTED]
Index: src/AIModel/AIBase.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIBase.cxx,v
retrieving revision 1.31
diff -u -r1.31 AIBase.cxx
--- src/AIModel/AIBase.cxx 16 Nov 2004 09:33:21 - 1.31
+++ src/AIModel/AIBase.cxx 18 Nov 2004 17:12:09 -
@@ -78,8 +78,8 @@
}
void FGAIBase::update(double dt) {
-ft_per_deg_lat = 366468.96 - 3717.12 * cos(pos.lat()/SG_RADIANS_TO_DEGREES);
-ft_per_deg_lon = 365228.16 * cos(pos.lat() / SG_RADIANS_TO_DEGREES);
+ft_per_deg_lat = 366468.96 - 3717.12 * cos(pos.lat()*SGD_DEGREES_TO_RADIANS);
+ft_per_deg_lon = 365228.16 * cos(pos.lat()*SGD_DEGREES_TO_RADIANS);
// Calculate rho at altitude, using standard atmosphere
// For the temperature T and the pressure p,
Index: src/AIModel/AIShip.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIShip.cxx,v
retrieving revision 1.11
diff -u -r1.11 AIShip.cxx
--- src/AIModel/AIShip.cxx 16 Nov 2004 19:48:09 - 1.11
+++ src/AIModel/AIShip.cxx 18 Nov 2004 17:12:09 -
@@ -84,9 +84,9 @@
}
// convert speed to degrees per second
- speed_north_deg_sec = cos( hdg / SG_RADIANS_TO_DEGREES )
+ speed_north_deg_sec = cos( hdg / SGD_RADIANS_TO_DEGREES )
* speed * 1.686 / ft_per_deg_lat;
- speed_east_deg_sec = sin( hdg / SG_RADIANS_TO_DEGREES )
+ speed_east_deg_sec = sin( hdg / SGD_RADIANS_TO_DEGREES )
* speed * 1.686 / ft_per_deg_lon;
// set new position
Index: src/Main/main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/main.cxx,v
retrieving revision 1.186
diff -u -r1.186 main.cxx
--- src/Main/main.cxx 20 Oct 2004 08:18:29 - 1.186
+++ src/Main/main.cxx 18 Nov 2004 17:12:16 -
@@ -240,6 +240,22 @@
real_delta_time_sec
= double(current_time_stamp - last_time_stamp) / 100.0;
+// round the real time down to a multiple of 1/model-hz.
+// this way all systems are updated the _same_ amount of dt.
+{
+ static double rem = 0.0;
+ real_delta_time_sec += rem;
+ double hz = fgGetInt(/sim/model-hz);
+ double nit = floor(real_delta_time_sec*hz);
+ rem = real_delta_time_sec - nit/hz;
+ real_delta_time_sec = nit/hz;
+ // Finally fool the _calc_multiloop function in FGInterface.
+ // That is, avoid roundoff problems by adding the roundoff itself.
+ // ... ok, two times the roundoff to have enough room for two operations.
+ real_delta_time_sec *= 1.0 + 2.0*DBL_EPSILON;
+}
+
+
if ( clock_freeze-getBoolValue() ) {
delta_time_sec = 0;
} else {
Index: src/Controls/controls.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Controls/controls.cxx,v
retrieving revision 1.12
diff -u -r1.12 controls.cxx
--- src/Controls/controls.cxx 10 Sep 2004 17:53:34 - 1.12
+++ src/Controls/controls.cxx 18 Nov 2004 17:12:10 -
@@ -81,6 +81,8 @@
gear_down( true ),
antiskid( true ),
tailhook( false ),
+launchbar( false ),
+catapult_launch_cmd( false ),
tailwheel_lock( false ),
wing_heat( false ),
pitot_heat( true ),
@@ -157,6 +159,8 @@
steering = 0.0;
gear_down = true;
tailhook = false;
+launchbar = false;
+catapult_launch_cmd = false;
tailwheel_lock = false;
set_carb_heat( ALL_ENGINES, false );
set_inlet_heat( ALL_ENGINES, false );
@@ -468,6 +473,14 @@
FGControls::get_tailhook, FGControls::set_tailhook);
fgSetArchivable(/controls/gear/tailhook);
+ fgTie
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Mittwoch 17 November 2004 10:29, Martin Spott wrote: Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), It is thought to work with the ai configuration Vivian was talking about. That means you need to apply the carrier-data.diff from ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ as well as put the nimitz_demo.xml into the Data/AI/ directory. But then, YASim's physics cannot yet 'see' the carrier deck. Changing YASim and the others to see the ground cache is one of the next steps. You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Dienstag 16 November 2004 18:25, Martin Spott wrote: into CVS is the addition of the Nimitz - no change to any FDM yet. Did I miss a mail ? True. There are many things to do. I would like to have the basic infrastructure in flightgears cvs. This way I can add the code safely to JSBSim's cvs, work on an update to YASim, etc ... But up to now, Erik gets a segfault. That is a showstopper, not only in Erik's eyes ... I want to know what the cause is. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Mittwoch 17 November 2004 22:20, Martin Spott wrote: Mathias Fr??hlich wrote: You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Well, this statement appears to be maybe mostly, but not entirely correct ;-) Apparently different rules apply when you put the carrier into the scenery: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg That's when you put that carrier statically into the scenery. Then it is in the scenery branch and SSGTRAV_HOT is set in the traversal mask. This is not true for AI models. And a AI carrier will be an AI model. But nice pic anyway :) Did you manage to take off? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Donnerstag 18 November 2004 00:32, Martin Spott wrote: With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea ... wait until the c172 gets a launchbar :) Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Aircraft carrier
Hi, I have now the FDM side of an aircraft carrier set up. The implementation uses a local cache of the scene graph to do intersection tests. This can then be done per gear/hook/lauchbar. Also the required aircraft carrier hardware will show up in this cache and can provide the required information. The cache itself is ATM integrated into the FGInterface class. New are functions to query a ground contact point below a given location in the earth. Together with that contact point the surface normal and the velocity of that contact surface are returned. The locations, normals and velovities are cartesian vectors given in the wgs84 coordinate system (origin in the earths center, x axis towards lat=lon=0, y axis towards lat=0, lon=90, z axis towards the north pole). A function to test catching a wire. The test is done by intersection of the quad where the hook moved during the past timestep with the lines representing the wires. When this test was sucessfull, we can query for the locations/velocities of the wires mount points. When the wire is no longer needed it should be released. Catapults are also stored as special lines in the scenegraph. There is a function which returns the nearest catapult line and its current locations/velocities. To build up the cache you need to call a function to let the cache know where and how big the cache must be. I have also a preliminary implementation to make use of that stuff from within JSBSim together with an aircraft which I have used for development. I have put that at ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier (Many thanks to Martin Spott for the webspace!) The file ground-cache-carrier-api.diff contains the required code for the surface cache together with the code to make the carrier and its velocity visible for the cache. The file nimitz_demo.xml must be put into the data directory under Data/AI/nimitz_demo.xml. The patch carrier-data.diff makes use of the AI nimitz. Looking into nimitz_demo.xml shows how the catapults/wires and deck surfaces are configured. Object names from the 3D Object are used to mark the scene graph nodes as special hardware. JSBSim-dropin.tar.bz2 contains the JSBSim part required to try that out. I will apply that seperately to JSBSim's cvs when that code is ready and the required infrastructure is in flightgear. For the ones curious how this is done, the files FGHook.cpp and FGLaunchBar.cpp contain the code how this is implemented. The FA-18.tar.bz2 file contains the FA-18 I have used for development. It has a hook and a launchbar configured. To play with that, you have to install the patches/new files described above. The hook can be extended with the H key, retracted with h. Start flightgear with fgfs --lat=37.688 --lon=-122.683 --heading=180 --altitude=71 and you will be placed on the carriers deck rolling backwards wrt the carrier. Then apply the breaks and wait until the aircraft settled down past being not trimmed. Now taxi on the deck to one of the catapults. When the nose wheel is above the first few meters of the catapult (please taxi exactly there). Apply the breaks and leave them applied. lower the flaps to half and give full throttle. Pull a little at your stick and release the breaks. As the breaks are released the aircraft is launched. Then you can cruise a bit, and again try to land on the nimitz. When you land, do not forget to extend the hook with 'H'. If you like it, you can then taxi to the catapult ... :) The physical model is not yet ready, but the api between the FDM and flightgear has prooven to be sufficient for that task. So, Erik, can you please apply ground-cache-carrier-api.diff to flightgear's sources, carrier-data.diff to the data directory and place nimitz_demo.xml into Data/AI ? I will do the JSBSim part myself when that stuff is ready. I have also looked into YASim how this can be integrated. Andy, have you done some work in that area? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: crease for ac3d files and speedup
On Mittwoch 13 Oktober 2004 04:25, Simon Hollier wrote: Well, I wish that were the case. Simgear/Flightgear/Plib fresh cvs as of 20 minutes ago (just to be sure). I'm running XFree86 4.4RC2,2.6.5-7 as per Suse 9.1 which might be the difference. But as everything just works right now...I'm pretty happy commenting out line 1174 in src/Scenery/tileentry.cxx: //makeDList( terra_transform ); to keep my 20+ fps. How much video memory does your radeon card have? I have seen similar effects with the dlist patch on my notebooks 32MB radeon 7500. What I can see than is that the system cpu time is at about 60%. Flying models with small textures and few vertices do not show that framerate hit with Eriks dlist patch. My guess is that display lists are stored in the graphics cards memory which is not that big with 32MB. That leads to graphics memory allocated via agp in main memory. These accesses seem to be much slower. The dri driver might be screwed up too??? So for gpu's with little memory this might be the problem? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases
Martin, If so, you might want to include some updated 3d models. For example the 737 is still flat shaded and the adf instrument is still ordered in in the wrong direction in current cvs base package. I am currently reviewing our models and will provide a patch later this evening. Greetings Mathias On Dienstag 12 Oktober 2004 19:14, Martin Spott wrote: Martin Spott wrote: I'm asking just to find out: Do we all agree that it makes much sense to build the upcoming binary releases with a crease-patched version of current PLIB CVS ? Ahem, for this purpose I'll have put a patched version here within the next couple of minutes that might serve as a reference if people tend to agree :-) ftp://ftp.uni-duisburg.de/FlightGear/Source/plib-20041010-crease.tar.gz Martin. -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
Hi,
During digging for that adf.ac stuff I have done some minor adjustmens to that
patch.
Things like not storing texture coordinate arrays when there is no texture
attached to that object and such.
The updated patch is attached.
Wolfram, this is the current one :)
Greetings and Thanks
Mathias
--
Mathias Frhlich, email: [EMAIL PROTECTED]
? Makefile
? Makefile.in
? aclocal.m4
? autom4te.cache
? config.log
? config.status
? configure
? src/Makefile
? src/Makefile.in
? src/fnt/.deps
? src/fnt/Makefile
? src/fnt/Makefile.in
? src/js/.deps
? src/js/Makefile
? src/js/Makefile.in
? src/net/.deps
? src/net/Makefile
? src/net/Makefile.in
? src/psl/.deps
? src/psl/Makefile
? src/psl/Makefile.in
? src/puAux/.deps
? src/puAux/Makefile
? src/puAux/Makefile.in
? src/pui/.deps
? src/pui/Makefile
? src/pui/Makefile.in
? src/pw/.deps
? src/pw/Makefile
? src/pw/Makefile.in
? src/sg/.deps
? src/sg/Makefile
? src/sg/Makefile.in
? src/sl/.deps
? src/sl/Makefile
? src/sl/Makefile.in
? src/ssg/.deps
? src/ssg/Makefile
? src/ssg/Makefile.in
? src/ssgAux/.deps
? src/ssgAux/Makefile
? src/ssgAux/Makefile.in
? src/util/.deps
? src/util/Makefile
? src/util/Makefile.in
Index: src/ssg/ssg.h
===
RCS file: /cvsroot/plib/plib/src/ssg/ssg.h,v
retrieving revision 1.173
diff -u -r1.173 ssg.h
--- src/ssg/ssg.h 4 Oct 2004 18:25:59 - 1.173
+++ src/ssg/ssg.h 9 Oct 2004 08:22:56 -
@@ -1469,18 +1469,14 @@
void getTexCoordList ( void **list ) { *list = texcoords - get ( 0 ) ; }
void getColourList ( void **list ) { *list = colours - get ( 0 ) ; }
- float *getVertex (int i){ if(i=getNumVertices())i=getNumVertices()-1;
- return (getNumVertices()=0) ?
- _ssgVertex000 : vertices-get(i);}
- float *getNormal (int i){ if(i=getNumNormals())i=getNumNormals()-1;
- return (getNumNormals()=0) ?
-_ssgNormalUp: normals-get(i);}
- float *getTexCoord(int i){ if(i=getNumTexCoords())i=getNumTexCoords()-1;
- return (getNumTexCoords()=0) ?
-_ssgTexCoord00 : texcoords-get(i);}
- float *getColour (int i){ if(i=getNumColours())i=getNumColours()-1;
- return (getNumColours()=0) ?
-_ssgColourWhite : colours-get(i);}
+ float *getVertex (int i){ int nv=getNumVertices(); if(i=nv)i=nv-1;
+ return (nv=0) ? _ssgVertex000:vertices-get(i);}
+ float *getNormal (int i){ int nn=getNumNormals(); if(i=nn)i=nn-1;
+ return (nn=0) ? _ssgNormalUp:normals-get(i);}
+ float *getTexCoord(int i){ int nc=getNumTexCoords(); if(i=nc)i=nc-1;
+ return (nc=0) ? _ssgTexCoord00:texcoords-get(i);}
+ float *getColour (int i){ int nc=getNumColours(); if(i=nc)i=nc-1;
+ return (nc=0) ? _ssgColourWhite:colours-get(i);}
ssgVtxArray *getAs_ssgVtxArray ();
@@ -1586,9 +1582,8 @@
void getIndexList ( void **list ) { *list = indices - get ( 0 ) ; }
- short *getIndex (int i){ if(i=getNumIndices())i=getNumIndices()-1;
- return (getNumIndices()=0) ?
- _ssgIndex0 : indices-get(i);}
+ short *getIndex (int i){ int ni=getNumIndices();if(i=ni)i=ni-1;
+ return (ni=0) ? _ssgIndex0 : indices-get(i);}
void removeUnusedVertices();
virtual ~ssgVtxArray (void) ;
Index: src/ssg/ssgLoadAC.cxx
===
RCS file: /cvsroot/plib/plib/src/ssg/ssgLoadAC.cxx,v
retrieving revision 1.34
diff -u -r1.34 ssgLoadAC.cxx
--- src/ssg/ssgLoadAC.cxx 2 Oct 2004 12:12:28 - 1.34
+++ src/ssg/ssgLoadAC.cxx 9 Oct 2004 08:22:57 -
@@ -23,6 +23,7 @@
#include ssgLocal.h
+#include ssgVertSplitter.h
static FILE *loader_fd ;
@@ -31,27 +32,34 @@
sgVec4 spec ;
sgVec4 emis ;
sgVec4 rgb ; // Should be named rgba instead - Bram
+ sgVec4 amb ;
float shi ;
} ;
static int num_materials = 0 ;
-static sgVec3 *vtab = NULL ;
-static ssgLoaderOptions* current_options = NULL ;
-static _ssgMaterial*current_material = NULL ;
-static sgVec4 *current_colour = NULL ;
-static ssgBranch *current_branch = NULL ;
-static char*current_tfname = NULL ;
-static char*current_data = NULL ;
+static ssgLoaderOptions *current_options= NULL ;
+static int current_materialind= 0 ;
+static ssgBranch*current_branch = NULL ;
+static ssgVertexArray *current_vertexarray= NULL ;
+static ssgTexCoordArray *current_texcoordarray = NULL ;
+static ssgIndexArray*current_triindexarray = NULL ;
+static ssgIndexArray*current_matindexarray = NULL ;
+static ssgIndexArray*current_flagsarray = NULL ;
+static char *current_tfname = NULL ;
+static char *current_data = NULL ;
+static float current_crease = 61.0 ;
#define
[Flightgear-devel] [PATCH] crease for ac3d files and speedup
Hi all,
During the past days I have done some profiling on flightgear. One final
outcome of that work was, that most time is spent in ssg routines (yes, ssg
not OpenGL!!). The problems are the huge amount of small leaf nodes we get
from the ac file loader. That vertex optimization pass makes this a bit
better but there was still room for improovement.
I have now changed the ac3d file loader to first collect all surface elements
of a leaf object and then split them to a minimum number of leaf nodes
according to material and colour properties.
For my local setup (radeon 9100, athlon XP 2400+) this gave me a framerate
speedup up to 40% (16 fps - 26fps, for the c172 rendered in a window to not
hit the ancient radeons fill rate limit). I would guess that the average
speedup is about 25%-30%.
As a /sideeffect/ it was now easy to implement the crease tag for ac3d files.
Ac3d models look now the same as in ac3d.
Attached is a patch to todays plib anoncvs.
Is sombody there with cvs write access to plib? Can somebody apply this patch,
please?
Greetings
Mathias
--
Mathias Frhlich, email: [EMAIL PROTECTED]
Index: src/ssg/ssg.h
===
RCS file: /cvsroot/plib/plib/src/ssg/ssg.h,v
retrieving revision 1.173
diff -u -r1.173 ssg.h
--- src/ssg/ssg.h 4 Oct 2004 18:25:59 - 1.173
+++ src/ssg/ssg.h 8 Oct 2004 06:02:41 -
@@ -1469,18 +1469,14 @@
void getTexCoordList ( void **list ) { *list = texcoords - get ( 0 ) ; }
void getColourList ( void **list ) { *list = colours - get ( 0 ) ; }
- float *getVertex (int i){ if(i=getNumVertices())i=getNumVertices()-1;
- return (getNumVertices()=0) ?
- _ssgVertex000 : vertices-get(i);}
- float *getNormal (int i){ if(i=getNumNormals())i=getNumNormals()-1;
- return (getNumNormals()=0) ?
-_ssgNormalUp: normals-get(i);}
- float *getTexCoord(int i){ if(i=getNumTexCoords())i=getNumTexCoords()-1;
- return (getNumTexCoords()=0) ?
-_ssgTexCoord00 : texcoords-get(i);}
- float *getColour (int i){ if(i=getNumColours())i=getNumColours()-1;
- return (getNumColours()=0) ?
-_ssgColourWhite : colours-get(i);}
+ float *getVertex (int i){ int nv=getNumVertices(); if(i=nv)i=nv-1;
+ return (nv=0) ? _ssgVertex000:vertices-get(i);}
+ float *getNormal (int i){ int nn=getNumNormals(); if(i=nn)i=nn-1;
+ return (nn=0) ? _ssgNormalUp:normals-get(i);}
+ float *getTexCoord(int i){ int nc=getNumTexCoords(); if(i=nc)i=nc-1;
+ return (nc=0) ? _ssgTexCoord00:texcoords-get(i);}
+ float *getColour (int i){ int nc=getNumColours(); if(i=nc)i=nc-1;
+ return (nc=0) ? _ssgColourWhite:colours-get(i);}
ssgVtxArray *getAs_ssgVtxArray ();
@@ -1586,9 +1582,8 @@
void getIndexList ( void **list ) { *list = indices - get ( 0 ) ; }
- short *getIndex (int i){ if(i=getNumIndices())i=getNumIndices()-1;
- return (getNumIndices()=0) ?
- _ssgIndex0 : indices-get(i);}
+ short *getIndex (int i){ int ni=getNumIndices();if(i=ni)i=ni-1;
+ return (ni=0) ? _ssgIndex0 : indices-get(i);}
void removeUnusedVertices();
virtual ~ssgVtxArray (void) ;
Index: src/ssg/ssgLoadAC.cxx
===
RCS file: /cvsroot/plib/plib/src/ssg/ssgLoadAC.cxx,v
retrieving revision 1.34
diff -u -r1.34 ssgLoadAC.cxx
--- src/ssg/ssgLoadAC.cxx 2 Oct 2004 12:12:28 - 1.34
+++ src/ssg/ssgLoadAC.cxx 8 Oct 2004 06:02:42 -
@@ -23,6 +23,7 @@
#include ssgLocal.h
+#include ssgVertSplitter.h
static FILE *loader_fd ;
@@ -35,14 +36,18 @@
} ;
static int num_materials = 0 ;
-static sgVec3 *vtab = NULL ;
-static ssgLoaderOptions* current_options = NULL ;
-static _ssgMaterial*current_material = NULL ;
-static sgVec4 *current_colour = NULL ;
-static ssgBranch *current_branch = NULL ;
-static char*current_tfname = NULL ;
-static char*current_data = NULL ;
+static ssgLoaderOptions *current_options= NULL ;
+static int current_materialind= 0 ;
+static ssgBranch*current_branch = NULL ;
+static ssgVertexArray *current_vertexarray= NULL ;
+static ssgTexCoordArray *current_texcoordarray = NULL ;
+static ssgIndexArray*current_triindexarray = NULL ;
+static ssgIndexArray*current_matindexarray = NULL ;
+static ssgIndexArray*current_flagsarray = NULL ;
+static char *current_tfname = NULL ;
+static char *current_data = NULL ;
+static float current_crease = 61.0 ;
#define MAX_MATERIALS 1000/* This *ought* to be enough! */
static _ssgMaterial *mlist[ MAX_MATERIALS ] ;
@@ -52,6 +57,9 @@
static sgVec2 texrep ;
static
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
On Freitag 08 Oktober 2004 18:33, Erik Hofman wrote: I've tried using display lists again (which didn't work in the past) and on my O2 I get a great improvement (up to 30%, but that only means from 6 fps to 9 fps in my case), but on my Linux machine I get a floating point exception. Could anyone test it on their Linux machine? I get a segfault in the radeon driver .so. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
On Freitag 08 Oktober 2004 19:54, Norman Vine wrote: This patch won't be acceptable to the PLIB team unless we can fix this. Hmm, from my local machine, I would say that these are different things mixed together. If I understand right Eriks DList change works on the scenery, not on the imported ac3d models. Correct? This one line change does not work for my radeon on the notebook and gives everything from funny colours to coredumps on my r200 chip in the desktop machine. That plib patch changes the function loading the ac3d models. I have also done a quick check what happens if I make display lists for the ac3d models in the plib loader code. This works well for me. From that, I would tell the plib patch is ok. Any different experience? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? Done in JSBSim's cvs. Please check out a new version. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linuxtag
Hi, Next week is the Linuxtag in Karlsruhe, Germany. http://www.linuxtag.org/ Is Flightgear present this year? Or will somebody be there for an other project? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
On Mittwoch, 12. Mai 2004 15:40, Innis Cunningham wrote: I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual u-fps, which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. Ok I have not got the latest CVS so don't know if its been fixed already.This is just the 9.4 version Is in the works. Is not yet in JSBSim mainline ... Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
Hi, On Sonntag, 25. April 2004 17:24, Nick wrote: I took a couple of classes in Matlab/Simulink last month and this was addressed specifically in the class. Matlab permits you to vary timestep size as you approach the ground. It you extrapolate ahead in time to see if any of the gear have come in contact with the ground you can then retreat to the previous time, cut the timestep size down and then go forward again until you capture the ground contact at a fine enough stepsize to prevent instability. It isn't necessary to run the entire simulation at this reduced stepsize if you can run the gear model as a faster subtask of the main simulation. Matlab then does running checks to vary the timestep size on the basis of a predictor-corrector algorithm (if there is a large discontinuity it will go back and systematically chop down the timestep size until the output is sensible. It's possible in this modern age to find implementation of these algorithms (Adams-Bashforth is one that I'm familiar with. Naturally you are taking a chance on frame overruns if you let the program decide its update rate, but then that's fixable too in this age, using a faster processor. There are even phantastic free odesolvers included in MATLAB odesuite available. I believe that this toolbox is just delivered with current MATLAB versions. You can just plug them in SIMULINK. So if you are at that situation you can do much more. If you just want to stay explicit for some reason you can just use an explicit solver like the ode45, set the atol and rtol values via odeset and let it run. Solvers like ode45 have adaptive stepsize control to get a result with that given accuracy. The downside of this approach is that explicit solvers will detect this stiffness and dependent on how stiff the problem is will reduce the stepsize to something *very* small. Too small to get some realtime behavour ... The other approach is to use the right tool for the given problem, an implicit solver like the ode15s of the odesuite. It will integrate well even if the problem is stiff or a DAE. ode15s can be restricted to a low order solver if your problem is not smooth enough (not enough often steady differntiable). If it is kind of smooth, or at least the sharp bends occure not that often, as is the case for a gear. A gear model is most likly smooth enough up to the point when the tire leaves the ground, at this point it is only steady but not differentiable. Then it might be a good idea to use a higher order solver anyway. For stiff problems I think it is best to use RADAU5 available from http://www.unige.ch/math/folks/hairer/software.html An excellent page for timestepping anyway. This RADAU5 has order 5 and also if required builtin stepsize control. The MATLAB code is not yet there, but I know that there is one (I have it here, a collegue implemented it in MATLAB) and I also know that the author of that page asked for this MATLAB version of RADAU5 to publish it on this page. So it will appear there ... ... wait. It *is* available via http://na.uni-tuebingen.de/na/software.shtml Hope this helps. Yep, kind of ... :) Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Dienstag, 6. April 2004 21:16, Jim Wilson wrote: Yep. It just depends on how your brain is organized I think :-) Using names you can also name it gear0, gear1 ... But using numbers you are fixed to remembering how you configured ... Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Montag, 5. April 2004 05:30, Jim Wilson wrote: We should also pick a coordinate origin to report it relative to. If JSBSim is using the (moving) c.g., then we're both bugged. :) Umm...I think it's all the same isn't it? It isn't like the ground is going to move under the FDM's altitude. Well maybe in the area around KSFO it could. But we could move that code to the FGEarthQuake class. :-) No it is not. Depending on the locations of the tanks and how much fuel they will carry the agl will change in this case... Andy is totaly right. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Montag, 5. April 2004 14:10, Jim Wilson wrote: Mathias Frhlich said: On Montag, 5. April 2004 05:30, Jim Wilson wrote: We should also pick a coordinate origin to report it relative to. If JSBSim is using the (moving) c.g., then we're both bugged. :) Umm...I think it's all the same isn't it? It isn't like the ground is going to move under the FDM's altitude. Well maybe in the area around KSFO it could. But we could move that code to the FGEarthQuake class. :-) No it is not. Depending on the locations of the tanks and how much fuel they will carry the agl will change in this case... Andy is totaly right. I may be a little slow (monday morning here), but that does not tell me anything. We are talking about agl not the center of gravity. Is that the confusion? Hmm, I don't think so. But the center of gravity is not fixed within the aircraft. So if there is a heavy fuel tank below the fuselage forexample, the center of gravity might be a few inches lower than when the tank is dropped. Since the altitude/agl currently used is the altitude/agl of the center of gravity the altitude/agl changes with the aircrafts mass distribution. And this is not an effect of the gear springs here. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Montag, 5. April 2004 14:12, Jim Wilson wrote: This sounds like it might be excessive. We should continue to model instrumentation in flightgear. Fine. Nothing more on this is needed from the FDM (we should only be translating to sensor points _if_ the particular aircraft models the instrument). That translation could easily occur in a Instrumentation/ subclasses. It would then be standardized across FDM's, which is why it is not advisable to increase the complexity of the FDM interface. We're having enough trouble keeping what we have standard. Yep, I think this too. FGInterface is way too heavy. And too little standardized. And it is too little documented :) This seperation between hard and soft values are thought to make things a bit leaner and cleaner. But I am not shure if I can reach this goal with that. What I can tell is that I think FGInterface needs to be cleaned out to some degree. Ok, back to the original subject: I am interrested if JSBSim should rely on the /preset/sim/onground property to be set correct or if we should think of some heuristic to find out how we should trim? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Montag, 5. April 2004 17:45, Curtis L. Olson wrote: Mathias Frhlich wrote: Yes, this is my question. I also think that this /sim/presets directory should be either built up to the idea someone noted in this thread before or should be removed. That way noone can rely on stuff not really maintained ... The /sim/presets/ stuff is being maintained. It's the official way to define the initial conditions for the flight dynamics before initializing them. Ok, then I think that the onground value needs to be fixed that it containes the valid value at reset time. Someone traced this already what happened here, true? So could this be fixed in flightgear please? Greetings and thanks Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
The onground property is now ok. You can reset now JSBSim aircraft. Thanks for the fix! Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Sonntag, 4. April 2004 17:49, Jim Wilson wrote:
Mathias Frhlich said:
Well, my first guesses were wrong, but I have found what JSBSim does now:
The code in question is in FGJSBSim::do_trim():
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
fgtrim = new FGTrim(fdmex,tGround);
} else {
fgtrim = new FGTrim(fdmex,tLongitudinal);
}
At initialization time /sim/presets/onground is true, at reset time it is
false.
It lookes like tGround triming also adjusts the height of the aircraft so
that it does not get pushed into the air by the gear springs. Whereas
tLongitudinal triming does not adjust the altitude.
Just taking tGround triming all the time fixes the reset issue. But this
is obviously not the right fix here.
Did you trace this in a debugger? fgGetBook(/sim/preset/onground) is
definately true at the time the reset key is hitotherwise that hack I
posted earlier would not work.
I just printed this with a cout.
And yep, I wondered too because of the patch you posted last time.
I am not too familiar with flightgear as such, but I guess, like written
before, that /sim/preset/onground is reset to false past your patch checks
for this property. Then past it is reset your change to the altitude value
might cause /sim/preset/onground to be set to true again, which does not
happen if the altitude is not set to -.
Try it yourself, just add
cout onground: fgGetBool(/sim/presets/onground) endl;
at the entry of void FGJSBsim::do_trim(void) in FGJSBSim.cpp and run
flightgear ... (yesterdays flightgear CVS)
Greetings
Mathias
--
Mathias Frhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Sonntag, 4. April 2004 17:59, Jim Wilson wrote: In any case, the VRP values in the config do not affect the output of the FDM, right? Right. I have found that this essential change has sliped through. It is in my queue to Jon. I guess it will not get lost ... As far as this problem is concerned, it has been around a lot longer than the VRP mod. One thing I noticed is the altitude-agl is reported at the gear level by YASim, where JSBSim reports the distance of the nose above the ground. I'm not sure one is better than the other, but perhaps this should be standardized. Hmm, the altitudes and agl stuff is currently reported relative to the center of gravity. What does YASim do when the gear is retracted? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 15:13, Jim Wilson wrote: Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? My response is that the Init is merely for setting up and initializing data structures. Hmm, but virtually every FDM calls FGInterface::common_init() in init(). And this one copies the initial values of the aircraft into the FDM. So if this data is screwed up at call of init(), this screwed up data ends in the FDM. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. Ok, I can find this is_suspended() call in the first line of JSBSim::update(double). So I guess that this is_suspended() call should return true as long as the remaining subsystems are not set up? Or how is this interface supposed to know when it can start computing physics? Ok, I have prepared all set_* calls in the JSBsim FGInterface with a cout function name function arguments to see what is different when the FDM is initialized at the first time and at reset time. This is the output at flightgear start: virtual void FGJSBsim::init() virtual void FGJSBsim::set_Longitude(double) long = 0.198215 virtual void FGJSBsim::set_Latitude(double) lat = 0.824871 virtual void FGJSBsim::set_Altitude(double) alt = 1949.82 virtual void FGJSBsim::set_V_calibrated_kts(double) vc = 0 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::update(double) is_suspended() 0 void FGJSBsim::do_trim() virtual void FGJSBsim::update(double) is_suspended() 0 What we can see here is that there is no problem with agl or altitude below -9990ft. Also the is_suspended() call is never true. This are the JSBSim FGInterface function entries when I press the reset menu entry: virtual void FGJSBsim::init() virtual void FGJSBsim::set_Longitude(double) long = 0.198215 virtual void FGJSBsim::set_Latitude(double) lat = 0.824871 virtual void FGJSBsim::set_Altitude(double) alt = 1949.82 virtual void FGJSBsim::set_V_calibrated_kts(double) vc = 0 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Climb_Rate(double) roc = -0.00421123 virtual void FGJSBsim::set_Gamma_vert_rad(double) gamma = -0.00082482 virtual void FGJSBsim::update(double) is_suspended() 0 void FGJSBsim::do_trim() The set_Climb_Rate, set_Gamma_vert_rad calls are new here. And I think that this is the problem. The rest looks identical. Ok, when I see this, I think that we should eliminate the duplicate calls. And I still think that it is not the job of a specific FDM to check for an error condition of the tile loader, even if this is not the error at the moment. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? I get more and more confused with this interface. JSBSim, copies almost all initial conditions at the init() call and updates these values with the ones superseeded by FGInterface::set_* calls. At the first entry to update(double) it checks if some initial conditions have changed and trims if required. So how is this interface class supposed to work? What could a FDM expect to be set up at which call to an interface function? And where is this documented :-) ? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Well, my first guesses were wrong, but I have found what JSBSim does now:
The code in question is in FGJSBSim::do_trim():
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
fgtrim = new FGTrim(fdmex,tGround);
} else {
fgtrim = new FGTrim(fdmex,tLongitudinal);
}
At initialization time /sim/presets/onground is true, at reset time it is
false.
It lookes like tGround triming also adjusts the height of the aircraft so that
it does not get pushed into the air by the gear springs. Whereas
tLongitudinal triming does not adjust the altitude.
Just taking tGround triming all the time fixes the reset issue. But this is
obviously not the right fix here.
On Samstag, 3. April 2004 23:22, Jim Wilson wrote:
There's a patch at the end of this that works around the issue by adding
yet another setter for the preset altitude, but I would much rather see
something improved in the ground trimming that makes it a little less
problematic.
This has been an ongoing issue with the trimming code in JSBSim. Is it
possible to fix it? I take it the ac is bouncing like a hard landing or
something like that.
Best,
Jim
cvs diff: Diffing src/GUI
Index: src/GUI/gui_local.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/gui_local.cxx,v
retrieving revision 1.11
diff -u -r1.11 gui_local.cxx
--- a/src/GUI/gui_local.cxx 31 Mar 2004 21:10:32 - 1.11
+++ b/src/GUI/gui_local.cxx 3 Apr 2004 21:07:43 -
@@ -45,7 +45,6 @@
build_rotmatrix(GuiQuat_mat, curGuiQuat);
}
-
void reInit(puObject *cb)
{
// BusyCursor(0);
@@ -70,6 +69,10 @@
globals-restoreInitialState();
+if ( fgGetBool(/sim/presets/onground) ) {
+fgSetDouble(/sim/presets/altitude-ft, -.0 );
+}
+
// update our position based on current presets
fgInitPosition();
Looking at this patch and the fact that this also works, I would guess that
normally /sim/presets/onground seems to be reset to false. Setting
the /sim/presets/altitude-ft to - seems to trigger the onground value
later to be true again ...
Greetings
Mathias
--
Mathias Frhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Hi, On Montag, 22. Mrz 2004 12:53, Martin Spott wrote: Jim Wilson wrote: Martin Spott said: I'm sorry to say this but I can't resist to note that some of the changes in your patch reverted David's the PA-28 rotates around it's nose corrections. I'm not aware of any difference of opinion Martin, but I will look into what you describe. Can anyone confirm the effect ? Yep, I can. I must admit that I find it a bit strange that it needed almost three discussion threads in the past until the probmlem was agreed upon as being really existent and now we're back at the starting point of the whole debate Nothing wrong with the debate. Just noone cared about a misplaced 3d model. The ac3d model of the pa-28 is misplaced as if the center of gravity is at the nose tip. This, together with the fact that you allways look at the nose tip (It is allways exactly in the center of your screen) leads to the described effect. I have attached a picture of the pa28 standing still on the runway. It shows that the 3d model is misplaced at least in the heigth. But given that the nose tip is painted where the center of gravity is (BTW: I assume that YASim reports the center of gravity to flightgear, true?) it is also misplaced in longitudinal direction. I don't know YASim well enough to tell what needs to be done in detail. But the 3d model needs to be shifted to somehwere else, either with ac3d, some offsets in the model xml file or somewhere in the YASim configuration, if this is possible. With JSBSim you would now just configure the visual reference point to be at the nose tip. :) Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] attachment: pa28.jpg___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New joystick configuration.
Hi all, I have done a new joystick definition for my hardware. This is the thrustmaster top gun afterburner USB (what a name!) throttle/stick combination. I took the great Cyborg-Gold-3d-USB.xml configuration and adjusted it to the thrustmaster axis and button definitions, the global layout is the same. The most notable customization is the throttle, which has two raster positions. One marked with 'idle' and one marked with 'afterburner'. I have made the throttle values scale between 0 and 0.98 between the idle and afterburner raster. In a small area around the raster there is a deadband like zone. Above the abterburner raster, it scales the throttle up to the value of 1, which then will give afterburning. Aditionaly the /controls/engines/engine*/augumentation value is set to true in this afterburning area. Attached is small diff to incorporate the joystick into the global configuration and the joystick configuration itself. In the hope that it might be useful: could someone apply this to the cvs tree please? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ? Input/Joysticks/ThrustMaster/Top-Gun-Afterburner.xml Index: joysticks.xml === RCS file: /var/cvs/FlightGear-0.9/data/joysticks.xml,v retrieving revision 1.25 diff -u -r1.25 joysticks.xml --- a/joysticks.xml 5 Jan 2004 20:48:00 - 1.25 +++ b/joysticks.xml 4 Mar 2004 10:04:46 - @@ -43,6 +43,7 @@ !-- ThrustMaster devices -- js-named include=Input/Joysticks/ThrustMaster/FCS.xml/ js-named include=Input/Joysticks/ThrustMaster/Attack-Throttle.xml/ + js-named include=Input/Joysticks/ThrustMaster/Top-Gun-Afterburner.xml/ !-- Lew Engineering RCJOY device for various RC transmitters. http://www.leweng.com -- js-named include=Input/Joysticks/LewEngineering/RC-transmitter-hitecLaser4.xml/ ?xml version=1.0? !-- $Id$ Bindings for THRUSTMASTER Top Gun Afterburner stick/throttle combination. This file is based on the Cyborg-Gold-3d-USB configuration file. So it provides maximum compatibility. ___ Layout ___ axis 0: aileron axis 1: elevator axis 2: rudder axis 3: throttle no modifier F3 F4 F3+F4 ~~ button 0 (trigger): brakes parking brake speed brake thrust revers. button 1 (top middle): flaps upgear up previous view * button 2 (front right): reset view dir tail wheel lock cockpit viewreset all trim button 3 (top right):flaps down gear down next view * button 4 (thr. down/back): brakes left * zoom out* button 5 (thr. middle/back): brakes right* zoom in * button 6 (thr. upper/back): modifier 0 / button 7 (thr. front): modifier 1 / hat left (axis5):look left leaner mixture aileron trimrudder trim hat right (axis5): look right richer mixture aileron trimrudder trim hat back (axis6):look down dec prop pitch elevator trim * hat forward (axis6): look up inc prop pitch elevator trim * F3 and F4 are used like Shift, Control, or Alternate on computer keyboards. For example: press F3 and keep holding it down while pressing the fire button/trigger - toggle parking brake Also this configurations will make use of the raster positions on the throttle. The idle position and below is really zero thrust command. Positions bewteen idle and afterburner will scale the thrust value between 0 and 0.98 and thus provides military power for jet engines. The afterburner raster will really turn on afterburning. Also to avoid additional deadband values in the linux kernel to the deadband values configured here in flightgear. You may need to issue the following command before starting flightgear: jscal -s 7,1,0,-5,5,4194304,4194304,1,0,-5,5,4194304,4194304,1,0,-5,5,4194304,4194304,1,0,128,128,4194304,4194304,1,0,112,142,5534751,5534751,1,0,0,0,536870912,536870912,1,0,0,0,536870912,536870912 /dev/input/js0 This will also avoid the useless deadband area in the middle of the throttle position. Also this will make the raster positions of the throttle match the programmed values here. ___ Customization If you want to change some (or all) of the bindings, the recommended way is to copy this file to your home directory, make your changes there, and include it from your personal preferences.xml file. Use the tags js-named n=100 and /js-named around the definitions, but within
[Flightgear-devel] Blender 2.32 ...
... is out. Including support for menu driven python import/export scripts. Just, for those who are curious. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: 3D aircraft model origins
Hi, I fully agree with the MRP idea. It is just an arbitrary point in the model. Alan, I don't see a real argument in this translation you talk about. The computonal cost of this single translation is peanuts compared to the computations done elsewhere in flightgear. Also If you prefer to have the POS for the origin of your models you can use POS=MRP for you and you are done. So, I think everyone can be happy with the MRP thing! Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
