RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Questions about problems with the particle system
Hi, I've done some work on the particle system using the primitives of PLIB. I've also got some screenshots about my work and Vivian had put them on the web (thank you again). They are here: http://myweb.tiscali.co.uk/vmeazza/FlightGear/particle1.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/particle2.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/particle3.jpg I've however some problems. The first and the second screenshots are made with the simulator freezed and the only difference is the position of the head of the pilot. Why the object change their color? (The right texture is the white green). I've a similar problem with the point of view out of the cockpit: the objects, when visible, are red (the red that appears when the texture it's not loaded, I know because I've already seen it)? Why this happens? The texture is loaded, but it appears only in the cockpit view. Another problem is the billboarding, I think. When the particle system is created there's a boolean used to make it a billboard. I've set it to true but seems that the particles appears only when the POW is directly afore them. I've seen the base code of the particle system and I've found that to create a billboard it's used the matrix GL_MODELVIEW_MATRIX defined into the OpenGL header. This could be the problem or this matrix is updated with the current point of view (maybe this question is for the PLIB develepers, but I make it anyvay)? Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS - Problems
On compiling the CVS download under Cygwin this morning I get the following error: tilemgr.cxx: In member function `void FGTileMgr::update_queues()': tilemgr.cxx:288: error: `size' undeclared (first use this function) tilemgr.cxx:288: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [tilemgr.o] Error 1 make[2]: Leaving directory `/flightgear-cvs/source/src/Scenery' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/flightgear-cvs/source/src' make: *** [install-recursive] Error 1 Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
(I'm sending this directly to the mailing list, as I haven't yet received any replies from Curt himself, who's probably too busy anyway) As I mentioned already on the user-mailing list a couple of days ago, Stewart Steven Andreason have finished their tardiff script - a perl script that creates patch files for two different versions of tar-archives. This script has meanwhile been heavily modified, so that it should now be able to deal with most 'track-able' changes between two different versions of an archive, and thereby reducing the required download time, as only a patch needs to be downloaded and not the whole archive itself. This is interesting and relevant for FlightGear cause it enables easy creation of (usually) *SMALL* patch archives, so that users won't have to download a complete base-package (~ 90 MB) from flightgear.org if they want to upgrade to a newer (pre-)release. So far, the patch archives between two successive versions were usually approx. 2-5 MB in size - so this is indeed a significant reduction of more than 90 %. Of course, the exact size is likely to vary in the future, depending on the changes that are being made and whether tardiff itself is smart enough to track them down. But even the patch from 0.9.4(final) to 0.9.6-pre1 is 'only' about 25 MB- so less than 1/3 of the actual base-package download itself. QUESTION: Because of this obvious advantage (particularly for users with slow dial-up connections, but also for those among us who have broadband access, but don't like to wait... ) we would now like to know what the rest of you thinks about adding those tardiff based patches as an OFFICIAL alternative *directly* to the FlightGear webpage as option to the downloads section for FlightGear's most recent base packages. + As most FlighGear users probably won't want to run 'tardiff' directly, but would rather choose to only download the created patches for their respective fgfs-base directory, a sourceforge project was set up. Actually, the whole process of applying the patch is rather simple, it involves only: - determining what base package version you're using right now - download the correct patch for the latest fgfs-base package - backup your existing base-package (just in case ...) - apply the patch by extracting the patch-archive - running the final finish-script - (a unix win shell scrip) = DONE ! So, the plan is, to also provide future patches via that sourceforge project - this is a very straight forward process and takes less than 5 minutes. At: https://sourceforge.net/projects/tardiff you can find the project's sourceforge page, where the patches are also being made available - the homepage (including extensive documentation) can be found at http://tardiff.sourceforge.net - tardiff itself is general enough to be also used for other projects, too. So, ultimately this would not only reduce traffic for flightgear.org and its mirrors but it wouldn't even consume any resources on flightgear.org or its mirrors either. Thanks for your feedback. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS - Problems
Vivian Meazza wrote: On compiling the CVS download under Cygwin this morning I get the following error: tilemgr.cxx: In member function `void FGTileMgr::update_queues()': tilemgr.cxx:288: error: `size' undeclared (first use this function) tilemgr.cxx:288: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [tilemgr.o] Error 1 make[2]: Leaving directory `/flightgear-cvs/source/src/Scenery' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/flightgear-cvs/source/src' make: *** [install-recursive] Error 1 You will have to update SimGear also ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions about problems with the particle system
Luca Masera wrote: Hi, I've done some work on the particle system using the primitives of PLIB. I've however some problems. The first and the second screenshots are made with the simulator freezed and the only difference is the position of the head of the pilot. Why the object change their color? (The right texture is the white green). This is doe to the reflection of the sun on the particles. To change that you will have to set the reflective color of the vertex to 0.0 and the ambient and diffuse colors very close to each other (say 0.49 for ambient and 0.51 for diffuse). Another problem is the billboarding, I think. When the particle system is created there's a boolean used to make it a billboard. I've set it to true but seems that the particles appears only when the POW is directly afore them. I've seen the base code of the particle system and I've found that to create a billboard it's used the matrix GL_MODELVIEW_MATRIX defined into the OpenGL header. This could be the problem or this matrix is updated with the current point of view (maybe this question is for the PLIB develepers, but I make it anyvay)? There are multiple ways for a billboard to behave, most common are spherical (the object always faces the viewer with the same side up) and cylindrical (the object always faces the viewer but the upward pointer is aligned with the scenery all the time, useful for trees for example). For particles you will need to make sure it behaves spherical. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
Boris Koenig wrote: Because of this obvious advantage (particularly for users with slow dial-up connections, but also for those among us who have broadband access, but don't like to wait... ) we would now like to know what the rest of you thinks about adding those tardiff based patches as an OFFICIAL alternative *directly* to the FlightGear webpage as option to the downloads section for FlightGear's most recent base packages. I find it a useful addition for modem users, but my only concern is that it will increase the number complaints about something not working while in fact their base package is somehow corrupted. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
Erik Hofman wrote: Boris Koenig wrote: Because of this obvious advantage (particularly for users with slow dial-up connections, but also for those among us who have broadband access, but don't like to wait... ) we would now like to know what the rest of you thinks about adding those tardiff based patches as an OFFICIAL alternative *directly* to the FlightGear webpage as option to the downloads section for FlightGear's most recent base packages. I find it a useful addition for modem users, but my only concern is that it will increase the number complaints about something not working while in fact their base package is somehow corrupted. While there were -so far- not any problems regarding something like that, I did also think about that possibility - that's why I would recommend to only release those patches that have been tested by running each created patch against the (old) base-package that it is supposed to patch, and directly compare the resulting (patched) folder structure with the one of the actual (original) base package, BEFORE publishing future patches. While it would be additional work, it can surely be automatized using a simple shell script [1], but we would at least make sure that the patch creates an identical folder structure. So, only those patches would be released. Boris [1]: patches could be checked for their validity by using the already created checksums of the original archive, possibly using the finish shell script. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] BO105 starting procedure - Melchior Franz
Hi, On Thu, Sep 16, 2004 at 12:01:34AM +0200, Georg Vollnhals wrote: my knowledge gaps are significant as I was more interested in aerodynamics and flying procedures until now. But I have the chance to discuss some of these questions with a helo pilot (hopefully with BO105 typerating and experience) the next weekend as I am on helo-rescue duty next Saturday/Sunday. Shall I report via eMail to you and protect all the other readers from this very special stuff? Is there any other question you are interested in that I should ask? Not right now. As I say in every other message: I do know a (German) Bo105 pilot myself. I guess asking him directly is a bit more effective. (I thought you were a helicopter pilot, not just a passenger -- which I am myself :-). After my opinion the AB204 = Bell 204 = (military) UH 1D has no clutch [...] Yet another opinion ... Note, that I don't really care for the AB204. I'm not going to model it. It's an oldtimer and hardly flying anywhere any more. Let's stick with the Bo105. There is always a delay between the running-up turbine (gas producer, N1) and the rotor movement Maybe I mistook that as the turbine first, then rotor effect. Once I implement the rotor brake, I'll need to know what I had to expect model in this case. (High temperature in both turbines? Unpleasant noise? Warining light/sound? :-) (.. third question to ask) But I am not sure any of our pilots has real-life experience with this! :-)) Hehe. A bit expensive to try. Maybe I can persuade someone. ;-) I'll download and read the manual that you linked to in your last email. Then I'll start to model the startup procedure more accurately. There will be a lot more questions then that require the expertise of a real pilot. (E.g. You say that one ignites at 10%, but how many RPM percent can the starter achieve if I don't? etc.) I'll come back for feedback then. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
On Thu, 16 Sep 2004 11:11:21 +0200, Boris wrote in message [EMAIL PROTECTED]: Erik Hofman wrote: Boris Koenig wrote: Because of this obvious advantage (particularly for users with slow dial-up connections, but also for those among us who have broadband access, but don't like to wait... ) we would now like to know what the rest of you thinks about adding those tardiff based patches as an OFFICIAL alternative *directly* to the FlightGear webpage as option to the downloads section for FlightGear's most recent base packages. I find it a useful addition for modem users, but my only concern is that it will increase the number complaints about something not working while in fact their base package is somehow corrupted. While there were -so far- not any problems regarding something like that, I did also think about that possibility - that's why I would recommend to only release those patches that have been tested by running each created patch against the (old) base-package that it is supposed to patch, and directly compare the resulting (patched) folder structure with the one of the actual (original) base package, BEFORE publishing future patches. While it would be additional work, it can surely be automatized using a simple shell script [1], but we would at least make sure that the patch creates an identical folder structure. ..do further tests: md5sum all files in the official package and and the patched package and compare those. Also, those that fail this test may still work, but now we know they're different. ..and, there is also good old rsync. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Particles billboarding
Erik Hofman wrote: This is doe to the reflection of the sun on the particles. To change that you will have to set the reflective color of the vertex to 0.0 and the ambient and diffuse colors very close to each other (say 0.49 for ambient and 0.51 for diffuse). Yes, it works right now. The texture appears from all the views. There are multiple ways for a billboard to behave, most common are spherical (the object always faces the viewer with the same side up) and cylindrical (the object always faces the viewer but the upward pointer is aligned with the scenery all the time, useful for trees for example). For particles you will need to make sure it behaves spherical. I understand what you mean but in the code there isn't such an option about this. Simply, the matrix that defines the position of the particle is multiplied by the matrix that defins, I suppose, the position of the viewer (using GL_MODELVIEW_MATRIX). So I think that the problem is the latter matrix, that I guess it's not istantiated. I'll try to write another function that gets from the FGViewer class the position of the user and use it instead of GL_MODELVIEW_MATRIX. About FGViewer... I've already seen this class and there's a lot of getters that return the position in cartesian coords, but I don't know which is the right one. Which is the real difference between the following methods (they return a float*): get_view_pos(), get_absolute_view_pos(), getRelativeViewPos(). I don't understand it from the comments... :-( and... if get_VIEW returns a matrix, could I use it as is? Thanks, Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: Sent: Thursday, September 16, 2004 8:33 AM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. I've checked and tested the submodel code. The submodel definitely inherits the parent velocities. Unfortunately, there's a basic snag: in order to get tracer to go in the right direction, I inserted a -ve rotation in pitch, but while making tracer correct, it applies an inverted pitch sense to droptanks/bombs. I don't understand why at this stage. Back to the drawing board! There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Thursday 16 September 2004 18:08, Vivian Meazza wrote: Vivian Meazza wrote: Sent: Thursday, September 16, 2004 8:33 AM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. I've checked and tested the submodel code. The submodel definitely inherits the parent velocities. Unfortunately, there's a basic snag: in order to get tracer to go in the right direction, I inserted a -ve rotation in pitch, but while making tracer correct, it applies an inverted pitch sense to droptanks/bombs. I don't understand why at this stage. Back to the drawing board! There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Thanks for the updates Vivian. I have complete confidence that you'll get it working;) I'll comment out the bomb release key-mapping for now, do some documentation and get an archive-package sorted out. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
