Re: [Flightgear-devel] Linux Expo Blurb
On Thu, 11 Mar 2004, Al West wrote: Jon, where are you based. I live just off the M5 up from Bridgwater which isn't that far from Yeovilton. If you are nearby I could spend some time to assist you - although I'm warning you now that I'm not very familiar with FlightGear code at the moment. I'm in Wakefield, Yorkshire. It's not a coding problem (a good job, because I don't code in c++). What I'm trying to come up with is a sort of sim controls meccano kit that can be fitted to virtually anything. I will definitely be going to the Expo - I think as it's not long to go now that we should sort out what we will be doing there, how will be doing it and what equipment we need. Do we have enough room in the booth to exhibit a Wasp or am I missing something here? The Wasp is basically gonna be the centrepiece of the show... and we get to run it. I'm not sure if we'll actually need any real booth space, since a helicopter is likely to attract lots more people than a few of us standing around in a booth, but I'm in fairly regular contact with the organisers, so if we do need space it shouldn't be a problem to organise. It's looking like the helicopter will be sponsored by IBM, who will be taking care of all the transport costs. I also need to get a shopping list to the organisers for the equipment we'll need - currently this is 2 PCs, 2 plasma screens, and all their associated bits. If anyone can think of anything else we need, or has any ammendments to the blurb, then please let me know - I'm sending the blurb off this morning. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Chambley Airbase sort of ICAO code
Hello Robin, would you please update the ICAO code for Chambley Airbase in France ? Currently it is set to 'LFZZ' in your current data set 'AptNav200402XP715'. This is the usual code for airfields in France that don't have an official ICAO code. Chambley in fact does _not_ have an _official_ ICAO code but there is an inofficial code mentioned here: http://www.fortunecity.com/marina/harbourside/2145/id28.htm and at least this one is definitely unique, so I am convinced that it is predestinated to identify this airfield. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New keybinding
I've bound Ctrl-R to the radios dialog. I imagine that this will be a very frequently-used command, especially for aircraft that do not have fully-interactive radios yet. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New keybinding
David Megginson I've bound Ctrl-R to the radios dialog. I imagine that this will be a very frequently-used command, especially for aircraft that do not have fully-interactive radios yet. All the best, Is that hard coded? I was literally in the process of binding R/r for seat raise/lower. Rather sounds like I'd better use L/l. Regards Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up for 3D modelers - plib cvs issue
David Megginson said: Actually, what we need is a proper graphics format that specifies per-vertex normals. What we have now is a kludge that we need to hold onto until plib supports another 3D format as fully as it supports AC3D. Given that problem, I don't know how much formal machinery we need to add -- let's just change the angle to 61 deg and leave it there. Could someone submit a patch for this? I would but I don't have a complete cvs for plib on disk. It's just a one line mod near the top of ssgVertexSplitter.cxx to change the default from 46 to 61. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
David Megginson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161/Models In directory baron:/tmp/cvs-serv6690/Aircraft/pa28-161/Models Modified Files: pa28-161.ac panel.rgb Added Files: bench-back.rgb glareshield.rgb Log Message: Added textures for the back bench (not right yet) and the glareshield. This aircraft gets really nice. Did you know that you employ the default outside texture (the one with orange stripes) at really funny places ? For an example look at the inner side of the co-pilot's door, look at the front of the cowling :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New keybinding
Vivian Meazza wrote: I've bound Ctrl-R to the radios dialog. I imagine that this will be a very frequently-used command, especially for aircraft that do not have fully-interactive radios yet. Is that hard coded? I was literally in the process of binding R/r for seat raise/lower. Rather sounds like I'd better use L/l. That's *control* R. I'm not sure if r/R are in use. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
Martin Spott wrote: This aircraft gets really nice. Thanks. The big breakthrough was my finally learning to use Blender to make the textures (such as the panel plastics and screws) as well as the geometry -- using a good 3D modeller with a bit of lighting can make even a ham-fisted dolt like me look like an artist. Thanks to Andy, too, for his work on YASim. There are still some borderline problems (such as propwash in a power climb), but on balance YASim allows this model to fly remarkably like a real Piper Warrior II. Did you know that you employ the default outside texture (the one with orange stripes) at really funny places ? For an example look at the inner side of the co-pilot's door, look at the front of the cowling :-) Yes: I haven't set the UV explicitly for all the faces yet, so there are some weird default texture patterns in places -- I'm working through the plane a little bit at a time so that the task isn't too daunting, but I've already switched to it as my default aircraft (rather than the 172p). Some day, the whole interior will look passably nice, but for now, I'm concentrating on the parts you see looking straight-forward while flying. My next big hurdle is figuring out how to model radios in 3D. I'll make a separate posting on that. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New keybinding
* David Megginson -- Thursday 11 March 2004 17:05: I'm not sure if r/R are in use. Yes. r is replay, R is toggle thrust reverser on the Fokker100. see $FG_ROOT/Docs/keyboard/map.pdf, or http://members.aon.at/mfranz/map.pdf m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFD: 3D Text Issues
I'm struggling a bit with the best way to implement text for the new (3D-capable) animation code in FlightGear. Plib's current approach seems suboptimal -- it uses textured fonts (good), but instead of adding the text directly to a scene graph, it requires a separate drawing pass for it (bad). I wonder if the plib text is one of the reasons that the old (2D-only) animation code could hurt the framerate so badly. So, what do we do? Do we require each instrument to supply a texture with all the text it might use and then simply animate texture coordinates? That works well for, say, OIL on an annunciator, but it isn't practical for frequencies, much less waypoint identifiers. Or, on the other hand, do we recreate the entire functionality of the PLIB FNT library and integrate it properly into the scene graph, generating a separate quad for each character? Are there any better solutions for general display-text support? For mechanical displays with numbers on rotating drums, etc. (like the King KX 170B NAVCOM), we should simply animate the mechanism -- we need text animations for LED and other more sophisticated display types. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New keybinding
David Megginson wrote Sent: 11 March 2004 16:05 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New keybinding Vivian Meazza wrote: I've bound Ctrl-R to the radios dialog. I imagine that this will be a very frequently-used command, especially for aircraft that do not have fully-interactive radios yet. Is that hard coded? I was literally in the process of binding R/r for seat raise/lower. Rather sounds like I'd better use L/l. That's *control* R. I'm not sure if r/R are in use. Yes, understand that - I didn't want to mix contexts up - CTRL R R/r = raise seat and radios. Not too easy to remember, and you might want to use R/r for other radio stuff. No problem, I'll use L/l Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiling under MS visual studio .NET 2003 -
Fred wrote Marco, Olivier just confirmed me that with the patches just included in CVS by Erik, SimGear compiles fine with MSVC .Net 2003. It seems that SimGear 0.3.4 has a problem in clouds3d that was corrected since then. So, my only advice is that it is time to switch to the CVS version. -Fred Hi Fred, thank you very much for your help and support. I'll try to use the CVS version. I'm sorry for my not quick answer, but I was temporarily without Internet connection. Marco ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
David Megginson wrote: Yes: I haven't set the UV explicitly for all the faces yet, so there are some weird default texture patterns in places -- I'm working through the plane a little bit at a time so that the task isn't too daunting, but I've already switched to it as my default aircraft (rather than the 172p). As the next step you probably might want to sell your Warrior in favour of an Archer :-)) My next big hurdle is figuring out how to model radios in 3D. I'll make a separate posting on that. BTW - radios I figured out how much money I'd need to spend for an IFR 'upgrade' after I have the PPL. This is _incredibly_ expensive in Germany. You'll have to do almost 60 hours !! of training with instructor (some on a simulator), an IFR equipped aircraft is more epensive and even the instuctor gets more money for an IFR flight. This means the IFR 'add-on' costs almost 150 % or the simple PPL. Is this similar to what you experienced in Canada ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
David Megginson wrote: I'm struggling a bit with the best way to implement text for the new (3D-capable) animation code in FlightGear. Plib's current approach seems suboptimal -- it uses textured fonts (good), but instead of adding the text directly to a scene graph, it requires a separate drawing pass for it (bad). I wonder if the plib text is one of the reasons that the old (2D-only) animation code could hurt the framerate so badly. What interface would you like? The Plib fnt library is an immediate mode kind of thing. If you want it to live in the scene graph, you need only write a node object that sets up the matrices appropriately. A fancy implementation of static text might precompile it into a set of textured quads instead of doing it at render time from the input string; but for static text you might as well use a static texture anyway. I'd suggest an interface where you specify a location for the lower left corner of the text, a plane in which it exists, and a point size in real world units. This stuff can compile down to a single matrix push, and the node object just calls the immediate mode fnt stuff inside of draw(). Honestly, I think you might be fooling yourself on the 2D/3D performance issues. There's no secret sauce in ssg that makes it faster; my guess is that the existing 3D cockpits are faster than the 2D ones because they use fewer and smaller textures, and do less animation of the layers. If you were to port the 2D panels to 3D model files with a 1:1 mapping, you probably wouldn't see any difference. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
Martin Spott writes: David Megginson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161/Models In directory baron:/tmp/cvs-serv6690/Aircraft/pa28-161/Models Modified Files: pa28-161.ac panel.rgb Added Files: bench-back.rgb glareshield.rgb Log Message: Added textures for the back bench (not right yet) and the glareshield. This aircraft gets really nice. I'll second that - it really is good. It looks really good, and at high resolutions the frame rate is much better than the default - I've seen 60 (pa28) vs. 30 (c172) at some locations and resolutions. One bug though - I don't see the instrument needles under Linux with an NVidia card. I thought you simply hadn't done them, until I saw them under Cygwin with an ATI card. I see the large tilting plane in the turn co-ordinator, and the AI, but none of the more 'needlish' needles. I've got no idea what the problem is. It also seems a lot easier to bleed off speed and/or height on approach by throttling back cf. the default Cessna. I would imagine they're both similar in that respect in real life, as a pilot of both can you (David M) give us some idea of which you think is more representative of real world behaviour? Once again, very nice model :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compile error with latest simgear cvs.
Hi,
Just update my simgear cvs today and I now get the following error:
In file included from sgstream.hxx:47,
from sgstream.cxx:32:
../../simgear/misc/zfstream.hxx:144: `traits_type' is not a member of
type `streambuf'
../../simgear/misc/zfstream.hxx:144: parse error before `::'
../../simgear/misc/zfstream.hxx:144: invalid type `{type error}' for
default argument to `int'
make[2]: *** [sgstream.o] Error 1
make[2]: Leaving directory `/scratch/simgear/SimGear/simgear/misc'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/scratch/simgear/SimGear/simgear'
make: *** [install-recursive] Error 1
Just thought I would get the word out. Sorry if this has been mentioned
already. Is there a solution to this problem?
Seamus
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Andy Ross writes: David Megginson wrote: snip Honestly, I think you might be fooling yourself on the 2D/3D performance issues. There's no secret sauce in ssg that makes it faster; my guess is that the existing 3D cockpits are faster than the 2D ones because they use fewer and smaller textures, and do less animation of the layers. If you were to port the 2D panels to 3D model files with a 1:1 mapping, you probably wouldn't see any difference. My observation has been that the performance difference is very small verging on neglible in situations where the framerate appears to be polygon limited, but that as the framerate becomes fillrate limited a significant difference emerges, and that the difference then increases with increased pixel count. I've seen significant differences at low-poly locations (KLVK, in the base package) with a high pixel resolution (1280 x 1024) - 30fps C172 vs. 60fps pa28-161. This with a card that should comfortably fit all the textures (64M). My gut feeling is that the 2D panels are probably overdrawing over scenery pixels that are also getting rendered, and that the 3D panels aren't, but that's a wild guess that'll probably leave me looking foolish when it's debunked by those who know what's going on... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
David Luff wrote: I'll second that - it really is good. It looks really good, and at high resolutions the frame rate is much better than the default - I've seen 60 (pa28) vs. 30 (c172) at some locations and resolutions. The old (2D) panel code seemed to be the real killer, since I'm using much more geometry and much bigger textures in the PA-28-161. One bug though - I don't see the instrument needles under Linux with an NVidia card. I thought you simply hadn't done them, until I saw them under Cygwin with an ATI card. I see the large tilting plane in the turn co-ordinator, and the AI, but none of the more 'needlish' needles. I've got no idea what the problem is. I used geometry for the needles, and they must just be too narrow to show up. It's strange, because I also use Linux+NVIDIA (GeForce2Go), and the needles do show up on my system at 1600x1200. In any case, I'll be switching to bigger quads with textures for the needles soon, and they should pop up then. It also seems a lot easier to bleed off speed and/or height on approach by throttling back cf. the default Cessna. I would imagine they're both similar in that respect in real life, as a pilot of both can you (David M) give us some idea of which you think is more representative of real world behaviour? They are different in this respect, though in most others, the 172 and Cherokee are comparable. The real Skyhawk glides forever in the flare, while the Warrior has the aerodynamic characteristics of a brick when you chop power (especially with full flaps). That has its advantages -- for example, ATC can squeeze me in for an approach ahead of an Airbus or 737, and I can keep up 120 kias almost right to the runway and still touch down with the stall horn blaring. In a 172, I'd be touching down in the next county if I tried that trick (or at least, I'd have to use some pretty viscious slips). When I first started flying the Warrior, I had a tendency to drop it in from a 6 in to a foot up, since the flare decayed so fast compared to a 172. First, I learned to recover by adding a bit of power to ease the touchdown, then I learned the different technique for a smooth landing without power (DON'T give up your airspeed too soon). Apparently, some Cessnas are like this as well -- the most common damage history for a Cessna 182 is a bent firewall from a hard, nose-first touchdown. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Andy Ross said: David Megginson wrote: I'm struggling a bit with the best way to implement text for the new (3D-capable) animation code in FlightGear. Plib's current approach seems suboptimal -- it uses textured fonts (good), but instead of adding the text directly to a scene graph, it requires a separate drawing pass for it (bad). I wonder if the plib text is one of the reasons that the old (2D-only) animation code could hurt the framerate so badly. What interface would you like? The Plib fnt library is an immediate mode kind of thing. If you want it to live in the scene graph, you need only write a node object that sets up the matrices appropriately. A fancy implementation of static text might precompile it into a set of textured quads instead of doing it at render time from the input string; but for static text you might as well use a static texture anyway. With the EFIS displays a lot of the text is what you might call semi static. It doesn't change often, but it changes (autopilot settings and nav id's for example). I think the idea of generating the quads makes the most sense. It would be nice to have a scheme to share the font texture objects in order to minimize memory usage across multiple models. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott wrote: As the next step you probably might want to sell your Warrior in favour of an Archer :-)) In retrospect, I wish I'd bought an Archer, since the cost of ownership is virtually identical, but there's a bit more power and useful load when you need it. On balance, though C-FBJO has been a good plane. If or when I move up, it will either be something like a Mooney (for speed) or a Cherokee Six (for load), depending on whether it happens after or before my kids leave home. If I ever become wealthy (ha!), it will be a six-seat, turbocharged, pressurized twin with known-ice certification. BTW - radios I figured out how much money I'd need to spend for an IFR 'upgrade' after I have the PPL. This is _incredibly_ expensive in Germany. You'll have to do almost 60 hours !! of training with instructor (some on a simulator), an IFR equipped aircraft is more epensive and even the instuctor gets more money for an IFR flight. This means the IFR 'add-on' costs almost 150 % or the simple PPL. Is this similar to what you experienced in Canada ? Most of our training aircraft are already at least minimally IFR equipped (mode C transponder, gyros, nav radio, VOR) -- typically, though, students move up to a four-seater for IFR training since it's a little more stable. You can even train in a non-IFR-certifiable aircraft like the Katana if you want, though, as long the IFR is only simulated using a hood or goggles. In Canada, you need at least 40 hours IFR time for the rating. You will already have done five of that for your PPL and, normally, another five for the night rating, so figure on 20 hours dual in a 172 at about CAD 160/hour, 10 hours dual in the sim at about CAD 80/hour, and a few hundred more in exam fees, ground school tuition, texts, and ground briefings, for a total just under CAD 5K (less than USD 4K). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Andy Ross wrote: Honestly, I think you might be fooling yourself on the 2D/3D performance issues. There's no secret sauce in ssg that makes it faster; my guess is that the existing 3D cockpits are faster than the 2D ones because they use fewer and smaller textures, and do less animation of the layers. If you were to port the 2D panels to 3D model files with a 1:1 mapping, you probably wouldn't see any difference. Most of the instruments in the PA-28 were ported 1:1, in fact, and initially I used the much higher resolution textures for the high-res 2D panel rather than the lower-res textures actually used by the 172p (and I'm still using bigger textures for things like the panel background). I was astounded at the framerate difference. My guess is that one or both of the following is the problem: 1. The old panel code triggers some expensive OpenGL rendering calls or state changes. 2. The PLIB FNT library is highly inefficent, since the text instruments are the only ones not yet ported. I can stuff the cockpit with higher-res textures and more detailed geometry and still get double the framerate on my computer that the old panel code gave me. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Jim Wilson wrote:
With the EFIS displays a lot of the text is what you might call
semi static. It doesn't change often, but it changes (autopilot
settings and nav id's for example). I think the idea of generating
the quads makes the most sense.
So how about an interface that looks vaguely like (apologies in
advance for getting Plib details wrong -- this is off the top of my
head):
class ssgTextNode : public ssgNode {
void setBaseline(sgVec3 start, sgVec3 end);
void setUp(sgVec3 up, bool correctToPerpendicular = true);
void setPointSize(float lineHeightInMeters);
void setText(char* text);
void setFont(FntFont* font);
void setFntRenderSettings(int AndyForgetsTheDetailsHere, ...);
void draw();
};
You would set the text baseline with a start point, and an end point
which lies along the line (not necessarily the end, I suppose). You
need to specify an up vector to get the plane and orientation
correct. This can be any point on the plane above the baseline. I
added the correctToPerpendicular option so that you can do affine
transformations on the text to simulate italics or whatnot.
The object would precompile its transformation matric and re-compile
only when the baseline/up points change. Likewise, the text string
would be precomputed as an array of quads (this might require some
surgery in the Fnt library to expose the right details) and changed
only when the text does.
Most of this would be pretty straightforward. The geometry code could
be lifted from the 2D-panel-in-3D hack I did (which does basically the
same thing), and the quad synthesis is already done inside the fnt
library; we just need to expose it in the right way.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: 3D Text Issues
David Megginson writes: Andy Ross wrote: Honestly, I think you might be fooling yourself on the 2D/3D performance issues. There's no secret sauce in ssg that makes it faster; my guess is that the existing 3D cockpits are faster than the 2D ones because they use fewer and smaller textures, and do less animation of the layers. If you were to port the 2D panels to 3D model files with a 1:1 mapping, you probably wouldn't see any difference. Most of the instruments in the PA-28 were ported 1:1, in fact, and initially I used the much higher resolution textures for the high-res 2D panel rather than the lower-res textures actually used by the 172p (and I'm still using bigger textures for things like the panel background). I was astounded at the framerate difference. My guess is that one or both of the following is the problem: 1. The old panel code triggers some expensive OpenGL rendering calls or state changes. 2. The PLIB FNT library is highly inefficent, since the text instruments are the only ones not yet ported. I can stuff the cockpit with higher-res textures and more detailed geometry and still get double the framerate on my computer that the old panel code gave me. My not so WAG is that the newer code draws MUCH less then the old approach. i.e. All of the 2D Panel was drawn as was all of the scenery that it obscured. In the new approach SSG is clipping those instruments not seen and the occluded scenery is not drawn. Note this includes the scenery occluded by the rest of the planes interior too FWIW That PLib's Font routines are quite efficient is amply demonstrated by the minimal hit drawing the HUD has on the FPS Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
David Megginson wrote: Most of our training aircraft are already at least minimally IFR equipped (mode C transponder, gyros, nav radio, VOR) -- typically, though, students move up to a four-seater for IFR training since it's a little more stable. We don't have two-seaters with gyros at our flight school ;-) - except the turn indicator - and we need at least dual NAV/COM as well as an ADF and DME for IFR flight in Germany. Everything below is not allowed for IFR. In Canada, you need at least 40 hours IFR time for the rating. You will already have done five of that for your PPL and, normally, another five for the night rating, [...] Whoops, that is _much_ easier than in Germany. We spend approx. over 9k Euro (15k CAD) for the PPL alone (including CVFR and night) and _additional_ 11k Euro (18k CAD) for the IFR training. If you like you can get it even more expensive Ha!, now I know why you managed to have an IFR rating in such short a timeframe after beginning :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Training costs
Martin Spott wrote: We don't have two-seaters with gyros at our flight school ;-) - except the turn indicator - and we need at least dual NAV/COM as well as an ADF and DME for IFR flight in Germany. Everything below is not allowed for IFR. Fuel costs don't help, obviously, but they're a relatively small percentage of the cost of operating a plane (i.e. doubling the fuel cost might increase the cost of flying by 25%). Is maintenance more expensive? Is it taxation and government fees? Obviously, the money's not going into the equipment they rent you. At the Ottawa Flying Club, the 150's that most people train in do not have DME, but most of the 172's would meet your criteria, and they're only a little more expensive to rent. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Norman Vine wrote: My not so WAG is that the newer code draws MUCH less then the old approach. i.e. All of the 2D Panel was drawn as was all of the scenery that it obscured. In the new approach SSG is clipping those instruments not seen and the occluded scenery is not drawn. Note this includes the scenery occluded by the rest of the planes interior too We're talking about using the old (2D) panel animation code inside a 3D cockpit, where the panel itself is a 3D object behind the instruments. The amount of scenery visible in the 3D scene graph is exactly identical (take a look at the default 172p, which uses the old 2D panel code). FWIW That PLib's Font routines are quite efficient is amply demonstrated by the minimal hit drawing the HUD has on the FPS That's worth keeping in mind, then. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: 3D Text Issues
David Megginson writes: Norman Vine wrote: My not so WAG is that the newer code draws MUCH less then the old approach. i.e. All of the 2D Panel was drawn as was all of the scenery that it obscured. In the new approach SSG is clipping those instruments not seen and the occluded scenery is not drawn. Note this includes the scenery occluded by the rest of the planes interior too We're talking about using the old (2D) panel animation code inside a 3D cockpit, where the panel itself is a 3D object behind the instruments. The amount of scenery visible in the 3D scene graph is exactly identical (take a look at the default 172p, which uses the old 2D panel code). Ah... OK but keep in mind you are still drawing all of the Panel even if it is not all in view, this includes all of the 'state changes' taking place in the 2D code that aren't necessarily happening in the 3D code and SSG might also be smart enough to optimize some of these 'state changes' to no-ops or at least minimal-ops. AFAIK the 2D code doesn't do any 'OpenGL state' optimization. Andy's approach for making a true SSG Text object is IMHO the probably the way to go about this. Another approach is to render the texture object each frame but this is probably to slow on older cards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
On Thu, 11 Mar 2004 17:10:30 +, David Luff [EMAIL PROTECTED] wrote: One bug though - I don't see the instrument needles under Linux with an NVidia card. I thought you simply hadn't done them, until I saw them under Cygwin with an ATI card. I see the large tilting plane in the turn co-ordinator, and the AI, but none of the more 'needlish' needles. I've got no idea what the problem is. I too, experienced this, no needles in the instruments. I use a NVidia card under Cygwin. After installing the cvs version of plib, the needles appeared (I used to have plib 1.6.0). Another thing that I noticed about the pa28 panel was the plane in the TC was not transparent where it should be. The rgb file did have an alpha channel but because the file was only 256 colors the alpha channel was not transparent in FlightGear. It was OK when I opened it in AC3D, but not in FlightGear. Converting the file to 24bit colour solved this, but I think that this is a bug, perhaps in plib. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile error with latest simgear cvs.
Seamus Thomas Carroll wrote:
Hi,
Just update my simgear cvs today and I now get the following error:
In file included from sgstream.hxx:47,
from sgstream.cxx:32:
../../simgear/misc/zfstream.hxx:144: `traits_type' is not a member of
type `streambuf'
../../simgear/misc/zfstream.hxx:144: parse error before `::'
../../simgear/misc/zfstream.hxx:144: invalid type `{type error}' for
default argument to `int'
make[2]: *** [sgstream.o] Error 1
make[2]: Leaving directory `/scratch/simgear/SimGear/simgear/misc'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/scratch/simgear/SimGear/simgear'
make: *** [install-recursive] Error 1
Just thought I would get the word out. Sorry if this has been mentioned
already. Is there a solution to this problem?
On which OS ? ( Cygwin or Linux ? )
What is your compiler version ?
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
On Thu, 11 Mar 2004, David Megginson wrote: I used geometry for the needles, and they must just be too narrow to show up. It's strange, because I also use Linux+NVIDIA (GeForce2Go), and the needles do show up on my system at 1600x1200. In any case, I'll be switching to bigger quads with textures for the needles soon, and they should pop up then. I didn't get them here either, but the compass housing also exhibited a few problem, and so I suspect the cause of all this is plib merging vertices - I can't remember the limit I've got set at the moment. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: 3D Text Issues
Norman Vine said: Ah... OK but keep in mind you are still drawing all of the Panel even if it is not all in view, this includes all of the 'state changes' taking place in the 2D code that aren't necessarily happening in the 3D code and SSG might also be smart enough to optimize some of these 'state changes' to no-ops or at least minimal-ops. AFAIK the 2D code doesn't do any 'OpenGL state' optimization. A. With the c172p in 3D mode on my lowly 32mb geforce2mx at KSFO: - View angle with panel in view 20 fps. - View angle slightly up so panel disappears below bottom of frustrum, but scenery still the same, 32 fps. B. With the c172p in 2D mode on the same lowly geforce2mx at KSFO: - 2D panel screen, 28 fps. - 2D panel screen off, 44 fps. C. With the pa28-161 3D Instruments: - 3D instrument panel at default view angle: 32 fps. - View angle slightly up: 38 fps. It looks like what everyone is saying holds true. The biggest savings here is with 3D instruments vs the 2D panels mapped to 3D cockpits (C vs A). No surprise. One interesting thing I picked up on that didn't occur to me before: it seems that the translucent prop disk object ends up costing 2-3 fps while in the cockpit view. I wonder if it is worth the cost. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] EasyXML
As far as I can tell, there is no SimGear-devel list, so I'm asking this here. I'm probably going to toy with EasyXML for a C++ side project I'm working on - and if that goes well, perhaps think about using it with JSBSim as well. I am guessing that I ought to be able to grab the EasyXML files from my flightgear installation and place them in my other application development directory, then compile and link them similarly to the way flightgear does it. To actually make any sensible use of it in my application, if I have read the docs correctly, I think I need to derive a class from XMLVisitor and override the handlers. I don't want to burden anyone with any handholding request, but any pointers on where the best documentation is (I am currently reviewing the docs at simgear.org), which files -- other than the EasyXML files themselves -- in the FlightGear tree should I peruse, and any other guidance on using EasyXML would be greatly appreciated and also increase my chance at success given my extremely limited time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Norman Vine wrote: Ah... OK but keep in mind you are still drawing all of the Panel even if it is not all in view, this includes all of the 'state changes' taking place in the 2D code that aren't necessarily happening in the 3D code and SSG might also be smart enough to optimize some of these 'state changes' to no-ops or at least minimal-ops. AFAIK the 2D code doesn't do any 'OpenGL state' optimization. Yes, that sounds more likely. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Jim Wilson wrote: One interesting thing I picked up on that didn't occur to me before: it seems that the translucent prop disk object ends up costing 2-3 fps while in the cockpit view. I wonder if it is worth the cost. I don't think that we need any prop disk at all for cruise RPMs -- the propeller really does become invisible. We should probably introduce a translucent prop disk only at lower RPMs, say, 1500 and below -- it's usually when I cut power for approach that I can (sort of) see the prop again. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
Roy Vegard Ovesen wrote: I too, experienced this, no needles in the instruments. I use a NVidia card under Cygwin. After installing the cvs version of plib, the needles appeared (I used to have plib 1.6.0). Ah, yes -- the last official PLIB version has a bug (I can hardly consider it a feature) where anything smaller than 1cm gets squished together. The same bug makes knobs and other small 3D objects come out funny. Another thing that I noticed about the pa28 panel was the plane in the TC was not transparent where it should be. The rgb file did have an alpha channel but because the file was only 256 colors the alpha channel was not transparent in FlightGear. It was OK when I opened it in AC3D, but not in FlightGear. Converting the file to 24bit colour solved this, but I think that this is a bug, perhaps in plib. Was this in PLIB 1.6, again? The alpha transparency is fine using the CVS plib. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] python - usable / presentable ?
I haven't heard much talk about the python class wrapper for FGFS's telnet remote access to the property tree. The scripting directory in CVS appears to have been untouched for the last couple of years. Is it still a stable bit of code whose capabilities we promote ? I'm asking because I've been invited to give a talk to the local Python users group (maybe as a joint meeting with one of the LUGs). However, I don't want to give a talk on something we don't use. It occurred to me that the FlightGear.py is a neat example of the power of Python in allowing easy encapsulation of something that wasn't originally designed with programmatic use in mind. Comments ? Does anyone have neat .py files other than the ones already in CVS ? Has someone already given a talk like this, that I could build on ? How many simultaneous users can connect to one FGFS using telnet ? Alex. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] EasyXML
Jon S Berndt wrote: I don't want to burden anyone with any handholding request, but any pointers on where the best documentation is (I am currently reviewing the docs at simgear.org), which files -- other than the EasyXML files themselves -- in the FlightGear tree should I peruse, and any other guidance on using EasyXML would be greatly appreciated and also increase my chance at success given my extremely limited time. You should have a look at SimGear / simgear / props / props_io.cxx to have an example of EasyXML use. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: data/Aircraft/pa28-161/Models
David Megginson wrote: Roy Vegard Ovesen wrote: Another thing that I noticed about the pa28 panel was the plane in the TC was not transparent where it should be. The rgb file did have an alpha channel but because the file was only 256 colors the alpha channel was not transparent in FlightGear. It was OK when I opened it in AC3D, but not in FlightGear. Converting the file to 24bit colour solved this, but I think that this is a bug, perhaps in plib. Was this in PLIB 1.6, again? The alpha transparency is fine using the CVS plib. I am using the CVS plib and I am seeing this bug. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
