Re: [Flightgear-devel] VMAP1 in Landcover-DB
Josh Babcock wrote: I say we issue everyone a GPS unit and start taking out own data :) It's being done already: http://www.free-map.org.uk/ Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Jon Stockill wrote: Josh Babcock wrote: I say we issue everyone a GPS unit and start taking out own data :) It's being done already: http://www.free-map.org.uk/ Well, Freemap data is from now on being contributed to the OpenStreetMap database. I must admit that I've never seen Freemap before and I'm really happy to see they did this move in order to combine their forces. Please take into account that merging such data of different sources and resolutions is _very_ time consuming work because you almost always have to adjust the boundaries manually. For example we have roads in the high resolution dataset which are placed almost correctly and the same road in the low resolution dataset has an offset of several hundred meters We are already preparing such a merge but I expect the process to take several, not to say numerous months until we're ready to offer the first results. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [RFC] HUD
I've started to clean up the HUD code. I've moved all class-specific code to the classes. Before, each class had an external initializer that loaded the properties from the property tree and called a constructor with *many* parameters. Now the constructors are only pointed to the group node and fetch their stuff themselves. Now there are two questions: 1. I would like to create a HUD class that contains the generic stuff (like setup, context, switching etc.), all of which is currently a set of separate static functions. Should this be: (a) an FGInstrumentMgr controlled class instance, and if so: should it be moved to Instrumentation/HUD/? (b) a subsystem on its own with an extra HUD::draw() method that's called from the renderer (HUD::update() wouldn't be usable for drawing)? (c) an unspecific, custom class? Consider a possible render-to-texture HUD option in addition to the two existing modes OSD-like 2D-fullscreen mode (ufo) and realistic-but-not-aircraft- model-associated-3D-HUD (f16-3d). 2. I want to drop the unflexible loadfn getters, and use property instead, so that any HUD element can take its value from any property. The current, ugly way is AFAIK due to the fact that the HUD code predates the property code, so there wasn't much choice for the author back then. Today really only properties make sense. (d) can I simply switch to properties, if I make sure that all HUD files in CVS get converted, and the result is identical (or otherwise in agreement with the aircraft maintainer)? Or am I expected to support both methods for one or two releases? My preference is, of course, to switch and let loadfn die immediately. :-) Erik, you looked into that a while ago, so you probably have specific expectations? Anyone else? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Martin Spott wrote: Jon Stockill wrote: Josh Babcock wrote: I say we issue everyone a GPS unit and start taking out own data :) It's being done already: http://www.free-map.org.uk/ Well, Freemap data is from now on being contributed to the OpenStreetMap database. I must admit that I've never seen Freemap before and I'm really happy to see they did this move in order to combine their forces. The combination of the two is certainly a good thing. The free-map author is already working on a new renderer for openstreetmap, and the amount of data in openstreetmap is growing quite quickly. I discovered this the other day - seems like it may be a useful resource for keeping track of this type of project: http://slashgeo.org/ Please take into account that merging such data of different sources and resolutions is _very_ time consuming work because you almost always have to adjust the boundaries manually. For example we have roads in the high resolution dataset which are placed almost correctly and the same road in the low resolution dataset has an offset of several hundred meters Yes - I've seen just how bad vmap0 roads are in my local area - trying to match edges between datasets would be a complete nightmare. We are already preparing such a merge but I expect the process to take several, not to say numerous months until we're ready to offer the first results. Is there any way people can help with this? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Jon Stockill wrote: Martin Spott wrote: I discovered this the other day - seems like it may be a useful resource for keeping track of this type of project: http://slashgeo.org/ Aye - this really is a valuable resource. Are they somehow affiliated with Slashdot or did they just pick a part of the name ? I should monitor it from time to time just to see if someone already announces what we're still preparing for ;-) Yes - I've seen just how bad vmap0 roads are in my local area - trying to match edges between datasets would be a complete nightmare. But in the end someone has to do it - no chance of circumvention unless we find an clever algorithm that does the job for us. We are already preparing such a merge but I expect the process to take several, not to say numerous months until we're ready to offer the first results. Is there any way people can help with this? There will be. Currently I'm waiting for someone giving the ok to move my DB to a more powerful machine but I think people can step upon the plate earlier. This page for example: http://www.mapability.com/info/vmap1_download.html mentions the bounding boxes of the respective VMap1 datasets. Before cutting out VMap0 we'll have to know if lat/lon of these boxes is really accurate or not. This could be done either by finding a reliable source which tells us yes, they _are_ really precise or by loading data files (shapefiles) into your preferred GIS viewer and determine if the roads and rivers that for example intersect the border between the US and Canada really end at the specified latitude. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Just came across this video: http://www.angelfire.com/il2/aphs/what_up_dog.wmv Are we ready to model this kind of aerobatics in FG? Andras ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Jon Stockill wrote: Is there any way people can help with this? As I already wrote in the previous posting Aside from that I'd be very happy if someone would beautify the visual apperance of the current Mapserver interface. 1.) The mapserver relies on JavaScript - and I've never done that before. It would be nice if someone could completely eliminate the need for this disturbing Browse map checkbox, overall improvement is very much welcomed. 2.) I'd wish someone would create an RGB colour schema for the representation of the different layers. Alone for all the VMAP0 layers we need a large set of different colours if we want to tell betwen the layers - not to speak of a combined presentation of VMAP0 and VMAP1 in a single picture Please don't hesitate to contact me if you'd like to work on one of these. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Thursday 15 June 2006 15:32: Melchior FRANZ wrote: (a) an FGInstrumentMgr controlled class instance, and if so: should it be moved to Instrumentation/HUD/? That's my preference, especially since it will be a completely overhauled version of the HUD code. The default HUD could then be a HUD entry in $FG_ROOT/Aircraft/Generic/generic-instrumentation.xml ... hud namehud/name number0/number !-- maybe some day an advanced UFO needs 2 HUDs :-) -- !-- textureAircraft/f16/Models/hud.rgb/texture -- /hud that depends on electricity and serviceable. The texture entry could be used once we have a *usable* render-to-texture HUD version. (My first version wasn't that pretty.) This would then be the virtual texture that can be mapped to a 3D HUD object of the aircraft model. Etc. etc. (d) can I simply switch to properties, [...] I'm trying to guess how many newly created special HUD configurations can be. I think there are at least a few. So I would postpone dropping the old code to after 1.0 (maybe not even counting 1.x subversions). OK. That makes sense. It could first output a warning on log level warning, then on alert, and finally disappear. I'd also write a section about the migration to properties. I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. Hmm ... there is only one HUD, so I'd prefer just HUD (which is still free as a class name). The XML prefix is as redundant as the New in NewGUI will soon be. :-) BTW: in case someone has looked at the current HUD files ... I left quite some FIXME everywhere, and I will, of course, really fix those soon, and also make other changes and improvments. So, don't panic. :-) The HUD look/behaviour shouldn't have become worse. If you notice any degradation, please shout in time! Well, there's one degradation: ticks and digits in the moving scales were before restricted to pixel boundaries. This made them jump, which looked silly. Also the scale ticks weren't evenly spaced because of that. I changed that, but now digits can move between pixels, which may sometimes look like flicker. If this is a problem, then I'd rather make it configurable, as the current method is IMHO more correct. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Martin Spott wrote: Jon Stockill wrote: Is there any way people can help with this? As I already wrote in the previous posting Aside from that I'd be very happy if someone would beautify the visual apperance of the current Mapserver interface. 1.) The mapserver relies on JavaScript - and I've never done that before. It would be nice if someone could completely eliminate the need for this disturbing Browse map checkbox, overall improvement is very much welcomed. I can highly recommend ka-Map - it'll give you a google maps style interface to mapserver. http://ka-map.maptools.org/ 2.) I'd wish someone would create an RGB colour schema for the representation of the different layers. Alone for all the VMAP0 layers we need a large set of different colours if we want to tell betwen the layers - not to speak of a combined presentation of VMAP0 and VMAP1 in a single picture Is the map definition file available anywhere so I can see what layers you have defined? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] statistics: usage of texture memory (shocking!)
Per 15 Haz 2006 14:44 tarihinde, Olaf Flebbe ?unlar? yazm??t?: Hi, let me add two points: ~ 8% of the startup time is consumed generating the mibmaps (ssgMakeMibMaps) (measured with Intel VTune). I.e. is used for downsampling textures. The tremendous texture memory is a performance killer for lowend graphics like intel 91x. (I got 1 Frame/sec.) I worked out a patch to plib, reducing all flightgear texture sizes and got 15 Frames/sec. Olaf Will you provide the patch? Regards Savas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Jon Stockill wrote: Martin Spott wrote: 1.) The mapserver relies on JavaScript - and I've never done that before. It would be nice if someone could completely eliminate the need for this disturbing Browse map checkbox, overall improvement is very much welcomed. I can highly recommend ka-Map - it'll give you a google maps style interface to mapserver. http://ka-map.maptools.org/ Thanks, I'll have a look at it. 2.) I'd wish someone would create an RGB colour schema for the representation of the different layers. Alone for all the VMAP0 layers we need a large set of different colours if we want to tell betwen the layers - not to speak of a combined presentation of VMAP0 and VMAP1 in a single picture Is the map definition file available anywhere so I can see what layers you have defined? http://mapserver.flightgear.org/landcover.map This is still work in progress - as always ;-) - because I didn't finish adding all the VMAP1-layers. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, let me comment on the current apt.dat performance i.e. of the time spent in fgAirportDBLoad: ~25% of time time is spent in simgear::strutils::split ~10% is spent in atof() Measured with Intel VTune using MS Visualc C++ 2005. IMHO it is an indicator that we should not use a plain text format. I have no experiences with the performance of binary XML representations. Cheers Olaf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] statistics: usage of texture memory (shocking!)
* Olaf Flebbe -- Thursday 15 June 2006 13:44: The tremendous texture memory is a performance killer for lowend graphics like intel 91x. (I got 1 Frame/sec.) I worked out a patch to plib, reducing all flightgear texture sizes and got 15 Frames/sec. That patch will probably collide with Fred's fix that is in CVS since a few weeks (months?). Do you not use CVS/HEAD? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Olaf Flebbe wrote : Hi, let me comment on the current apt.dat performance i.e. of the time spent in fgAirportDBLoad: ~25% of time time is spent in simgear::strutils::split ~10% is spent in atof() Measured with Intel VTune using MS Visualc C++ 2005. IMHO it is an indicator that we should not use a plain text format. I have no experiences with the performance of binary XML representations. There is not much information here. If you tell us what cost us fgAirportDBLoad in the whole initialisation process, we could decide if it's worth optimizing it. And you're missing a bit of history here : The airport file used to be binary and it was decided that a text file was easier to maintain. No endianess or integer size problem, no compilation phase. MetaKit was a PITA at the time. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Jon Stockill wrote: Martin Spott wrote: 1.) The mapserver relies on JavaScript - and I've never done that before. It would be nice if someone could completely eliminate the need for this disturbing Browse map checkbox, overall improvement is very much welcomed. I can highly recommend ka-Map - it'll give you a google maps style interface to mapserver. http://ka-map.maptools.org/ It should only be used by developers that have some knowledge of JavaScript [...] :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Guys, I've been operating under the assumption that load performance for FG is not a requirement for apt.dat because you guys are already pre-processing the file to make scenery, and could thus convert the apt.dat file to something faster to read _if_ you wanted to trade load time for the benefits of text. *cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Martin Spott wrote: There will be. Currently I'm waiting for someone giving the ok to move my DB to a more powerful machine but I think people can step upon the plate earlier. This page for example: http://www.mapability.com/info/vmap1_download.html mentions the bounding boxes of the respective VMap1 datasets. Before cutting out VMap0 we'll have to know if lat/lon of these boxes is really accurate or not. Shapefiles are available now, each of them contains the complete VMap1- coverage of the respective layer. Feel free to have a look at them if you like: ftp://ftp.uni-duisburg.de/FlightGear/TGShapes/*_vmap1.tar.bz2 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
2006/6/15, Frederic Bouvier [EMAIL PROTECTED]: Olaf Flebbe wrote : Hi, let me comment on the current apt.dat performance i.e. of the time spent in fgAirportDBLoad: ~25% of time time is spent in simgear::strutils::split ~10% is spent in atof() Measured with Intel VTune using MS Visualc C++ 2005. IMHO it is an indicator that we should not use a plain text format. I have no experiences with the performance of binary XML representations. There is not much information here. If you tell us what cost us fgAirportDBLoad in the whole initialisation process, we could decide if it's worth optimizing it. Reading the airportlist needs roughly half of the startup time. And you're missing a bit of history here : The airport file used to be binary and it was decided that a text file was easier to maintain. No endianess or integer size problem, no compilation phase. MetaKit was a PITA at the time. I didn't know this. Was there an attempt to create a binary representation on-the-fly when a new apt.dat was detected? Cheers Olaf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
On Jun 14, 2006, at 8:23 PM, Jon S. Berndt wrote: Maybe said a different way, imagine your wing is riding on the edge of the amount of air it can push down without stalling. Now you deflect the aileron down and try to push the air down even more. Stupid me. I forgot something. OK, deflecting an aileron is like deflecting a flap. If you look at a lift curve from a wing section you can see that deflecting a flap (aileron) increases the lift coefficient, but you also reduce your stall angle. That would be enough to do it for that portion of the airfoil. Jon There tends to be another issue here as well. And it might relate to what Curt experienced. When teaching students to do slow flight (near the edge of stall) the temptation is to use aileron to correct. If they do that, what can happen is that the down wing, that they want to raise, will get down aileron, more lift, and an increase in induced drag. That increase in drag will pull the wing back. Thus there is a yaw induced, that can have the same affect as using rudder...a spin! As an additional complication, wings don't stall all at once, instead it is a progressive event. When a wing is on the edge of stall the trailing edge is where the stall will start. So it is possible that a wing that is nearly stalled will have have some flow separation at the trailing edge. That is also where the ailerons are. Down aileron can cause flow separation and a decrease in lift, with an increase in drag, and that wing can drop on you. When in slow flight students have to be taught to use rudder instead of aileron, or the CFIs get nervous ;-) --Adam ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
On Jun 14, 2006, at 8:33 PM, Josh Babcock wrote: Jon S. Berndt wrote: Snap roll: This is indeed the recipe for a snap roll: starting from a speed slightly above the stall, apply a sudden yaw with the rudder, apply opposite aileron, and pull back on the yoke. SNAP! --- One wing stalls and the plane rolls over. [I liked the clever use of the word, recipe with the phrase snap *roll*] This would be hard to model using lookup tables, but it might be possible using JSBSim functions and a table or tables, together. Could be fun. I need to think about this one. The first idea that comes to mind is that if the aircraft speed minus the yaw rate times some characteristic lateral length (span/2?) falls below the stall speed, then a rolling moment would be generated - maybe a yawing moment, too. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel My understanding is that a snap roll is initiated by yaw-roll coupling. The lower wing is put into the turbulent flow behind the fuselage by the hard yaw. This imparts a strong roll moment, and the result is that the AOA of the upper wing goes down, while the AOA of the lower wing goes up into the stall region. At that point the partial loss of lift on the down wing becomes almost complete, while the upper wing only loses a small amount of lift. If it were done at a low AOA you would only get roll damping as the low wing would go into a high AOA high lift regime, while the upper wing would go into a low AOA low lift regime. You need to be close enough to stall that the lower wing goes past the high lift regime and into the stall regime. I may be wrong about that. If the roll were initiated on the back side of the lift curve, the upper wing would actually gain lift in the roll, and the lower one would lose it as it goes into stall. I'm not sure which is right, but I'm pretty sure that to get a roll going fast enough to get only one wing into a stall you have to have the yaw-roll coupling. Otherwise roll damping would limit you to a mere barrel roll. So for JSBSim, you would need to add another dimension to your lookup tables that indicates the loss of lift as an airfoil goes through the turbulent wake of other elements like the fuselage. Not a bad idea really, but it's a lot of data and probably pretty hard to find. You would also need separate R/L wing elements. Josh I don't believe so. Remember that a snap roll is a type of spin. So probably this discussion should focus on simulating spins more generally. It is easy to enter a spin. For a simple spin the aircraft is just put in slow flight, near stall, and then some yaw is added, but a lot is generally not necessary (depends on the aircraft). I don't believe that it is enough to blanket the lower wing behind the fuselage. I believe that the main effect is just that the yaw rate is enough that the two wings are flying at different speeds. Essentially, like a helicopter, there is a retreating wing and an advancing wing. If both wings are near stall, then that retreating wing , going a little slower (or effectively a higher AOA), will stall, and you will end up in a spin. A snap roll is only different in that the aircraft is generally at a higher airspeed, so a high pitch rate is necessary to get the aircraft to that stall AOA, instead of just causing a climb, and a slow airplane. But the dynamics are still just high AOA, then yaw rate causing a wing to stall. It might be possible to simulate spins (and snap rolls) by just adding a new term to JSBSim that is essentially loss of lift due to yaw rate (or something similar...maybe normalize to Cl difference?). But it would have to be a table that would look like a Cl_Alpha curve, so that it would capture the stall on the wing. I believe, as Jon mentioned, that it could be done with a table, showing wing lift difference, from average alpha and yaw rate. And, just to complicate things, inverted spins are fun to do, and there could be some sign issues to keep in mind for the above table to also work that way as well. --Adam ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] statistics: usage of texture memory (shocking!)
On Thu, 15 Jun 2006 17:43:12 +0200, Olaf wrote in message
[EMAIL PROTECTED]:
2006/6/15, Melchior FRANZ [EMAIL PROTECTED]:
* Olaf Flebbe -- Thursday 15 June 2006 13:44:
The tremendous texture memory is a performance killer for lowend
graphics like intel 91x. (I got 1 Frame/sec.) I worked out a patch
to plib, reducing all flightgear texture sizes and got 15
Frames/sec.
That patch will probably collide with Fred's fix that is in CVS
since a few weeks (months?).
I didn't see a reduced memory size.
Do you not use CVS/HEAD?
plib: No, Flightgear/simgear: Yes.
I did a plib tweak with a flightgear frontend to set the maximal
texture size. I do not have the low and laptop handy in order to
double check todays frames/second performance of fg. I did this
several months ago.
..in a similar vein: Is there way to set the jpg-factory
screen shot size, other than at compile time by editing
this bit in SimGear/simgear/screen/jpgfactory.hxx ?:
typedef enum {
DEFAULT_XS = 320,
DEFAULT_YS = 240
} JPG_FACTORY_ENUM;
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] statistics: usage of texture memory (shocking!)
Hi,
..in a similar vein: Is there way to set the jpg-factory
screen shot size, other than at compile time by editing
this bit in SimGear/simgear/screen/jpgfactory.hxx ?:
typedef enum {
DEFAULT_XS = 320,
DEFAULT_YS = 240
} JPG_FACTORY_ENUM;
Does this relate in any way to the discussion in this thread?
I doubt that this definitions is actually used in the code: In
jpg-httpd the factory is initialized as 400x300.
JpgFactory-init(400,300);
screenshots (In FlightGear Menu called Snaphots) are done differently.
Size of snapshots are controlled by /sim/startup/xsize and ysize
respectivly. gui_funcs.cxx around line 570.
Olaf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Reading the airportlist needs roughly half of the startup time Sorry, more precisly it is 19% ;-) ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Thursday 15 June 2006 15:32: * Melchior FRANZ wrote: My preference is, of course, to switch and let loadfn die immediately. :-) Yes, I can imagine but I think the cases where the old code is/has been used outside of the FlightGear scope are all cases that draw attention to FlightGear (universities and research organizations). I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. And let the old code how and where it is for compatibility reasons? It turns out that I can't do much more improvements and fixes if I have to keep all the old shit that I wanted to get rid of in the first place. Chicken/Egg. :-/ m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: * Erik Hofman -- Thursday 15 June 2006 15:32: I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. And let the old code how and where it is for compatibility reasons? It turns out that I can't do much more improvements and fixes if I have to keep all the old shit that I wanted to get rid of in the first place. That's why I said I would copy the necessary files (all HUD related code) to Instrumentation/HUD and rename the class(es) and leave the old code to rust away. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] IMPORTANT: SimGear CVS Logs mailing list
SourceForge has kindly removed all but 5 subscribers to the simgear-cvslogs mailing list. I have no idea what happened or why. If you would like to receive commit log messages for the SimGear sub-project, then please go to the simgear-cvslogs subscription page and resubscribe yourself. http://mail.flightgear.org/mailman/listinfo/simgear-cvslogs Sorry for any inconvenience. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] IMPORTANT: SimGear CVS Logs mailing list
Curtis L. Olson wrote: SourceForge has kindly removed all but 5 subscribers to the simgear-cvslogs mailing list. I have no idea what happened or why. If you would like to receive commit log messages for the SimGear sub-project, then please go to the simgear-cvslogs subscription page and resubscribe yourself. http://mail.flightgear.org/mailman/listinfo/simgear-cvslogs Sorry for any inconvenience. Errr, looks like a posted this warning before I looked closely enough. Your subscriptions are all still intact. There may be a problem with this list at the moment though. And I suppose it is still a good idea to check on the status of your mailing list subscriptions once in a while. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Adam Dershowitz wrote: I don't believe so. Remember that a snap roll is a type of spin. So We are probably both right. If the wing were to be split into several sections, the effect that you describe would be approximated (a-la X-plane), or you could add another table which could be much more accurate. I still think that the turbulent shadow effect (I cannot remember the proper name) is another important one to pay attention to. In low wing aircraft both these contribute to yaw-roll coupling, which is the source of many interesting phenomena including dutch rolls. They can also be a factor in higher frequency PIOs. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update to the C-182
Hi Stuart, Buchanan, Stuart wrote: I've been working on an update to the c182. Improvements over previous version: I got interested in this update as I hopefully will soon have a briefing for the C182Q (D-EVOS). I found applying the patch to result in a difficult task, because I had to arrange the correct mix of DOS line endings and Unix line endings to make 'patch' happy. Finally 'patch' survived but the result got rejected by FlightGear (could not read aircraft from Aircraft/c182/Models/c182-dpm.xml or something like that). Would you consider removing all DOS line endings from the '.xml' and '.ac' files and creating a new patch ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
How about some stub functions ?It's kind of temporary patch up that's organized in one place.So later on, you know where to look in to delete the obsolete stuff.IsaoErik Hofman [EMAIL PROTECTED] wrote: Melchior FRANZ wrote: * Erik Hofman -- Thursday 15 June 2006 15:32: I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. And let the old code how and where it is for compatibility reasons? It turns out that I can't do much more improvements and fixes if I have to keep all the old shit that I wanted to get rid of in the first place.That's why I said I would copy the necessary files (all HUD related code) to Instrumentation/HUD and rename the class(es) and leave the old code to rust away.Erik-- http://www.ehtw.info (Dutch) Future of Enschede Airport Twentehttp://www.ehofman.com/fgfs FlightGear Flight Simulator___Flightgear-devel mailing listFlightgear-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] statistics: usage of texture memory (shocking!)
On Thu, 15 Jun 2006 21:24:52 +0200, Olaf wrote in message
[EMAIL PROTECTED]:
Hi,
..in a similar vein: Is there way to set the jpg-factory
screen shot size, other than at compile time by editing
this bit in SimGear/simgear/screen/jpgfactory.hxx ?:
typedef enum {
DEFAULT_XS = 320,
DEFAULT_YS = 240
} JPG_FACTORY_ENUM;
Does this relate in any way to the discussion in this thread?
..I dunno yet, I'm gonna find out after I get TerraGear built, your
fooling around in plib to hike fps up by 15 times tells me you
might be able to point me the right way.
I doubt that this definitions is actually used in the code: In
jpg-httpd the factory is initialized as 400x300.
..this matches what I see chking the jpeg's coming out.
In the code, where, FG?
JpgFactory-init(400,300);
screenshots (In FlightGear Menu called Snaphots) are done differently.
Size of snapshots are controlled by /sim/startup/xsize and ysize
respectivly. gui_funcs.cxx around line 570.
..maybe, these change the display within the main window and
probably the screen shot sizes too, and yeah, that's a different
show from jpeg-factory.
..found it in FlightGear/src/Network/jpg-httpd.hxx:
public:
HttpdImageChannel() : buffer(512) {
setTerminator(\r\n);
JpgFactory = new trJpgFactory();
// This is a terrible hack but it can't be initialized until
// after OpenGL is up an running
JpgFactory-init(400,300);
}
..huh? If OpenGL is dead, kill FG too, or ask if SW rendering is ok.
..is also possible to control jpg fps (5Hz) and picture
quality (90%) at compile time now.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VMAP1 in Landcover-DB
Martin Spott wrote: Jon Stockill wrote: Is the map definition file available anywhere so I can see what layers you have defined? http://mapserver.flightgear.org/landcover.map This is still work in progress - as always ;-) - because I didn't finish adding all the VMAP1-layers. Ok, I think the file is now complete in the sense that it contains all layers where the (still unchanged) landcover selection retrieves at least one object from VMap1, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] statistics: usage of texture memory (shocking!)
On Fri, 16 Jun 2006 00:06:25 +0200, Arnt wrote in message
[EMAIL PROTECTED]:
..are we trigger happy today. %o)
On Thu, 15 Jun 2006 21:24:52 +0200, Olaf wrote in message
[EMAIL PROTECTED]:
Hi,
..in a similar vein: Is there way to set the jpg-factory
screen shot size, other than at compile time by editing
this bit in SimGear/simgear/screen/jpgfactory.hxx ?:
typedef enum {
DEFAULT_XS = 320,
DEFAULT_YS = 240
} JPG_FACTORY_ENUM;
Does this relate in any way to the discussion in this thread?
..I dunno yet, I'm gonna find out after I get TerraGear built, your
fooling around in plib to hike fps up by 15 times tells me you
might be able to point me the right way.
I doubt that this definitions is actually used in the code: In
jpg-httpd the factory is initialized as 400x300.
JpgFactory-init(400,300);
screenshots (In FlightGear Menu called Snaphots) are done
differently.
Size of snapshots are controlled by /sim/startup/xsize and ysize
respectivly. gui_funcs.cxx around line 570.
..maybe, these change the display within the main window and
probably the screen shot sizes too, and yeah, that's a different
show from jpeg-factory.
..found it in FlightGear/src/Network/jpg-httpd.hxx:
public:
HttpdImageChannel() : buffer(512) {
setTerminator(\r\n);
JpgFactory = new trJpgFactory();
// This is a terrible hack but it can't be initialized until
// after OpenGL is up an running
JpgFactory-init(400,300);
}
..huh? If OpenGL is dead, kill FG too, or ask if SW rendering is ok.
..is also possible to control jpg fps (5Hz) and picture
quality (90%) at compile time now.
..now, there's also runtime, and property trees to grow and poke.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
On Thu, 15 Jun 2006 18:08:25 -0500, Jon wrote in message [EMAIL PROTECTED]: Hmm, so how would JSBSim model low speed control reversals like this? Could it be done in a way that would also be able to model transonic control reversals that are caused by shockwaves near the control surface hinge? Josh I've got several ideas in mind. One is that the wing could be split up into sections for tip, aileron, interspan, flap, root. Alpha and spanwise velocity would be calculated for each section. Then, lateral effects due to the wing would be calculated. I think that would be rolling moment due to wing effects, and yawing moment due to wing effects. It would incorporate rolling moment due to aileron deflection, roll moment damping, roll due to yaw rate. Maybe other things as well. On the yaw side: yaw moment due to aileron deflection, yaw damping, and yaw moment due to roll rate. Another idea would be to just add additional incremental aerodynamic effects based on carefully calculated or devised functions or tables, etc., instead of the whole approach given above. Another approach might be to detect a stall at a specific wing location based on some given parameters, then manufacture an incremental aerodynamic effect based on that. There are a lot of ways to do this, but it should be done so as to not break the existing paradigm, but instead to fit within it. ..another big deal to dig up: Downwash. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
..another big deal to dig up: Downwash. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) There may end up being some things that don't get specifically addressed, but must be defined by the user with functions and tables. What I'd like most to do is to provide all the basic building blocks needed so that the user is free to create the model they'd like to create. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
On Thu, 15 Jun 2006 18:45:22 -0500, Jon wrote in message [EMAIL PROTECTED]: ..another big deal to dig up: Downwash. There may end up being some things that don't get specifically addressed, but must be defined by the user with functions and tables. What I'd like most to do is to provide all the basic building blocks needed so that the user is free to create the model they'd like to create. ..aye, I have a multi-fdm idea, that needs both downwash and collision detection turned off, to show how they respond differently to gusts etc, say a red 3d model for JSBSim, orange for yasim, yellow for LaRCSim, green for UIUC, cyan for UIUC-tail ice, blue for UIUC-wing ice, violet for UIUC-all-ice etc, and match those colors so they merge as one white. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
