Re: [Flightgear-devel] Website status
Andrei or Curt... On this page: http://www.flightgear.org/Docs/fgfs-model-howto.html There is a spot that says: * roll is a rotation around the x-axis, where positive is clockwise viewed from behind [[TODO: will someone volunteer to draw diagrams?]] This mini-HOWTO contains three parts: Here is a jpg of for the diagram if you all want to include it in the docs. http://24.121.17.106/misc/axis.jpg Re's WillyB On Sunday 27 July 2003 17:56, Andrei Barbu wrote: Website's done, I emailed curt with the files for it. Features page is the only one that stands not finished, because I couldn't think of enough to put there. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Bug#185558: fgfs-base: part II not in h2
Ove Kaaven [EMAIL PROTECTED] wrote: Here's a small fgfs-base bug report from the Debian bug tracker. It's against fgfs-base 0.8.0, but I see the problem still exist on http://www.flightgear.org/Docs/InstallGuide/getstart.html, so I guess it's still current. Thanks for the hint. I can't tell by now if we'll manage to change this because I don't know by now how much influence I have on the HTML generator (the manual is written in LaTeX), 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] Speed question?
5) Around the default KFSO, the framerate is way slower than in e.g. Slovenia. Is there any way to fix that (I know there are way more objects, but still I think it should be faster than 6 FPS when looking to the city or airfield) Is that fps in cockpit view or chase view? I get that sort of fps in chase view at KSFO too, but if in chase view there's also the a/c texture overhead as well. KSFO is pretty heavy especially if you've still got the high res textures. In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: Matevz Jekovec [EMAIL PROTECTED] said: 1) In mode 24 bpp, FlightGear ran faster than in 16 bpp (I also switched the Xfree depth to 24 and 16 then). Is there any known explanation (I haven't made benchmark, but judging by the eye I thought it was faster) for this. I think it's the textures fault as they are in 32 bit palette maybe? (including alpha channel) And FlightGear needs to calculate approximates to 24 output palette then? I wonder where the 16 bit dithering overhead comes in? Might this become a CPU speed (as opposed to interface) issue if there was a lot of texture swapping going on? I would think that any dithering would be cached...but... Best, Jim My suspicions were not correct. I benchmarked the framerate again yesterday and had 7 FPS in 24bpp mode and 9 FPS in 16bpp mode. I'm pretty sure the 16bpp mode worked faster in all views and positions in comparison to 24 bpp. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New key bindings for managing the views
I was intensively thinking about changing the current keys sets for viewing around. By combining Falcon and Flanker key sets, I've come to the following conclution: Joystick hat: - stays as it is, just that it is to slow and the factor should be increased for 8 times (that's just ok for my MS Precision pro) - inverted lateral hat for outside view (if you're looking the aircraft from the outside, it should rotate the view in the direction you move and not inverted like now) Mouse: - mouse cursor disappears if not moved in certain period. The coordinates of the cursor stay - mouse cursor changed when moved over a clickable/setable item in the cockpit - inverted lateral rotate for mouse in outside views. - only one mode for mouse: clickable cockpit mode. To fly with the mouse, you would hit ctrl+m or something like that and this will switch you to this steer mode. By hitting ctrl+m again, it will jump back to the clickable cockpit mode. - in clickable cockpit mode, left click clicks a button or increases value. Holding left mouse button and moving mouse increases/decreases the value in mouse direction. Right click decreases value. - panning view with mouse is possible (for more precise pan of the joystick hat) by holding down right mouse button and move the mouse around then. - scroll wheel moves in and out the view (not increasing/decreasing FOV!) in outside views and increasing/decreasing FOV in the cockpit. Keyboard: - numeric numbers rotate the view - inverted lateral rotate in outside view - numeric 9 and 3 walks in and out - numeric + and - increases/decreases FOV - no more V key for views, but seperate keys for all of them on number keys: inside views: 1 - inside view without the 2d and 3d cockpit. Just you and your HUD and maybe MFDs (able to turn of) later 2 - inside 2D panel view. Here you are able to really click the buttons with the mouse etc. 3 - inside 3D cockpit view. You are not able to press buttons yet (hm... this would be really cool!:)). But is meant for panning around (2D panel view should be still or should have preset possible positions of views) 4 - inside 3D padlock view. The same as the 3 key, but center a desired object and tracks it (turns the head to its direction and leave the cockpit rotate) all the time. Multiple 4 presses will walk through the objects in the screen. Shift+4 will walk back through the objects. Hat of the joystick breaks the padlock view and return to 3 key view. outside views: (left key of 1) - outside satellite view. Top-down very far away view of your aicraft. Multiple key presses toggles between top-down and botom-up satellite views. 0 - outside tracking aircraft view. Joystick hat, mouse drag of right button and numeric keys work. By turning aircraft around, the view stays and doesn't turn along the aircraft. When multiple hits, it walks through the objects from your aircraft to the farest away. ctrl + 0 - same as 0, but walks through just air objects. shift + 0 - same as 0, but walks through just ground objects. ctrl + shift + 0 - walks back through the current objects. 9 - outside chasing view. Same as 0 key view, but turns with the aircraft. shift + 9 - flyby view. Camera is still, placed somewhere in front of the aircraft. Then the aircraft flies through or very close to it. ctrl + 9 - tower view. Current tower view. Multiple presses walk through the nearst to the farest tower from your aicraft. when wanting to select a flyby view for not your aircraft, you'd have to firstly get to desired aircraft with 0 key and then hit shift+9 key to get in flyby view. I think I've covered the most of the views. However, the main idea is to have inside views from key 1 to the right and outside views from key 0 to the left (ok, satellite view is an exception). - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec writes: In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? 3d rendering performance really has nothing to do with how closely you view an item. It has more to do with how much geometry you are drawing, how much texture ram is consumed by the objects you are drawing, and how much layering is done (i.e. how many total pixels do you need to draw to paint the entire scene.) - When looking at a 3d cockpit, you probably have more geometry to draw because of the complexities of the inside of the cockpit. To draw a lot of geometry you want a fast CPU and a fast AGP buss. - You also could have increased texture ram use because all the instruments are made from textures attached to polygons. To draw lots of textures without having to swap memory around, you want a card with lots of texture ram. - You could have increased layering as well. Think about it this way. If are pointed up and the sky takes up the whole view, I have to draw the blue sky background. Then I may need to redraw the entire screen again to add a semi-transpant cloud texture that covers the whole sky. Maybe there are 2 layers so I need to repaint the whole screen again for the 2nd layer. That means I had to draw 1024x768 pixels for the blue sky (or whatever your resolution is.) Then I have to update those 1024x768 pixels for each cloud texture. For panels it is a similar issue because instruments are made up of layers that are drawn over the top of each other (the HSI has many layers.) When the instrument panel takes up the whole screen you may have to update a particular pixel several times to get the finished scene. To handle this sort of situation well, you want a video card with high fill rate. That won't necessarily help you get faster frame rates and won't necessarily help people afford faster video cards, but those are some of the issues ... What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already? !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1 title/title /head body text=#00 bgcolor=#ff meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1 title/title meta http-equiv=Content-Type content=text/html;charset=iso-8859-1 title/title br blockquote type=cite cite=[EMAIL PROTECTED] pre wrap= /pre blockquote type=cite pre wrap=5) Around the default KFSO, the framerate is way slower than in e.g. Slovenia. Is there any way to fix that (I know there are way more objects, but still I think it should be faster than 6 FPS when looking to the city or airfield) /pre /blockquote pre wrap=! Is that fps in cockpit view or chase view? I get that sort of fps in chase view at KSFO too, but if in chase view there's also the a/c texture overhead as well. KSFO is pretty heavy especially if you've still got the high res textures. /pre /blockquote In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway?br br What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already?br /body /html
[Flightgear-devel] Fokker 50 turboprop commuter
Thanks Fred Nice aircraft also the 100 to.Noticed that it (f50) seemed a little touchey on pitch but nothing bad. Also on a different subject.The maintance hangar at KSFO does not seem to be in the stg file yet.If not what are its co ordinates.Is it the United airlines hangar.If so which one. You must have Blender just about worn out LOL. Thanks again. Cheers Innis _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=174referral=Hotmail_taglines_plainURL=http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Binary scenery file format
Hello, can you tell me the format of the .btg-files, and if it is possible to get a more detailed shape of the mountains by manually adding some points to the landscape definition? Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
man, 28.07.2003 kl. 14.03 skrev Curtis L. Olson: - When looking at a 3d cockpit, you probably have more geometry to draw because of the complexities of the inside of the cockpit. To draw a lot of geometry you want a fast CPU and a fast AGP buss. For geometry-limited situations, a fast AGP bus does not necessarily help all that much if you're using TL hardware and vertices are not actually stored in AGP memory, since then the drivers have to use system resources to transfer the vertex data from system memory to the card on every rendering call (in case the app changed the data between them), instead of letting the card fetch the vertices it needs straight from AGP memory on its own. In some situations, EXT_compiled_vertex_array can be useful to reduce the frequency of redundant transfers. But it's also possible to use the ARB_vertex_buffer_object, NV_vertex_array_range, or ATI_vertex_array_object extensions to store vertices directly in AGP memory where the card can get at it when it wants to. Trust me, for high geometry, it *really* makes a difference. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fokker 50 turboprop commuter
* Innis Cunningham -- Monday 28 July 2003 14:38: The maintance hangar at KSFO does not seem to be in the stg file yet. It is! - $FG_ROOT/Scenery/w130n30/w123n37/942058.stg m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Binary scenery file format
Harald Haspl wrote: Hello, can you tell me the format of the .btg-files, and if it is possible to get a more detailed shape of the mountains by manually adding some points to the landscape definition? This is the purpose of fgsd ( http://fgsd.sourceforge.net/ ). Still work in progress though. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker 50 turboprop commuter
Innis Cunningham wrote: Thanks Fred Full credits should go to Erik for the Fokker family ! I am only responsible for the Airbus A320. Nice aircraft also the 100 to.Noticed that it (f50) seemed a little touchey on pitch but nothing bad. Also on a different subject.The maintance hangar at KSFO does not seem to be in the stg file yet.If not what are its co ordinates.Is it the United airlines hangar.If so which one. This is not the United Airlines hangar. Just the one in from of the central terminal. It is in 942058.stg, as well as the Candlestick Park Stadium. Here is a long url that shows it : http://www.airliners.net/open.file?id=277445WxsIERv=TWNEb25uZWxsIERvdWdsYXMgTUQtODcgKERDLTktODcpWdsYXMg=UHJpdmF0ZQ%3D%3DQtODMg=U2FuIEZyYW5jaXNjbyAtIEludGVybmF0aW9uYWwgKFNGTyAvIEtTRk8pERDLTkt=VVNBIC0gQ2FsaWZvcm5pYQ%3D%3DktODMp=QXByaWwgMTk5OA%3D%3DWNEb25u=TWFyayBEdXJiaW4%3DxsIERvdWdsY=TjNIBP=0MgTUQtODMgKE=YXMgTUQtODMgKERD=MjA5NEb25uZWxs=MjAwMi0wOS0yNg%3D%3Dstatic=yessize=M You must have Blender just about worn out LOL. Blender is a very productive tool. Worth the time it takes to learn the basics. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker 50 turboprop commuter
On Mon, 28 Jul 2003, Frederic Bouvier wrote: Blender is a very productive tool. Worth the time it takes to learn the basics. Agreed - Initial attempts at using it left me wondering what sort of substances the people who designed the UI were abusing, but once you get the hang of it it's rather productive. I'm just trying to get my head around the UV editor now. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker 50 turboprop commuter
Jon Stockill writes: On Mon, 28 Jul 2003, Frederic Bouvier wrote: Blender is a very productive tool. Worth the time it takes to learn the basics. Agreed - Initial attempts at using it left me wondering what sort of substances the people who designed the UI were abusing, but once you get the hang of it it's rather productive. I'm just trying to get my head around the UV editor now. I'm no 3d modeling expert, but I have yet to see any 3d modeler with a comprehensible gui. 3d modeling is a very complex process and so the gui's are also necessarily complex. But with most of them, you can be very productive once you learn the various tricks and keyboard accelerators, and what the 300+ 8x8 icons stand for. And then if you leave the program for a month or two you have to learn it all from scratch again. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
If you are in 3D move the view to the right or left and you'll see the rate go right back up. The reason this works is the panel items are culled from the view and I presume their textures can be swapped out by the card. The hit in the cockpit is primarily the texture ram, and a little bit more geometry (quite a bit more in the case of the p51d). In any case this little test suggests that breaking aircraft into two models won't necessarily work. And if you want to be able to see the exterior parts from inside the cockpit (which I definately do) then you will need to render both anyway. Generally if aircraft models are used in a multiple aircraft situation, we need to do at least one of two things. One is have simplified aircraft models (separate model which just has less polys and no cockpit). The other thing is to put LOD selectors in the animation xml for the model. Some of the aircraft already have xml that does this by selecting out the cockpit and maybe gear when they are viewed from a certain distance. In that case the cockpit would be removed as well as other interior geometry. I think the first option is probably the most effective. This is maybe a little different than some other approaches, but my guess is we'll find that we'll need separate models for other aircraft (AI and multiplayer) that are simplified with much less geometry and smaller textures. Best, Jim Matevz Jekovec [EMAIL PROTECTED] said: In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Fokker 50 turboprop commuter
I'm no 3d modeling expert, but I have yet to see any 3d modeler with a comprehensible gui. 3d modeling is a very complex process and so the gui's are also necessarily complex. But with most of them, you can be very productive once you learn the various tricks and keyboard accelerators, and what the 300+ 8x8 icons stand for. And then if you leave the program for a month or two you have to learn it all from scratch again. :-) Curt. Moray is excellent, IMHO, but it's aimed more at 3D ray-tracing than 3D modeling for realtime. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument help
If ther eis a switch for CHT .. would this be so you can manually adjust the temp if needed? No. Cylinder Head Temp is usually used to help you assess the health of your engine. If it is running too hot it is likely to shorten the life of the engine. If it is running really hot then it's probably about to die very soon. IIRC, running lean at high power settings increases CHT. Running rich decreases it since there is more fuel to help dissipate heat. In the context of a racer, CHT is helpful in knowing if you can push your engine a little harder without blowing it I suppose. Then again, I might be totally wrong! Cheers, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: If you are in 3D move the view to the right or left and you'll see the rate go right back up. The reason this works is the panel items are culled from the view and I presume their textures can be swapped out by the card. The hit in the cockpit is primarily the texture ram, and a little bit more geometry (quite a bit more in the case of the p51d). In any case this little test suggests that breaking aircraft into two models won't necessarily work. And if you want to be able to see the exterior parts from inside the cockpit (which I definately do) then you will need to render both anyway. We added wings and tails objects, taken from the aircraft you are in, to that 3d cockpit. Then you were able to see the wings and tails. However, these were seperated models and have nothing in common with the aircraft model (except the textures, so you'd think this is really the aircraft model itself). Generally if aircraft models are used in a multiple aircraft situation, we need to do at least one of two things. One is have simplified aircraft models (separate model which just has less polys and no cockpit). The other thing is to put LOD selectors in the animation xml for the model. Some of the aircraft already have xml that does this by selecting out the cockpit and maybe gear when they are viewed from a certain distance. In that case the cockpit would be removed as well as other interior geometry. I think the first option is probably the most effective. This is maybe a little different than some other approaches, but my guess is we'll find that we'll need separate models for other aircraft (AI and multiplayer) that are simplified with much less geometry and smaller textures. Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec [EMAIL PROTECTED] said: Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? You can, yes. Though it might be useful to simplify the geometry of the objects that you select to show as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] away for the week
In case anybody cares, I will be off to LA, California all this week. I'll have very limited email access so hopefully anything that involves me can wait until I return. Best regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS: main.cxx error: no matching function forcall to `SGSky::build
so just today I downloaded the plib, SimGear and FlightGear all CVS, the plib didn't compile at start, I had to comment out line 146 from the file plib/src/ssg/ssg.cxx ssgAddModelFormat ( .asc, NULL, ssgSaveASC ) ; after that the plib compiled ok, the SimGear compiled out of the box.. and finally I started the Flight Gear... it stopped with this error: main.cxx: In function `bool fgMainInit(int, char**)': main.cxx:1771: error: no matching function for call to `SGSky::build(double, double, int, double (*)[3], double, int, double (*)[3], double)' /usr/local/include/simgear/scene/sky/sky.hxx:240: error: candidates are: void SGSky::build(double, double, double, double, int, double (*)[3], int, double (*)[3]) my OS is GNU/Linux Debian 3.0, XFree 4.3, WindowMaker 0.81 (CVS) with GeForce 4 MX 420 and the newest nVidia drivers kernel version: 2.4.22-pre8 gcc 3.3, glibc 2.2.3 my Flight Gear config summary: Prefix: /usr/local Plib PSL scripting: yes Debug messages: yes Automake version: automake (GNU automake) 1.4-p4 Using FGEnvironment Using default multiplayer support threads: no any ideas? with regards Lukasz Hejnak [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: main.cxx error: no matching functionfor call to `SGSky::build
Lukasz Szift Hejnak wrote: so just today I downloaded the plib, SimGear and FlightGear all CVS, the plib didn't compile at start, I had to comment out line 146 from the file plib/src/ssg/ssg.cxx ssgAddModelFormat ( .asc, NULL, ssgSaveASC ) ; after that the plib compiled ok, the SimGear compiled out of the box.. and finally I started the Flight Gear... it stopped with this error: main.cxx: In function `bool fgMainInit(int, char**)': main.cxx:1771: error: no matching function for call to `SGSky::build(double, double, int, double (*)[3], double, int, double (*)[3], double)' /usr/local/include/simgear/scene/sky/sky.hxx:240: error: candidates are: void SGSky::build(double, double, double, double, int, double (*)[3], int, double (*)[3]) It looks like you are mixing a CVS version of FlightGear with the stable version of SimGear. It could be that SimGear was already available on your system, but on a different location than where you have placed the new version. Try removing all simgear related files from your system and install it again to see if that solves this problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker 50 turboprop commuter
On Monday 28 July 2003 06:25, Jon Stockill wrote: On Mon, 28 Jul 2003, Frederic Bouvier wrote: Blender is a very productive tool. Worth the time it takes to learn the basics. Agreed - Initial attempts at using it left me wondering what sort of substances the people who designed the UI were abusing, but once you get the hang of it it's rather productive. I'm just trying to get my head around the UV editor now. LOL !!! I was thinking it was a combination of substances! These have been helping me a lot: http://docs.artun.ee/blender/blenderboard-us2.gif http://blender.excellentwhale.com/ http://reblended.com/tutorials/uvmapping.html On the chance you have not found them yet. Re's WillyB ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument help
From: Matthew Law [EMAIL PROTECTED] If ther eis a switch for CHT .. would this be so you can manually adjust the temp if needed? No. Cylinder Head Temp is usually used to help you assess the health of your engine. CHT itself doesn't have a switch, it is purely a measurement. _However_ ... * Some people put EGT and CHT on the same dial and need a switch to select which output is being shown at any given time. * Like EGT, it is often useful to have a peak hold feature, in which case you need a switch to disable the peak hold. * You normally have one CHT sensor per cylinder (sometimes two), so you either need to have lots of dials, or a switch to select among them, or an electronic display to cycle through them, etc. * On a racing aircraft, I might be tempted to connect an autothrottle to the CHT (with a switch to disable it), just like a lot of acft have an autolean that operates the mixture on carburated engines. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument help
H Ok, I'm probably confusing the switch then. I resized and enhanced the photos and have attached the new one I made from it. Is that 4 position switch for the C HT or am I totally wrong on that? Re's WillyB On Monday 28 July 2003 11:42, Alex Perry wrote: From: Matthew Law [EMAIL PROTECTED] If ther eis a switch for CHT .. would this be so you can manually adjust the temp if needed? No. Cylinder Head Temp is usually used to help you assess the health of your engine. CHT itself doesn't have a switch, it is purely a measurement. _However_ ... * Some people put EGT and CHT on the same dial and need a switch to select which output is being shown at any given time. * Like EGT, it is often useful to have a peak hold feature, in which case you need a switch to disable the peak hold. * You normally have one CHT sensor per cylinder (sometimes two), so you either need to have lots of dials, or a switch to select among them, or an electronic display to cycle through them, etc. * On a racing aircraft, I might be tempted to connect an autothrottle to the CHT (with a switch to disable it), just like a lot of acft have an autolean that operates the mixture on carburated engines. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel attachment: chtimg.jpg___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument help
The engine has four cylinders and the four-position switch in question allows the pilot to select between four Cylinder Head Temperature sensors (one in each cylinder head). Kris WillyB wrote: H Ok, I'm probably confusing the switch then. I resized and enhanced the photos and have attached the new one I made from it. Is that 4 position switch for the C HT or am I totally wrong on that? Re's WillyB On Monday 28 July 2003 11:42, Alex Perry wrote: From: Matthew Law [EMAIL PROTECTED] If ther eis a switch for CHT .. would this be so you can manually adjust the temp if needed? No. Cylinder Head Temp is usually used to help you assess the health of your engine. CHT itself doesn't have a switch, it is purely a measurement. _However_ ... * Some people put EGT and CHT on the same dial and need a switch to select which output is being shown at any given time. * Like EGT, it is often useful to have a peak hold feature, in which case you need a switch to disable the peak hold. * You normally have one CHT sensor per cylinder (sometimes two), so you either need to have lots of dials, or a switch to select among them, or an electronic display to cycle through them, etc. * On a racing aircraft, I might be tempted to connect an autothrottle to the CHT (with a switch to disable it), just like a lot of acft have an autolean that operates the mixture on carburated engines. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument help
From: WillyB [EMAIL PROTECTED] Ok, I'm probably confusing the switch then. I resized and enhanced the photos and have attached the new one I made from it. Is that 4 position switch for the C HT or am I totally wrong on that? Url : http://mail.flightgear.org/pipermail/flightgear-devel/\ attachments/20030728/02418d4a/chtimg.jpg Aha! Nicely enhanced; it resolves the confusion. The two switches lower left are the magnetos as you've already figured out. The rotary analog display is labelled CYL HEAD TEMP and only has one needle (white) and the redline (which is irrelevant to the discussion). From: Alex Perry [EMAIL PROTECTED] * You normally have one CHT sensor per cylinder (sometimes two), so you either need to have lots of dials, or a switch to select among them, or an electronic display to cycle through them, etc. The metal control (without a knob) is shown, in both the drawing and the panel, with four positions and, in the drawing, is labelled CHT select. I therefore assert that this aircraft has a four cylinder engine and this selects which cylinder measurement is going to be seen on the dial. Individual cylinders have slightly more or less airflow cooling (due to the pattern of baffles in front of the firewall) and receive slightly different richness in the mixture (due to fuel injection differences, or uneven atomization after the carbureter as appropriate). For each engine (and baffle layout), the pattern of differences is generally well known and the behavior is pretty consistent across most of the fleet. After enough experience in an aircraft, many owners know which cylinder is going to be hottest for a given phase of flight and therefore can leave the switch in a single position, just changing it (eg) after climb ends. Periodically, the pilot will cycle through all the cylinders to make sure they all read as expected, as a way of detecting some imminent failures. As far as simulating it is concerned, there are standard models for how CHT changes as a function of operating conditions for a given cylinder. Therefore, we could easily have per-cylinder parametrics for the cooling and for the mixture (in the engine file) that drive a standard CHT model. Those parametric values, plus the broken status of each CHT sensor, would be accessible to the instructor through the property tree. Hope that helps ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument help
Thanks Kris That makes sense :) WillyB On Monday 28 July 2003 12:34, Kris Feldmann wrote: The engine has four cylinders and the four-position switch in question allows the pilot to select between four Cylinder Head Temperature sensors (one in each cylinder head). Kris WillyB wrote: H Ok, I'm probably confusing the switch then. I resized and enhanced the photos and have attached the new one I made from it. Is that 4 position switch for the C HT or am I totally wrong on that? Re's WillyB On Monday 28 July 2003 11:42, Alex Perry wrote: From: Matthew Law [EMAIL PROTECTED] If ther eis a switch for CHT .. would this be so you can manually adjust the temp if needed? No. Cylinder Head Temp is usually used to help you assess the health of your engine. CHT itself doesn't have a switch, it is purely a measurement. _However_ ... * Some people put EGT and CHT on the same dial and need a switch to select which output is being shown at any given time. * Like EGT, it is often useful to have a peak hold feature, in which case you need a switch to disable the peak hold. * You normally have one CHT sensor per cylinder (sometimes two), so you either need to have lots of dials, or a switch to select among them, or an electronic display to cycle through them, etc. * On a racing aircraft, I might be tempted to connect an autothrottle to the CHT (with a switch to disable it), just like a lot of acft have an autolean that operates the mixture on carburated engines. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: main.cxx error: no matching functionfor call to `SGSky::build
Mon, 28 Jul 2003 19:19:32 +0200 Erik Hofman [EMAIL PROTECTED] napisal: Lukasz Szift Hejnak wrote: so just today I downloaded the FlightGear all CVS,it stopped at compile.. cut Try removing all simgear related files from your system and install it again to see if that solves this problem. I tried that, and it didn't help, but I took a look into those files (main.cxx and sky.hxx) and found out, what might be the error.. flightgear/src/Main/main.cxx lines: 1767-1771 looked like this thesky-build( 550.0, 550.0, globals-get_ephem()-getNumPlanets(), globals-get_ephem()-getPlanets(), 6.0, globals-get_ephem()-getNumStars(), globals-get_ephem()-getStars(), 6.0); and in the sky.hxx the function took a bit different order of those arguments: /usr/local/include/simgear/scene/sky/sky.hxx line: 237 void build( double h_radius_m, double v_radius_m, double sun_size, double moon_size, int nplanets, sgdVec3 *planet_data, int nstars, sgdVec3 *star_data ); so I changed the order of the args in main.cxx and ended up with: flightgear/src/Main/main.cxx lines: 1767-1771 thesky-build( 550.0, 550.0, 6.0, 6.0, globals-get_ephem()-getNumPlanets(), globals-get_ephem()-getPlanets(), globals-get_ephem()-getNumStars(), globals-get_ephem()-getStars() ); it solved the compile problem.. no it's for testing, but judging from the var names I think it will work ok dunno how come this passed compiling for the outhers though... thx anyway for the response :) -- with regards Lukasz Hejnak [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker 50 turboprop commuter
Agreed - Initial attempts at using it left me wondering what sort of substances the people who designed the UI were abusing, but once you get the hang of it it's rather productive. I'm just trying to get my head around the UV editor now. Can you guys recommend any tutorial resources for the likes of myself who have a little 3DS Max experience but are still cluless when it comes to Blender? Anyone feel like doing a FGFS-only aircraft modelling with blender tutorial by any chance? Cheers, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker 50 turboprop commuter
Besides the urls I posted earlier in this thread, there's this page: http://www.blender3d.org/Education/ and this whole site here is very good as well. probably better actually ;) http://www.elysiun.com/ I've gotten pretty good at the basics.. but there's still a lot more I don't know than I do know about Blender. Aside: At the moment I'm trying to get the manifolds? of the cassutt racer put on the 3d model.. but, I can't seem to make them look right at all .. period! lol (they stick out the front sides of the fusilage for the engine) As soon as those are done I'll put the model up for public bashing ;) Re's William B McRaven WillyB On Monday 28 July 2003 15:12, Matthew Law wrote: Agreed - Initial attempts at using it left me wondering what sort of substances the people who designed the UI were abusing, but once you get the hang of it it's rather productive. I'm just trying to get my head around the UV editor now. Can you guys recommend any tutorial resources for the likes of myself who have a little 3DS Max experience but are still cluless when it comes to Blender? Anyone feel like doing a FGFS-only aircraft modelling with blender tutorial by any chance? Cheers, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: Matevz Jekovec [EMAIL PROTECTED] said: Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? You can, yes. Though it might be useful to simplify the geometry of the objects that you select to show as well. Best, Jim But we can use a combination of both, right? If you will look at an aircraft at range of 15 feets, you see nothing. At 100k feets, you see a dot. At 7, you would see a triangle. At 5, you would see a rough shape. At 25000, the next one and at 1 a complete model without inner instruments. At 10 feet, you would see the inner instruments as well. I think LOD selector is very usable because instruments like radar, weapon control, radio controls etc. can really eat up lots of CPU for calculating and GPU for rendering it. So, when we implement all this some day, this might save lots of FPS then. We can assign a simple texture for e.g. radar behind the real calculated radar display to fill the whole between 100 and 1 feet. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: main.cxx error: no matching function forcall to `SGSky::build
Lukasz Szift Hejnak [EMAIL PROTECTED] said: so I changed the order of the args in main.cxx and ended up with: flightgear/src/Main/main.cxx lines: 1767-1771 thesky-build( 550.0, 550.0, 6.0, 6.0, globals-get_ephem()-getNumPlanets(), globals-get_ephem()-getPlanets(), globals-get_ephem()-getNumStars(), globals-get_ephem()-getStars() ); it solved the compile problem.. no it's for testing, but judging from the var names I think it will work ok dunno how come this passed compiling for the outhers though... thx anyway for the response :) That really does look like it is an out of date SimGear function you are building against. If you are using cvs is there any chance you've got a file or two tagged so they won't update (e.g. specific version from a past rollback)? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] away for the week
Curtis L. Olson wrote: In case anybody cares, I will be off to LA, California all this week. I'll have very limited email access so hopefully anything that involves me can wait until I return. Best regards, Curt. We wish you a good trip Curt. I hope you know that we do care if you leave even for a week and that FGFS would never come so far without you (or at least I see you like FGFS meister:)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec [EMAIL PROTECTED] said: Jim Wilson wrote: Matevz Jekovec [EMAIL PROTECTED] said: Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? You can, yes. Though it might be useful to simplify the geometry of the objects that you select to show as well. But we can use a combination of both, right? If you will look at an Yes, absolutely. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] away for the week
Matevz Jekovec writes: (or at least I see you like FGFS meister:)) FWIW AFAIK Curt *is* the 'official' FlightGear BDFL Benevolent Dictator For Life at-least-until-he-resign'ly yr's Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
