Re: [Flightgear-devel] Memory leak
* Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender to ac3d material exporting
Robicd wrote: Where? Sorry, I've found it. Silly question :-) ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. They are not designed for that either. It can be useful for sound processing and color adjustments where very high precision isn't necessary. I use it for instance for gamma correction on my O2. It does give me a framerate improvement. 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
Re: [Flightgear-devel] [RFC] HUD
On Saturday 17 June 2006 10:05, Erik Hofman wrote: Mathias Fröhlich wrote: I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. They are not designed for that either. It can be useful for sound processing and color adjustments where very high precision isn't necessary. I use it for instance for gamma correction on my O2. It does give me a framerate improvement. Well, but gamma correction happens often. At ervery frame width times height pixels times number of colors. That are easily more than 1e6 operations a second. I can hard imagine an operation in flightgear that happens that often, dominates the computation time *and* that does not require some minimum accuracy. I for myself would not use them for the HUD. Too few invocations (that is: potential speedup) compared to the subtle problems that can arise. For the sound stuff, I do not even see, if sound is disabled or enabled, so I can hard imagine to see the improovement of the fastmath functions from the sound subsystem. Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
On Saturday 17 June 2006 01:11, Joacim Persson wrote: On Sat, 17 Jun 2006, Mathias Fröhlich wrote: Given the error message, I could imagine a that the attached patch helps. Can you please tell me if that patch helps? Compiled without a warning on mat.cxx now. (Was that all? Couldn't handle that method as inline?) I believe I know what the problem is: At the time of implementation there must be more available then just the forward decl of that SGGlyphMaterial. Sad that the others tolerate that code ... I will check that in now, thanks for the feedback ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. I've never advocated using these routines for FMD's or anything like that since it could get messy really quick. But tests using the fastmath routines have revealed a considerable speed increase when compared with the C library functions solely because they are lossy and imperfect. 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
Re: [Flightgear-devel] [RFC] HUD
Hi Erik, On Saturday 17 June 2006 10:54, Erik Hofman wrote: Mathias Fröhlich wrote: Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. I've never advocated using these routines for FMD's or anything like that since it could get messy really quick. But tests using the fastmath routines have revealed a considerable speed increase when compared with the C library functions solely because they are lossy and imperfect. If you feel that they should be used, can you care for them and make them alias safe? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Friday 16 June 2006 09:34: It think it would be best to use offset and factor just like most of the other configurations (sound/animations). I'm now using property/factor/offset for all numeric values. Some HUD elements need two values. I'm now just using property n=1/ factor n=1/offset n=1 for those. That's a bit ugly and one could put it into a group. But then one would also have to put such a tuple into a group even if there's only one. (?) Also, I'd like to dump the silly element groups, as in: instruments hudladder pathHuds/Instruments/Default/hudladder.xml/path /hudladder hudcard pathHuds/Instruments/Default/hudcard.xml/path /hudcard ... I see no reason why the elements should be grouped by type and loaded in chunks. I'd rather prefer something like: instruments pathHuds/Instruments/Default/hudladder.xml/path pathHuds/Instruments/Default/hudcard.xml/path ladder ... contents ... /ladder card ... /card card // ... /card that is: all HUD elements simply on one level, but a way to import further files. I'd call that include but everywhere else path is used, so that's probably better. Of course, one could use the include attribute (foo include=...), but this is only allowed once, and it doesn't add the imported stuff, but replace the old if the indices are the same, so it's really useless. Ideas? Objections? m. ___ 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
--- Martin Spott wrote: 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 ? cvs.flightgear.org is currently unreachable, and I'm going to be out of town for the next week, so I've cleaned the files, tarred the entire Aircraft/c182 directory and uploaded it to http://www.nanjika.co.uk/flightgear/c182.tar.gz. Just replace your c182 directory and you should be good to go. Note that it has a dependency on the pilot model patch (http://www.nanjika.co.uk/flightgear/pilot.tar.gz), but this can be easily removed by editing c182-dpm.xml and removing the model on line 79. Let me know what you think. -Stuart ___ All New Yahoo! Mail Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html ___ 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
Buchanan, Stuart wrote: Note that it has a dependency on the pilot model patch (http://www.nanjika.co.uk/flightgear/pilot.tar.gz), but this can be easily removed by editing c182-dpm.xml and removing the model on line 79. I simply removed the complete references to the pilot both in 'Models/c182-dpm.xml' as well as to 'pilot.nas' in 'c182-set.xml' because I was unwilling to deal with another pilot for now :-) The aircraft looks fine to me - at least better as the first one, the yellow lines at the model edges have disappeared in your update. Still I think there's room for improvement: 1.) The nose of the aircraft looks a bit 'flat', when compared for example to this one: http://www.texelairport.nl/fotogroot/D-EVOS.jpg (C182Q) or even this one (the README says FlightGear has this type) http://www.linzaviation.com/images/flotte_c182_large.jpg (C182S) 2.) I guess this is not affected by your work on the model, still I don't want to miss the chance: I'd expect such a small aircraft with a 230 HP engine to run a bit faster than 120 kts at full throttle at a few 1000 feet. 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
Mathias Fröhlich wrote: If you feel that they should be used, can you care for them and make them alias safe? Not at this time, I've got other things on my prioritylist. 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] Joystick and DEAD-BAND
Hi there! I'm trying to configure my joysticks to use it with FGFS. I'm having trouble with the dead-zone setting that seems to do nothing. My joy is not very new and has a big dead zone (-0.1,0.1) and I'm trying to set sead-band to 1.0 or even greater values. But it did not work. How can I solve this? Because it's terrible to see how controls move from time to time a lot! Thank you. -- Gonzalo Aguilar Delgado - Ingeniero en Informática [ Seguridad Medios de pago ] ___ 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
Looks like a spin, does not it ? ;) That is with stock JSBSim FDM ... attachment: spin.jpg ___ 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
Very cool. I guess you survived, or you would not be writing this. ;-) Did the spin seem to enter and exit normally? Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of flying.toaster Sent: Saturday, June 17, 2006 10:04 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim Looks like a spin, does not it ? ;) That is with stock JSBSim FDM ... ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? LeeE ___ 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
Well actually I did not survive that one, I was too busy taking the shot ;) But I did survive many others Entry and exit is by the book : - stall the aircraft with wings level using gentle full back stick and apply full rudder to enter - release the stick and rudder, let the nose point down and catch un speed + pullout to exit The spin may be more or less flat depending on engine power and roll at the begining of the spin. After 2 to 3 turns it seems to be willing to go flat (as you can see on the picture alpha was fairly close to 90º) Snap rolls are also accomplished in a similar manner by using brisk full aft stick at high speed (full throttle) and full rudder. You get a very important roll rate but speed bleeds very quickly and after one turn you'd rather release the stick or you end up loosing a lot of height (turns into a spin). Inverted spins are tougher to perform though because the aircraft wants to get upright into a regular spin (takes a lot of aileron to keep the spin inverted) Message du 17/06/06 à 17h21 De : Jon S. Berndt [EMAIL PROTECTED] A : [EMAIL PROTECTED], FlightGear developers discussions flightgear-devel@lists.sourceforge.net Copie à : Objet : Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim Very cool. I guess you survived, or you would not be writing this. ;-) Did the spin seem to enter and exit normally? Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Joystick and DEAD-BAND
On Saturday 17 June 2006 08:18 am, Gonzalo Aguilar Delgado wrote: Hi there! I'm trying to configure my joysticks to use it with FGFS. I'm having trouble with the dead-zone setting that seems to do nothing. My joy is not very new and has a big dead zone (-0.1,0.1) and I'm trying to set sead-band to 1.0 or even greater values. But it did not work. How can I solve this? Because it's terrible to see how controls move from time to time a lot! Thank you. I had the same problem when setting up my joystick taken from README.joystick.html that ended up working for me: You may recall from the section about raw axis value modifiers that dead-band is implemented outside the command manager. This means that if you want to apply a dead-band, the tag *must* precede the binding tag. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] www/cvs/ftp outage
We had some severe storms come through last night with an associated power outage. The power along with the flightgear machines that host www, ftp, cvs, and rsync services are back online. 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] [RFC] HUD
On Saturday 17 June 2006 14:54, Erik Hofman wrote: Mathias Fröhlich wrote: If you feel that they should be used, can you care for them and make them alias safe? Not at this time, I've got other things on my prioritylist. Ok, the ones in fastmath.hxx are easy to fix, I have already prepared a checkin for that. The ones in the fastmath.cxx look really ugly to fix. If we would have no different compiler than gcc I would have suggested to add a special compile flag to fastmath.cxx to avoid gcc optimizing too much away. But we also have to support other compilers ... So I have to note that many of these functions are expected to be misscompiled by modern compilers that care for alias sets like current gcc's do. Anyway, you still try to sell to me that (in case of fast_fabs for example) it is faster to take a floating point value probably already being loaded in the fpu push it into memory reload it into the integer unit do some bit fiddling push it back into memory and reload it into the floating point unit to do further computations with that is faster than just take the fpu register and execute a fabs operation on that? Seriously, I *can* think of fast_atan's polynomials being faster than a full blown correct functioin. But those simple fabs, sign or neg function implemented in the header cannot even be faster than the cpu builtin assembler instructions usually available on current cpu's. Also, in presence of sse instructions forcing that fist legacy i386 fpu instruction in that assembler snipet will not make it faster (unloading from sse unit, loading to legacy fpu, in contrast to do the same directly in the sse unit ...). Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OT, linking foilgen.f
I'm trying to get some data on the B-47 wing, but I need to generate a .dat file of the airfoil to run xfoil against. Supposedly foilgen will handle 6a series NACA airfoils, but I can't get foilgen to link properly to test it. Does anyone have any suggestions? Josh tower:src$ g77 foilgen.f tower:src$ ld -o foilgen a.out tower:src$ ldd foilgen ./foilgen: error while loading shared libraries: ./foilgen: unsupported version 8051 of Verneed record tower:src$ ldd a.out linux-gate.so.1 = (0xe000) libg2c.so.0 = /usr/lib/libg2c.so.0 (0xb7f35000) libm.so.6 = /lib/tls/libm.so.6 (0xb7f0f000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb7f04000) libc.so.6 = /lib/tls/libc.so.6 (0xb7dcc000) /lib/ld-linux.so.2 (0xb7f7a000) tower:src$ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT, linking foilgen.f
Josh Babcock wrote: I'm trying to get some data on the B-47 wing, but I need to generate a .dat file of the airfoil to run xfoil against. Supposedly foilgen will handle 6a series NACA airfoils, but I can't get foilgen to link properly to test it. Does anyone have any suggestions? Like, for instance reading the man page. Apologies. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Joystick and DEAD-BAND
On 17 Jun 2006, Gonzalo Aguilar Delgado wrote: My joy is not very new and has a big dead zone (-0.1,0.1) and I'm trying to set sead-band to 1.0 or even greater values. But it did not work. How can I solve this? Because it's terrible to see how controls move from time to time a lot! Lots of joysticks have a dead zone so large that it makes them unusable. I got my private license on an aircraft that had a stick, not a yoke, and I know how a responsive stick should feel. You can't control your aircraft on final with crosswind and turbulence with a big dead zone -- little stick movements don't do anything, and bigger movements can jerk the plane right into the ground. When I bought my last joystick, I tested several demo joysticks in a computer store by taking a laptop into the store running a modified version of fgjs. I recompiled fgjs to display the axis positions with an extra digit of precision. I attached each demo joystick and tested each axis of movement. Regardless of price, most joysticks had a huge dead zone in all three axes. Only one model (Thrustmaster Top Gun Fox 2 Pro USB) showed an acceptably smooth and continuous movement through the center. I'm very happy with it. There's an alternative to adjusting the dead band. You might try setting a very non-linear filter on the position in the joystick's .xml file. For example, you can try a combination of parameters such as: power type=double2.5/power offset type=double+0.0/offset factor type=double+1.0/factor tolerance type=double0.0/tolerance This will let you slap the stick around the center dead zone to make small corrections, while still allowing the controls to reach full travel. That much non-linearity is not realistic, however. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
* Vivian Meazza -- Saturday 17 June 2006 21:18: I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. The only recent change to the 2D panel was IIRC my patch to allow other fonts than just Helvetica.txf and led.txf. I'll try to reproduce and check if that's the cause, and fix it if so. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
* Melchior FRANZ -- Saturday 17 June 2006 21:23: The only recent change to the 2D panel was IIRC my patch to allow other fonts than just Helvetica.txf and led.txf. I'll try to reproduce and check if that's the cause, and fix it if so. Can't reproduce. You might want to try with that last change reverted: $ cd src/Cockpit cvs up -r1.40 panel.cxx later, to restore: $ cvs up -AC panel.cxx m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Saturday 17 June 2006 20:18, Vivian Meazza wrote: Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian Sounds very much like it - I first noticed under the same conditions. I'll try cvs with Melchior's latest update, but a bit later - I'm of to a birthday now. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Simgear compile error: min function
I just did an update from cvs and got this when trying to build: In file included from ../../simgear/math/SGMath.hxx:32, from ../../simgear/math/point3d.hxx:54, from ../../simgear/math/sg_types.hxx:41, from sg_socket.hxx:39, from socktest.cxx:6: ../../simgear/math/SGQuat.hxx:134:35: macro min requires 2 arguments, but only 1 given ../../simgear/math/SGQuat.hxx:165:47: macro min requires 2 arguments, but only 1 given ../../simgear/math/SGQuat.hxx:166:47: macro min requires 2 arguments, but only 1 given ../../simgear/math/SGQuat.hxx:181:47: macro min requires 2 arguments, but only 1 given ../../simgear/math/SGQuat.hxx:182:47: macro min requires 2 arguments, but only 1 given ../../simgear/math/SGQuat.hxx:205:32: macro min requires 2 arguments, but only 1 given ../../simgear/math/SGQuat.hxx:212:41: macro min requires 2 arguments, but only 1 given ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
In file included from ../../simgear/math/SGMath.hxx:32,
from ../../simgear/math/point3d.hxx:54,
from ../../simgear/math/sg_types.hxx:41,
from sg_socket.hxx:39,
from socktest.cxx:6:
../../simgear/math/SGQuat.hxx:134:35: macro min requires 2
arguments, but only 1 given
Here is the offending code for the first error:
/// Create a quaternion from the angle axis representation where the angle
/// is stored in the axis' length
static Squat fromAngleAxis(const SGVec3T axis)
{
T nAxis = norm(axis);
if (nAxis = SGLimitsT::min())
return SGQuat(1, 0, 0, 0);
T angle2 = 0.5*nAxis;
return fromRealImag(cos(angle2), T(sin(angle2)/nAxis)*axis);
}
Is it legal to call a min function with no arguments? The compiler doesn't
seem to think so, at least.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:06, Jon S. Berndt wrote:
In file included from ../../simgear/math/SGMath.hxx:32,
from ../../simgear/math/point3d.hxx:54,
from ../../simgear/math/sg_types.hxx:41,
from sg_socket.hxx:39,
from socktest.cxx:6:
../../simgear/math/SGQuat.hxx:134:35: macro min requires 2
arguments, but only 1 given
Here is the offending code for the first error:
/// Create a quaternion from the angle axis representation where the
angle /// is stored in the axis' length
static Squat fromAngleAxis(const SGVec3T axis)
{
T nAxis = norm(axis);
if (nAxis = SGLimitsT::min())
return SGQuat(1, 0, 0, 0);
T angle2 = 0.5*nAxis;
return fromRealImag(cos(angle2), T(sin(angle2)/nAxis)*axis);
}
Is it legal to call a min function with no arguments? The compiler
doesn't seem to think so, at least.
Perfectly legal.
That is a static member of SGLimitsT that is basically the same than
std::numeric_limits. That in turn has a min static member.
On windows, you have that nasty windows.h header defining a min and max macro
that will interfere with the ISO C++ standard.
Dig into the windows headers, there is a way to avoid windows.h defining that
macro.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Perfectly legal. That is a static member of SGLimitsT that is basically the same than std::numeric_limits. That in turn has a min static member. On windows, you have that nasty windows.h header defining a min and max macro that will interfere with the ISO C++ standard. Dig into the windows headers, there is a way to avoid windows.h defining that macro. Greetings Mathias This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:15, Jon S. Berndt wrote: This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? About a year or so ... It is not the first time I hit this nasty defines. But I can never remember what needs to be done to get rid of them. With the lack of a win system here, you have to dig yourself ... greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Jon S. Berndt schrieb: Perfectly legal. That is a static member of SGLimitsT that is basically the same than std::numeric_limits. That in turn has a min static member. On windows, you have that nasty windows.h header defining a min and max macro that will interfere with the ISO C++ standard. Dig into the windows headers, there is a way to avoid windows.h defining that macro. Greetings Mathias This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? Jon I could not compile SimGear CVS under CYGWIN for a short time due to this error. Will now try to make the changes recommended. Thank you Jon for making it public. Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Mathias Fröhlich schrieb: On Saturday 17 June 2006 22:15, Jon S. Berndt wrote: This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? About a year or so ... Hmmm, I *could* compile SimGear CVS under Cygwin without any problems until now. The only thing I did in the last weeks was to try to get TerraGear running under Cygwin (without success) and downloaded some additional stuff for Cygwin. Really strange. Thank you for your hint, Mathias! Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? Jon I could not compile SimGear CVS under CYGWIN for a short time due to this error. Will now try to make the changes recommended. Thank you Jon for making it public. Georg EDDW George: If you find the fix, please make *that* public! :-) I've got a headache after looking through this for a while, and I've already spent more time on this than I have. I'm DITW (dead in the water) until this is resolved. Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:24, Georg Vollnhals wrote: I could not compile SimGear CVS under CYGWIN for a short time due to this error. Will now try to make the changes recommended. Thank you Jon for making it public. There is a #define that saves windows.h from defining the min and max macro. Either grep for them in cgwin's includes or use google ... May be we can include that in a generic simgear header? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Mathias Fröhlich schrieb: On Saturday 17 June 2006 22:24, Georg Vollnhals wrote: I could not compile SimGear CVS under CYGWIN for a short time due to this error. Will now try to make the changes recommended. Thank you Jon for making it public. There is a #define that saves windows.h from defining the min and max macro. Either grep for them in cgwin's includes or use google ... May be we can include that in a generic simgear header? Greetings Mathias I am just trying to find that needle but I am blind! But not giving up for the next hour. Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:44, Georg Vollnhals wrote: I am just trying to find that needle but I am blind! But not giving up for the next hour. Ok, google tells me that #define NOMINMAX or equivalently CPPFLAGS=-DNOMINMAX ./configure --whatever-you-like does the trick. Tell me if this is ok ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Jon S. Berndt writes: This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? Jon I could not compile SimGear CVS under CYGWIN for a short time due to this error. Will now try to make the changes recommended. Thank you Jon for making it public. Georg EDDW George: If you find the fix, please make *that* public! :-) I've got a headache after looking through this for a while, and I've already spent more time on this than I have. I'm DITW (dead in the water) until this is resolved. You need to include either config.h or simgear_config.h (can't remember which one offhand for SimGear) as the first include in the offending source (cxx or cpp) file. This picks up the NOMINMAX definition. Alternatively define NOMINMAX globally as Mattias say's later on. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Mathias Fröhlich writes On Saturday 17 June 2006 22:44, Georg Vollnhals wrote: I am just trying to find that needle but I am blind! But not giving up for the next hour. Ok, google tells me that #define NOMINMAX or equivalently CPPFLAGS=-DNOMINMAX ./configure --whatever-you-like does the trick. Tell me if this is ok ... It is easy to fix this once and for all ... http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/SimGear/simgear/compiler.h.diff?r1=1.1r2=1.2cvsroot=SimGear-0.3 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Mathias Fröhlich schrieb: On Saturday 17 June 2006 22:44, Georg Vollnhals wrote: I am just trying to find that needle but I am blind! But not giving up for the next hour. Ok, google tells me that #define NOMINMAX or equivalently CPPFLAGS=-DNOMINMAX ./configure --whatever-you-like does the trick. Tell me if this is ok ... Greetings Mathias Hi Mathias and Jon, CPPFLAGS=-DNOMINMAX ./configure --xx removed this error. I already found out before your message that the \cygwin\usr\include\w32api\windef.h is the bad guy with the definition of #ifndef NOMINMAX #ifndef max #define max(a,b) ((a)(b)?(a):(b)) #endif #ifndef min #define min(a,b) ((a)(b)?(a):(b)) #endif #endif Could we just place the following into the constants.h of SimGear? #ifndef NOMINMAX #define NOMINMAX I did not try it but will do this night. Now I am off for an urgent walk with the dog before ... BUT THERE IS ANOTHER NEW ERROR so that SimGear does not compile: RenderTexture.cpp:1555: Fehler: WGL_SAMPLE_BUFFERS_ARB nicht deklariert (ers te Verwendung dieser Funktion) RenderTexture.cpp:1555: Fehler: (Jeder nicht deklarierte Bezeichner wird nur ein mal fur jede Funktion, in der er vorkommt, gemeldet.) RenderTexture.cpp:1557: Fehler: WGL_SAMPLES_ARB nicht deklariert (erste Verw endung dieser Funktion) make[3]: *** [RenderTexture.o] Fehler 1 make[3]: Leaving directory `/home/Besitzer/SimGear-0.3-cvs/source/simgear/screen ' Sorry, error messages in German. Will come back later! Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: Seriously, I *can* think of fast_atan's polynomials being faster than a full blown correct functioin. But those simple fabs, sign or neg function implemented in the header cannot even be faster than the cpu builtin assembler instructions usually available on current cpu's. Also, in presence of sse instructions forcing that fist legacy i386 fpu instruction in that assembler snipet will not make it faster (unloading from sse unit, loading to legacy fpu, in contrast to do the same directly in the sse unit ...). You know, I did a quick grep in the source code for fast_ and only found it to be used in simgear/sound/xmlsound.cxx (namely fast_log10 and fast_log). Maybe we can get rid of them after all. 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] A few notes from Blender's AC3D exporter plugin programmer: Sir William P. Germano
Hi people, I contacted William and asked him to add a simple option to his exporter pulgin. He was soon back with an answer and a new customized ac3d plugin which accomodates my request. He was very kind and, after having read a few archived fgfs-dev threads about the subject, he asked me to post the following notes. I think that's worth a quick reading, since it makes clear a few points. Roberto Hi, I'm Willian, I wrote the ac3d import / export scripts that come with Blender. Checking archived posts here related to them, after Roberto contacted me, I noticed it might be useful to mention a few things possibly not known to all users. - Configuration: There's a script called Scripts Config Editor that you can use to tweak options for the ac3d importer and exporter. It's in the Scripts window Scripts menu System submenu. As soon as you execute the ac scripts once (no need to finish, you can press ESC right after calling them) there will be config data available to be edited. There's another script called Scripts Help Browser in Blender's Help menu. From it you can get info about the configurable parameters and other notes (it's all written in the scripts themselves, this is just a nicer way to read the info). - Exporting single / double sided face info: The Double Sided button in Blender works per mesh, so if you set or unset it all faces in that mesh will be either double or single sided. I decided not to export that info because there is also a simple way to set this *per face*: enter UV Face Select mode (select mesh, press f in the 3d view win) and in the Texture Face panel of the mesh editing buttons tab (F9 in the buttons win) use the Twosided toggle button. To copy the face flags to other faces, so you don't have to do it manually: select them, then select the face with the data (make it active) and press Copy Draw Mode in that same panel. I believe that is the best way (its only drawback is that it's sort of hidden inside the uv face select mode), but since Roberto emailed me stating he still would like to use the Double Sided button, I updated the ac3d exporter with an option to define whether to check per mesh or per faces (defaults to per face, the current behavior). I'll test the script properly and commit it to Blender's cvs (btw, the next release should be out soon, maybe in a week), but already sent a copy to Roberto. Lastly, in the long run I suppose / hope projects like yours will support COLLADA (which we want well represented in Blender, too), but I'm really glad to see those two small scripts I started years ago were and are still useful to some people involved with such a cool project, thanks :) . PS: I'm not subscribed to this list (thanks Roberto for forwarding this), you can reach me at wgermano at ig.com.br -- Willian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Jon S. Berndt wrote : I just did an update from cvs and got this when trying to build: In file included from ../../simgear/math/SGMath.hxx:32, from ../../simgear/math/point3d.hxx:54, from ../../simgear/math/sg_types.hxx:41, from sg_socket.hxx:39, from socktest.cxx:6: ../../simgear/math/SGQuat.hxx:134:35: macro min requires 2 arguments, but only 1 given A fix is in CVS now -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] Simgear compile error: min function
Thank you to all who helped to solve the SimGear min function compile error. Jon, I got a second error while further compiling. If you also have the RenderTexture.cpp:1555: Fehler: WGL_SAMPLE_BUFFERS_ARB error then my very ugly workaround might help you. (I am no C-guy and all further is far behind my scope): FILE TO CHANGE: C:\cygwin\home\Besitzer\SimGear-0.3-cvs\source\simgear\screen\exte nsions.hxx I didn't get thsi error. However, I did get pages of FlightGear errors similar to the SimGear one - not really unexpected, I guess. example: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/locale_facets.tcc:514:57: macro min requires 2 arguments, but only 1 given /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/locale_facets.tcc:563:57: macro max requires 2 arguments, but only 1 given /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/istream.tcc:146:36: macro min requires 2 arguments, but only 1 given /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/istream.tcc:147:46: macro max requires 2 arguments, but only 1 given etc. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
However, I did get pages of FlightGear errors similar to the SimGear one - not really unexpected, I guess. I applied the same process for FlightGear as with SimGear and got a good build: CPPFLAGS=-DNOMINMAX ./configure ... etc. Unfortunately, it immediately segfaults. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Jon S. Berndt schrieb: ... I didn't get thsi error. However, I did get pages of FlightGear errors similar to the SimGear one - not really unexpected, I guess. example: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/locale_facets.tcc:514:57: macro min requires 2 arguments, but only 1 given /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/locale_facets.tcc:563:57: macro max requires 2 arguments, but only 1 given /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/istream.tcc:146:36: macro min requires 2 arguments, but only 1 given /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/istream.tcc:147:46: macro max requires 2 arguments, but only 1 given etc. Jon OK, now we have two diffent problems with FlightGear CVS under Cygwin. You have this min-max problem, I'll get a glide-info one: gcc -g -O2 -D_REENTRANT -L/fg-cvs/lib -L/usr/local/lib -o gl-info.exe gl-info .o -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 gl-info.o: In function `getPrints': /home/Besitzer/FlightGear-0.9-cvs/source/tests/gl-info.c:29: undefined reference to `_glGetString' gl-info.o: In function `getPrint2f': /home/Besitzer/FlightGear-0.9-cvs/source/tests/gl-info.c:35: undefined reference to `_glGetFloatv' gl-info.o: In function `getPrintf': /home/Besitzer/FlightGear-0.9-cvs/source/tests/gl-info.c:42: undefined reference to `_glGetFloatv' gl-info.o: In function `getPrint2i': /home/Besitzer/FlightGear-0.9-cvs/source/tests/gl-info.c:49: undefined reference to `_glGetIntegerv' gl-info.o: In function `getPrinti': /home/Besitzer/FlightGear-0.9-cvs/source/tests/gl-info.c:56: undefined reference to `_glGetIntegerv' collect2: ld gab 1 als Ende-Status zuruck make[1]: *** [gl-info.exe] Fehler 1 make[1]: Leaving directory `/home/Besitzer/FlightGear-0.9-cvs/source/tests' make: *** [all-recursive] Fehler 1 What a pity, CVS compiling worked without problems for a very long time! Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Unfortunately, it immediately segfaults. Jon I ran FlightGear from within gdb: (gdb) run Starting program: /usr/local/bin/fgfs.exe Program received signal SIGSEGV, Segmentation fault. 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll Does this suggest an error to anyonw? Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
Unfortunately, it immediately segfaults. Jon I ran FlightGear from within gdb: (gdb) run Starting program: /usr/local/bin/fgfs.exe Program received signal SIGSEGV, Segmentation fault. 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll Does this suggest an error to anyonw? Jon Is there a way to turn off pthreads? What do pthreads buy me under Cygwin? Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A few notes from Blender's AC3D exporter plugin programmer: Sir William P. Germano
On Saturday 17 June 2006 22:35, Roberto Inzerillo wrote: Hi people, I contacted William and asked him to add a simple option to his exporter pulgin. He was soon back with an answer and a new customized ac3d plugin which accomodates my request. He was very kind and, after having read a few archived fgfs-dev threads about the subject, he asked me to post the following notes. I think that's worth a quick reading, since it makes clear a few points. Roberto Hi, I'm Willian, I wrote the ac3d import / export scripts that come with Blender. Checking archived posts here related to them, after Roberto contacted me, I noticed it might be useful to mention a few things possibly not known to all users. - Configuration: There's a script called Scripts Config Editor that you can use to tweak options for the ac3d importer and exporter. It's in the Scripts window Scripts menu System submenu. As soon as you execute the ac scripts once (no need to finish, you can press ESC right after calling them) there will be config data available to be edited. There's another script called Scripts Help Browser in Blender's Help menu. From it you can get info about the configurable parameters and other notes (it's all written in the scripts themselves, this is just a nicer way to read the info). - Exporting single / double sided face info: The Double Sided button in Blender works per mesh, so if you set or unset it all faces in that mesh will be either double or single sided. I decided not to export that info because there is also a simple way to set this *per face*: enter UV Face Select mode (select mesh, press f in the 3d view win) and in the Texture Face panel of the mesh editing buttons tab (F9 in the buttons win) use the Twosided toggle button. To copy the face flags to other faces, so you don't have to do it manually: select them, then select the face with the data (make it active) and press Copy Draw Mode in that same panel. I believe that is the best way (its only drawback is that it's sort of hidden inside the uv face select mode), but since Roberto emailed me stating he still would like to use the Double Sided button, I updated the ac3d exporter with an option to define whether to check per mesh or per faces (defaults to per face, the current behavior). I'll test the script properly and commit it to Blender's cvs (btw, the next release should be out soon, maybe in a week), but already sent a copy to Roberto. Lastly, in the long run I suppose / hope projects like yours will support COLLADA (which we want well represented in Blender, too), but I'm really glad to see those two small scripts I started years ago were and are still useful to some people involved with such a cool project, thanks :) . PS: I'm not subscribed to this list (thanks Roberto for forwarding this), you can reach me at wgermano at ig.com.br That's helpful info - thanks for posting it and to William. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A few notes from Blender's AC3D exporter plugin programmer: Sir William P. Germano
Lee Elliott wrote: On Saturday 17 June 2006 22:35, Roberto Inzerillo wrote: Hi people, I contacted William and asked him to add a simple option to his exporter pulgin. He was soon back with an answer and a new customized ac3d plugin which accomodates my request. He was very kind and, after having read a few archived fgfs-dev threads about the subject, he asked me to post the following notes. I think that's worth a quick reading, since it makes clear a few points. Roberto Hi, I'm Willian, I wrote the ac3d import / export scripts that come with Blender. Checking archived posts here related to them, after Roberto contacted me, I noticed it might be useful to mention a few things possibly not known to all users. - Configuration: There's a script called Scripts Config Editor that you can use to tweak options for the ac3d importer and exporter. It's in the Scripts window Scripts menu System submenu. As soon as you execute the ac scripts once (no need to finish, you can press ESC right after calling them) there will be config data available to be edited. There's another script called Scripts Help Browser in Blender's Help menu. From it you can get info about the configurable parameters and other notes (it's all written in the scripts themselves, this is just a nicer way to read the info). - Exporting single / double sided face info: The Double Sided button in Blender works per mesh, so if you set or unset it all faces in that mesh will be either double or single sided. I decided not to export that info because there is also a simple way to set this *per face*: enter UV Face Select mode (select mesh, press f in the 3d view win) and in the Texture Face panel of the mesh editing buttons tab (F9 in the buttons win) use the Twosided toggle button. To copy the face flags to other faces, so you don't have to do it manually: select them, then select the face with the data (make it active) and press Copy Draw Mode in that same panel. I believe that is the best way (its only drawback is that it's sort of hidden inside the uv face select mode), but since Roberto emailed me stating he still would like to use the Double Sided button, I updated the ac3d exporter with an option to define whether to check per mesh or per faces (defaults to per face, the current behavior). I'll test the script properly and commit it to Blender's cvs (btw, the next release should be out soon, maybe in a week), but already sent a copy to Roberto. Lastly, in the long run I suppose / hope projects like yours will support COLLADA (which we want well represented in Blender, too), but I'm really glad to see those two small scripts I started years ago were and are still useful to some people involved with such a cool project, thanks :) . PS: I'm not subscribed to this list (thanks Roberto for forwarding this), you can reach me at wgermano at ig.com.br That's helpful info - thanks for posting it and to William. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Yes, well done. Much more productive than My correspondence was. I'm interested in COLLADA, maybe we need a new loader for Plib? Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Altimiter error
I'm looking at the B-47 flight manual(s), and they have a correction chart for altimeter error vs. altitude AGL with flaps down. Is this sort of thing a common problem, or is it just some oddity with the Stratojet, possibly due to static port location? It reads -40 ft at 0 AGL, correct at 20, and then stabilizes at about +12 around 60 AGL. I I'm wondering if I will have to concoct a special altimeter for this ac. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
