Re: [Flightgear-devel] MD-11 Good News
Hi Ampere, I just tried your animation file. All I had to change were the lines that read property/controls/rudder/property to property/controls/flight/rudder/property and then I saw a nicely animated rudder appearing. Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs sideway. IIRC, this is a know problem of the plib 3ds model read function. We could have rotated the 3ds model by 90 degs in FlightGear's md11.xml file, so that the model would still have used the X-axis is front to back convention. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Hi Ampere If I gave the impression that I wanted to do some or all of the animations that was not my intention. I just ran a bit of animation code to see if FG had any problems reading 3DS scripts and it did not. I put the code below into the animation file and it seems to work fine if that is any help to you. As you seem to have it well under control I will leave it in your capable hands. Cheers Innis Ampere K. Hardraade writes Okay, let try something simple first. URudder and LRudder pass through the following coordinates: [54.3,0,6.25] [58.3,0,12.24] Displacement of the two points in vector is: [4,0,5.99] I believe the XML will be this: animation typerotate/type object-nameURudder/object-name property/controls/rudder/property factor18/factor center x-m54.30/x-m y-m0.0/y-m z-m6.25/z-m /center axis x4.0/x y0.0/y z5.99/z /axis /animation animation typerotate/type object-nameLRudder/object-name property/controls/rudder/property factor18/factor center x-m54.30/x-m y-m0.0/y-m z-m6.25/z-m /center axis x4.0/x y0.0/y z5.99/z /axis /animation Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs sideway. Regards, Ampere _ Personalise your phone with chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Tuesday 11 May 2004 08:31, Innis Cunningham wrote: Well Ampere the good news is that FG is quite happy to animate using the 3DS file. Another piece of good news is that the ground trimming problems have been solved by Mathias Frolich. His proposed solution is currently under investigation by Tony Peden and will hopefully traverse it's way from JSBSim cvs to FlightGear cvs wthin the next few days/weeks. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Tue, May 11, 2004 at 07:04:03PM -0400, Ampere K. Hardraade wrote: Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs sideway. No, that's not weird, that's standard in aeronautical engineering! (with the z-axis pointing down, btw.) Cheers, -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Durk Talsma wrote: Hi Ampere, I just tried your animation file. All I had to change were the lines that read property/controls/rudder/property to property/controls/flight/rudder/property and then I saw a nicely animated rudder appearing. Just a heads up for every body again, Don't add the leading slash to the animation property (property/controls/flight/rudder/property) but use relative paths instead (propertycontrols/flight/rudder/property) This allows the AIModel code to animate the model based on the property system for the particular AIModel rather than for the main aircraft (controlled by the user). Since the AIModel code will probably be used for ATC models and by the multiplayer code in the future this will give a much nicer view. For one thing that would mean that if the users extends the gear, all the AIModel will continue with gear up, instead of lowering the gear at the same time! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Mittwoch, 12. Mai 2004 09:56, Erik Hofman wrote: Just a heads up for every body again, Don't add the leading slash to the animation property (property/controls/flight/rudder/property) but use relative paths instead (propertycontrols/flight/rudder/property) This allows the AIModel code to animate the model based on the property system for the particular AIModel rather than for the main aircraft (controlled by the user). Since the AIModel code will probably be used for ATC models and by the multiplayer code in the future this will give a much nicer view. For one thing that would mean that if the users extends the gear, all the AIModel will continue with gear up, instead of lowering the gear at the same time! May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Mathias Fröhlich wrote: On Mittwoch, 12. Mai 2004 09:56, Erik Hofman wrote: Just a heads up for every body again, Don't add the leading slash to the animation property (property/controls/flight/rudder/property) but use relative paths instead (propertycontrols/flight/rudder/property) This allows the AIModel code to animate the model based on the property system for the particular AIModel rather than for the main aircraft (controlled by the user). Since the AIModel code will probably be used for ATC models and by the multiplayer code in the future this will give a much nicer view. For one thing that would mean that if the users extends the gear, all the AIModel will continue with gear up, instead of lowering the gear at the same time! May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Yes, that would be a good idea. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] multiple windows - offset setting not working
Hi, I posted this message to the user's group, but no one responded there. My department has a 3-screen setup for flightgear. With the old versions, it was possible to set the viewing angles for the right and left screen using command line option. However, with the current version (or recent few versions maybe), it doesn't work. I have to mannually adjust the offset. Could any developer take a look at this? Thanks. - Keeyoung ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple windows - offset setting not working
Keeyoung Choi wrote: I posted this message to the user's group, but no one responded there. My department has a 3-screen setup for flightgear. With the old versions, it was possible to set the viewing angles for the right and left screen using command line option. However, with the current version (or recent few versions maybe), it doesn't work. I have to mannually adjust the offset. Could any developer take a look at this? Thanks. In current versions you need to use something like: --prop:/sim/view/config/heading-offset-deg=45 --prop:/sim/view/config/pitch-offset-deg=3 Regards, 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A/C turns without power
Hi All While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. It also seemed the lighter A/C turned at a faster rate then the bigger ones. Just an observation. Cheers Innis _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. Which FDM(s)? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. Which FDM(s)? I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual u-fps, which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. As for Yasim, I tried the A-10, but it either sits on its tail, or bounces continualy on its gear. Maybe I have an old config. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Why ZERO
Hi Guys I am just wondering is there a very good reason that we use zero to number things in FG.Engines tanks and the like.Because in the real world of aviation nothing is numbered zero as far as I know. Why does it matter you may ask. Well it seems a bit strange that a four engined aircraft has engines numbered 0-3 and a three engined aircraft has engines numbered 0-2 and so on. As FG grows and more systems are added it would seem to me that the confusion could multiply. Is there a good reason that we do this and how hard would it be to change. I guess this applies to the FDM's to. Cheers Innis _ Personalise your phone with chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
Hi David David Culp writes Which FDM(s)? I was using the c172(dont know what it uses) and the MD-11 with JSBSim aeromatic generated FDM I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual u-fps, which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. Ok I have not got the latest CVS so don't know if its been fixed already.This is just the 9.4 version As for Yasim, I tried the A-10, but it either sits on its tail, or bounces continualy on its gear. Maybe I have an old config. I have been aware for a long time now that with the park brake set the A/C jumps around with the stall warning horn sounding all the time. Dave -- Cheers Innis _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
On Mittwoch, 12. Mai 2004 15:40, Innis Cunningham wrote: I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual u-fps, which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. Ok I have not got the latest CVS so don't know if its been fixed already.This is just the 9.4 version Is in the works. Is not yet in JSBSim mainline ... Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Ampere K. Hardraade wrote: Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs sideway. What convention would you have chosen? :) Coordinate systems are like cuisines. There's no accounting for taste, and you can't fix things by mixing them together. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Why ZERO
Because 0 is used in computing, if not aeronautics. (Small explanation for the non-technical: Originally, for complex and obscure technical reasons, array elements were numbered (indexed) starting at 0. This is still the case for c c++ and most other languages. There is no real reason for doing so at present that I've ever found, apart from tradition. That said, some of the fastest binary tree implementations take advantage of this, but with the processing power we play with these days it can't be really relevant) Giles Robertson -Original Message- From: Innis Cunningham [mailto:[EMAIL PROTECTED] Sent: 12 May 2004 13:30 To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Why ZERO Hi Guys I am just wondering is there a very good reason that we use zero to number things in FG.Engines tanks and the like.Because in the real world of aviation nothing is numbered zero as far as I know. Why does it matter you may ask. Well it seems a bit strange that a four engined aircraft has engines numbered 0-3 and a three engined aircraft has engines numbered 0-2 and so on. As FG grows and more systems are added it would seem to me that the confusion could multiply. Is there a good reason that we do this and how hard would it be to change. I guess this applies to the FDM's to. Cheers Innis _ Personalise your phone with chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ 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] Why ZERO
Innis Cunningham wrote: I am just wondering is there a very good reason that we use zero to number things in FG. Engines tanks and the like. Because in the real world of aviation nothing is numbered zero as far as I know. Why does it matter you may ask. Well it seems a bit strange that a four engined aircraft has engines numbered 0-3 and a three engined aircraft has engines numbered 0-2 and so on. As FG grows and more systems are added it would seem to me that the confusion could multiply. This can't be fixed. The underlying software engines (property system, C++, Nasal, all of it really) all use zero based indexing in accordance with (very) long standing software engineering convention. There's no reason the user should ever be exposed to internal indexing anyway, so the best we can do is present a consistent picture to the developers. As confused as you might be, I assure you it would only be worse if we all had to remember which subsystem used which array indexing convention. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] MD-11 Good News
How often do people need to specify the state of gear etc globally? I can't, offhand, think of a point at which you want all the aircraft in the world how drop the gear. Considering this, is the typo easy enough to make that we ought to change the behaviour? - or is this mucking up the established system too much? Or perhaps, /property/value should reference to the aircraft currently under user control, which would extend compatibility if we ever implement a 'switch which aircraft you are flying in mid-air' feature. Giles Robertson -Original Message- From: Andy Ross [mailto:[EMAIL PROTECTED] Sent: 12 May 2004 14:21 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] MD-11 Good News Mathias Fröhlich wrote: May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Or even generate a runtime warning during parsing. This is a really easy typo to make. Andy ___ 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] MD-11 Good News
Mathias Fröhlich wrote: May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Or even generate a runtime warning during parsing. This is a really easy typo to make. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Wednesday 12 May 2004 16:20, Andy Ross wrote: Mathias Fröhlich wrote: May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Or even generate a runtime warning during parsing. This is a really easy typo to make. I guess both are excellent ideas. I consulted David Culp's 737 config file to find out why the MD11 animation didn't work initially, and I didn't even spot the difference in leading slash between his configuration file and the animation section I had just I copied from Ampere's email until Erik's message. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GUI Layout Management
I just commited an implementation of GUI layout management, ported over from my game project last year*. What this means is that you no longer need to position your widgets manually in dialogs, and can instead lay them out in tables and boxes like the pros do. :) I've redone a few of the dialogs using the new scheme (I'm especially proud of the autopilot dialog: http://plausible.org/andy/autopilot-new.png), so you can see what the possibilities look like. * FWIW, this is almost the last of my useful code from last spring. Nasal and the Plib vertex splitting code are two other bits that were useful in isolation. I also had a terrain engine and stencil shadow implementation, but those weren't really production quality. Basically, the implementation is a preprocessor on top of the existing dialog properties, which sets x/y/width/height values based on constraints. The group objects, including the top-level one which represents the whole dialog, can now have a layout property, which can be hbox, vbox, or table. The boxes simply lay out their children in order, either top-to-bottom or left-to-right. The box name comes from Qt and Gtk, but this is also the same thing that Java calls a flow layout, or what the Tk packer does. You can set constraint properties on the children, to give the layout manager hints as to how to place the children. For the boxes, these are: equal: The box manager makes sure that all the widgets with this constraint set to true get equal sizes big enough to fit the largest one. This is very useful for button boxes to make the OK and Cancel buttons match, for example. stretch: Cells with stretch set to true get all the extra space, if any, the box has to allocate. These are useful for alignment purposes, especially when combined with empty widgets (which are ignored by the dialog creation code, but honored by the layout engine). The table layout will be a little more familiar to anyone with HTML experience. Children of tables get the following constraints: row: The row number containing the upper left corner of the widget. Table rows are zero-indexed. col: The column number containing the upper left corner of the widget. Table columns are zero-indexed. rowspan: The number of rows spanned by the widget. Defaults to one. colspan: The number of columns spanned by the widget. Defaults to one. Inside of each cell, regardless of parent layout, there are some constraints that are used to position the widget within the space available: halign: The horizontal alignment. Can be left, right, center, or fill (i.e. stretch to available space). valign: The vertical alignment. Can be top, bottom, center, or fill. padding: The number of pixels to leave between the edge of the cell and the widget. pref-height: pref-width: Overrides the default preferred size of the widget. Note that this is the size of the widget only, not the cell (which includes padding). Also, the padding values for cells in a group can be set to a default value with a default-padding property on the group widget. Some will ask why didn't I implement this as part of Pui. The problem is the pui just isn't set up for it. Not only is there no notion of preferred size for a widget, there isn't anything remote like a constraint system for attaching arbitrary values to widgets. With the property system, I have that for free (the original code was written to work with Nasal objects, btw). I can do the layout with the properties and on the properties, and our existing dialog code hardly needs to change at all. Anyway, give it a try and see if I've broken anything. Also, note that some of these changes *do* modify the visual appearance of the GUI. I think it looks better, but opinions will no doubt vary. Shout if you hate it. And finally, the text alignment doesn't quite look right with current plib due to some minor rendering bugs. Bug Steve to apply the patch I submitted a week or so ago. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
Andy Ross wrote: I just commited an implementation of GUI layout management, ported over from my game project last year*. What this means is that you no longer need to position your widgets manually in dialogs, and can instead lay them out in tables and boxes like the pros do. :) I've redone a few of the dialogs using the new scheme (I'm especially proud of the autopilot dialog: http://plausible.org/andy/autopilot-new.png), so you can see what the possibilities look like. I can't seem to set autothrottle speed with the new autopilot dialog. It keeps reverting 1.0 (might there be anyway to trim the trailing zeros?) Regards, 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
Curtis L. Olson wrote: I can't seem to set autothrottle speed with the new autopilot dialog. It keeps reverting 1.0 (might there be anyway to trim the trailing zeros?) Oh, whoops. Sorry, I meant to fix this before I checked it in but forgot. Both the pitch and speed input fields are mapped to the same property. I left two input fields in for symmetry, but the Nasal code that runs before the dialog-update command always sets the pitch one last, so it overrides. The immediate workaround is to set the value in the second field. A better solution would be to either write some Nasal to keep the values synchronized or else think of a new layout that works with only one input for both radio buttons... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
Andy Ross wrote: I just commited an implementation of GUI layout management, ported over from my game project last year*. What this means is that you no longer need to position your widgets manually in dialogs, and can instead lay them out in tables and boxes like the pros do. :) Whoo hoo! Now I can take that off my ever longer to-do list. Note to self: procrastination pays. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
I wrote: Curtis L. Olson wrote: I can't seem to set autothrottle speed with the new autopilot dialog. It keeps reverting 1.0 (might there be anyway to trim the trailing zeros?) A better solution would be to either write some Nasal to keep the values synchronized or else think of a new layout that works with only one input for both radio buttons... I just checked in a version that eliminates one of the fields and rowspan's the remaining one to center it over both lines. Ugly, maybe, but it should work for now. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
On Wednesday 12 May 2004 16:37, Andy Ross wrote: [snip...] * FWIW, this is almost the last of my useful code from last spring. Nasal and the Plib vertex splitting code are two other bits that were useful in isolation. I also had a terrain engine and stencil shadow implementation, but those weren't really production quality. Andy Was the stencil shadow stuff for generating object shadows? How far off usable was it, and did it only work with your terrain engine? It would be nice to have generated shadows - After trying them for a while, I've come to the conclusion that using fake shadow objects doesn't really cut it and I've started removing them from my models. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] A/C turns without power
Lee - There's no way that the screenshots on your site look like my standard FG scenery - I've never seen proper joins of taxiways to runways etc. How did you take them? Giles Robertson -Original Message- From: Lee Elliott [mailto:[EMAIL PROTECTED] Sent: 12 May 2004 18:38 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] A/C turns without power On Wednesday 12 May 2004 14:16, David Culp wrote: While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. Which FDM(s)? I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual u-fps, which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. As for Yasim, I tried the A-10, but it either sits on its tail, or bounces continualy on its gear. Maybe I have an old config. Dave Re the A-10 problem: is this with the cvs version? There's an updated package available at http://www.overthetop.freeserve.co.uk/FlightGearAC.html It's still not textured properly atm - just converted to .ac format and coloured, but as it's been re-named it'll co-exist with the version currently in cvs. This version should sit on it's u/c ok, even with no fuel in it;) LeeE ___ 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
[Flightgear-devel] Shadows
Lee Elliott wrote: Was the stencil shadow stuff for generating object shadows? How far off usable was it, and did it only work with your terrain engine? It was decidedly demo quality. But it was part of the model code, not the terrain engine. Doing shadows on terrain is sort of a 2D problem, and actually a little simpler (computationally faster, if not algorithmically easier) than doing a full-on general shadow implementation. Basically, there are two general techniques for doing shadows with 3D hardware: The first is to draw the object casting the shadow into a 1-bit-plus-depth shadow buffer from the point of view of the light source. You then use this buffer as a modulating texture for the light source when drawing the objects on which the shadow falls. This is a relatively straightforward process (although it requires some form of rendering to a texture, which wasn't standardized in OpenGL until recently) and works fast. The problems are that the resolution is limited to what you pick for the texture, so you can see pixelation effects if the viewer is close to an object which is far from the shadow caster. More seriously, you cannot use this technique for objects which cast shadows on *themselves* since the depth information in the shadow buffer isn't precise enough. Stenciling is the other trick. This is a geometric technique where you draw the shadow volume of an object into the stencil buffer. For each triangle, for example, you draw a tetrahedron containing its vertices and a vertex projected infinitely far away from the light source. You then use some nifty tricks involving the stencil buffer to tell which screen pixels are lit by the light source. This is a great technique, and works correctly in a very nice general way for every surface on the screen. It's also abysmally slow when implemented naively. Every (!) polygon ends up beign drawn as a big swath from its real position to one edge of the screen. This eats fill rate like there's no tomorrow. Production implementation need to do lots of bookeeping work to optimize the shadow volume such that only polygons on the silouette of the object are drawn (others are essentially useless). This is the part I didn't finish. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Saitek Cyborg Evo joystick xml file done
I witnessed a lot of discussion about joysticks with flightgear under windows, and the swapped axis problem. But when I connected this one, the only problem I had was that the default joystick mapping didn't include rudder control! Anyway, I made an xml based off of the Cyborg Gold 3D USB xml file and it works pretty well for me. If anyone wants a copy, I'll send it to you. Should this maybe go in the CVS? -Phillip ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
Erp! - I don't mind top or bottom posting, but both in a single e-mail confuses me;) Those screen shots were taken using the old photo scenery for KSJC, together with the old scenery data. I don't think it's been re-worked for the new scenery data - I no longer have it installed. So it's a bit of artistic license really;) LeeE On Wednesday 12 May 2004 19:54, Giles Robertson wrote: Lee - There's no way that the screenshots on your site look like my standard FG scenery - I've never seen proper joins of taxiways to runways etc. How did you take them? Giles Robertson -Original Message- From: Lee Elliott [mailto:[EMAIL PROTECTED] Sent: 12 May 2004 18:38 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] A/C turns without power On Wednesday 12 May 2004 14:16, David Culp wrote: While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. Which FDM(s)? I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual u-fps, which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. As for Yasim, I tried the A-10, but it either sits on its tail, or bounces continualy on its gear. Maybe I have an old config. Dave Re the A-10 problem: is this with the cvs version? There's an updated package available at http://www.overthetop.freeserve.co.uk/FlightGearAC.html It's still not textured properly atm - just converted to .ac format and coloured, but as it's been re-named it'll co-exist with the version currently in cvs. This version should sit on it's u/c ok, even with no fuel in it;) LeeE ___ 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
On Wednesday 12 May 2004 20:04, Andy Ross wrote: Lee Elliott wrote: Was the stencil shadow stuff for generating object shadows? How far off usable was it, and did it only work with your terrain engine? It was decidedly demo quality. But it was part of the model code, not the terrain engine. Doing shadows on terrain is sort of a 2D problem, and actually a little simpler (computationally faster, if not algorithmically easier) than doing a full-on general shadow implementation. Basically, there are two general techniques for doing shadows with 3D hardware: The first is to draw the object casting the shadow into a 1-bit-plus-depth shadow buffer from the point of view of the light source. You then use this buffer as a modulating texture for the light source when drawing the objects on which the shadow falls. This is a relatively straightforward process (although it requires some form of rendering to a texture, which wasn't standardized in OpenGL until recently) and works fast. The problems are that the resolution is limited to what you pick for the texture, so you can see pixelation effects if the viewer is close to an object which is far from the shadow caster. More seriously, you cannot use this technique for objects which cast shadows on *themselves* since the depth information in the shadow buffer isn't precise enough. Stenciling is the other trick. This is a geometric technique where you draw the shadow volume of an object into the stencil buffer. For each triangle, for example, you draw a tetrahedron containing its vertices and a vertex projected infinitely far away from the light source. You then use some nifty tricks involving the stencil buffer to tell which screen pixels are lit by the light source. This is a great technique, and works correctly in a very nice general way for every surface on the screen. It's also abysmally slow when implemented naively. Every (!) polygon ends up beign drawn as a big swath from its real position to one edge of the screen. This eats fill rate like there's no tomorrow. Production implementation need to do lots of bookeeping work to optimize the shadow volume such that only polygons on the silouette of the object are drawn (others are essentially useless). This is the part I didn't finish. :) Andy Thanks for the info. It's something I've wondered about, in a 'how do they do that?' sort of way, but it's a bit beyond my programming ability to do anything practical about it. Something to look forwards to, perhaps;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: RE: K-Class Blimp Blueprints]
[Note: forwarded from non-subscriber ] Original Message Subject: RE: K-Class Blimp Blueprints Date: Wed, 12 May 2004 17:58:22 + From: Christopher Daniels Corbett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Heard mention of some K-class USN bluprints around these parts... I'm gmax modeler making aircraft models for CFS3. I just found out about Flightgear *yesterday*--sounds interesting, and sounds like building a gmax ac for it just follows FS 2k2/4 procedures, correct? Open source, eh...cool! At present, I am working on a K-class blimp for the devil I know (CFS3) based on the few photos I could find on the internet. Details and working images of my progress to date can be found here: http://www.sim-outhouse.com/forums/showthread.php?s=threadid=12153 My screen name in those posts is Manymegs. If anybody still has those blueprints, or any other useful information about USN blimps and would be willing to share them, I would be most grateful to you! Anything from a simple line drawing to full engineering bluprints would be welcome and would be a great help to me in realizing a final model, which will be free to anyone who wishes to download it. I just discovered Flightgear and need to find out all the details, what is involved with aircraft modeling and conversion from gmax, etc. I can't promise to make a conversion to Flightgear since I know so little about it but I will promise, at mimimum to make the gmax files available to anybody who does want to make a conversion to Flightgear (someone who knows what they're doing.) Just need some plans to enusre the details are accurate. I do hope that you can help out, so we can share a combat-ready K-class blimp that might bring back some memories of Navy airships-- for all who are interested. Let's see the 'K' fly again! Regards, Chris [EMAIL PROTECTED] -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MingW, GUI, and build errors
Giles Robertson wrote: Just got an error on the following compile: In file included from C:/msys/1.0/fg/include/plib/pu.h:2140, from layout-props.cxx:1: C:/msys/1.0/fg/include/plib/puGLUT.h:36:22: GL/glut.h: No such file or directory My fault; I Forgot to test the build on a glutless system. Fixed. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Giles Robertson wrote: How often do people need to specify the state of gear etc globally? I can't, offhand, think of a point at which you want all the aircraft in the world how drop the gear. Considering this, is the typo easy enough to make that we ought to change the behaviour? - or is this mucking up the established system too much? Or perhaps, /property/value should reference to the aircraft currently under user control, which would extend compatibility if we ever implement a 'switch which aircraft you are flying in mid-air' feature. The problem is that this is only required for certain parts of the property tree (animation and maybe sound related), but other parts of the property tree should be accessible globally (time, sun positions, etc). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Tue, 2004-05-11 at 23:16, Durk Talsma wrote: On Tuesday 11 May 2004 08:31, Innis Cunningham wrote: Well Ampere the good news is that FG is quite happy to animate using the 3DS file. Another piece of good news is that the ground trimming problems have been solved by Mathias Frolich. His proposed solution is currently under investigation by Tony Peden and will hopefully traverse it's way from JSBSim cvs to FlightGear cvs wthin the next few days/weeks. It's in JSBSim CVS now, just needs to get into FG. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Saitek Cyborg Evo joystick xml file done
Phillip Jones wrote: I witnessed a lot of discussion about joysticks with flightgear under windows, and the swapped axis problem. But when I connected this one, the only problem I had was that the default joystick mapping didn't include rudder control! Anyway, I made an xml based off of the Cyborg Gold 3D USB xml file and it works pretty well for me. If anyone wants a copy, I'll send it to you. Should this maybe go in the CVS? Off course. Please sent it to me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
I think it happens on the 737 as well. Regards, Ampere On May 12, 2004 09:40 am, Innis Cunningham wrote: I was using the c172(dont know what it uses) and the MD-11 with JSBSim aeromatic generated FDM ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
hmm... if FlightGear is to be as realistic as possible, it will be a good idea to simulate everything down to the very last detail. Perhaps a translator of some sort can be written? Regards, Ampere On May 12, 2004 10:31 am, Andy Ross wrote: Innis Cunningham wrote: I am just wondering is there a very good reason that we use zero to number things in FG. Engines tanks and the like. Because in the real world of aviation nothing is numbered zero as far as I know. Why does it matter you may ask. Well it seems a bit strange that a four engined aircraft has engines numbered 0-3 and a three engined aircraft has engines numbered 0-2 and so on. As FG grows and more systems are added it would seem to me that the confusion could multiply. This can't be fixed. The underlying software engines (property system, C++, Nasal, all of it really) all use zero based indexing in accordance with (very) long standing software engineering convention. There's no reason the user should ever be exposed to internal indexing anyway, so the best we can do is present a consistent picture to the developers. As confused as you might be, I assure you it would only be worse if we all had to remember which subsystem used which array indexing convention. Andy ___ 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] Why ZERO
Ampere K. Hardraade wrote: hmm... if FlightGear is to be as realistic as possible, it will be a good idea to simulate everything down to the very last detail. Perhaps a translator of some sort can be written? I can't quite tell if this is a joke or not. If it is, then accept my apologies. In the real world, you don't use a property browser to configure your engine. Nor do real landing gear behave differently when the pilots secretly start referring to them with different indexing conventions. (Whatever you do, don't call the nose gear 'zero', it doesn't like that...) When you do realistic things like move levers, push buttons, and examine stuff in the cockpit, the FlightGear behavior should be expected to match real life. When you peek under the hood with the property browser and/or configure the simulator via XML files, you are looking at a software system, not an aircraft. IMHO, it should act the way software systems are expected to act. Real Programmers count from zero. Always have, always will. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Why ZERO
* Ampere K. Hardraade -- Thursday 13 May 2004 00:56:
hmm... if FlightGear is to be as realistic as possible, it will be a good idea
to simulate everything down to the very last detail.
Perhaps a translator of some sort can be written?
Yes, sure:
$ cat engine-number-translator
#!/usr/bin/perl -w
use strict;
sub help() {
print Usage: $0 [--to-index|--to-engine] number\n;
exit 0;
}
help unless @ARGV == 2;
if ($ARGV[0] eq --to-index) {
print $ARGV[1] - 1 . \n;
} elsif ($ARGV[0] eq --to-engine) {
print $ARGV[1] + 1 . \n;
} else {
help();
}
exit 0;
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Andy Ross wrote: stuff cut the way software systems are expected to act. Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Bruce Finney [EMAIL PROTECTED] Auburn, WA ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Bruce Finney wrote: Andy Ross wrote: Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! So we agree. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Bruce Finney wrote: the way software systems are expected to act. Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! Does that apply to both of them? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
On Thursday 13 May 2004 12:51 am, Bruce Finney wrote: Andy Ross wrote: stuff cut the way software systems are expected to act. Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! ...and APL programmers can choose, by assigning a value to the system variable IO (index origin). The default is 1, though. Sorry, Andy! Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
On Thursday 13 May 2004 12:57 am, David Megginson wrote: Bruce Finney wrote: the way software systems are expected to act. Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! Does that apply to both of them? Oi! Somewhere here I've got a stack of Hollerith cards with my first ever program, in Fortran, on it. Not Fortran77, though, because I punched it sometime in 1974. There's still lots of scientific stuff in Fortran. Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
On Thursday 13 May 2004 01:24, Jonathan Richards wrote: There's still lots of scientific stuff in Fortran. And there are plenty of Zeroth laws in science. Cheers, Al ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Jonathan Richards wrote: Oi! Somewhere here I've got a stack of Hollerith cards with my first ever program, in Fortran, on it. Not Fortran77, though, because I punched it sometime in 1974. Yes, I wrote my first programs in Fortran as well -- I was 13 in 1977, and used to sneak into the Queen's University computer centre at night with a, well, borrowed password, to run my card batches. I dropped a big pile of cards on my second visit, giving me my first lesson in the importance of good interfaces. Later that year my high school got a TRS-80 with BASIC, and I never looked back. Sure, the language was not optimal, but I didn't have any cards to drop and I could write video games for the other kids to play. There's still lots of scientific stuff in Fortran. There's still lots of business stuff in COBOL. Old code never dies: it just becomes someone else's problem. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Ok Andy I thought this maybe the case but I guess I was hopeing against hope that it was not. Cheers Innis Andy Ross writes This can't be fixed. The underlying software engines (property system, C++, Nasal, all of it really) all use zero based indexing in accordance with (very) long standing software engineering convention. There's no reason the user should ever be exposed to internal indexing anyway, so the best we can do is present a consistent picture to the developers. As confused as you might be, I assure you it would only be worse if we all had to remember which subsystem used which array indexing convention. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Ampere K. Hardraade wrote: Oh... I have to learn Fortran next year. Fortran is pretty much just like BASIC but the line numbers are optional. You can get the feel of it here: http://www.westnet.com/mirrors/99bottles/beer_d_h.html#f90 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
