Re: [Flightgear-devel] idea ... (?)
Fine. I will send it first thing on Monday to Curt alongwith a sample ascii format data file to help you see what it does. We have also put together a short 'instructions for use' and that may be of some help in understanding how it works. Regards Ranga --- Alex Perry <[EMAIL PROTECTED]> wrote: > I suggest that you submit it mostly as-is and have > Curt place it into CVS > so we can all see how it's implemented ... that way > we will have a basis to > give you realistic answers to those questions > (instead of guessing). > > > OK. I will do so on Monday (11th March). Do you > want > > me to integrate it into SimGear so that its > offline > > plotting function could be used by people who work > > with one PC and the stand-alone executable could > be > > used by those who have more than one PC.? Or > Should I > > just send the stand-alone code to Curt?. > > As a first step I will just integrate it as is, > test > > it with our FDM (for real-time) and our ascii > format > > data file (for off-line) and send it to Curt. Once > I > > recieve suggestions from you I could get it to > work > > with other FDMs of FlightGear. > > Regards > > Ranga > > --- Jon Berndt <[EMAIL PROTECTED]> wrote: > > > This sounds ideal! I vote that you submit it! > :-) > > > > > > What are the code dependencies? SimGear? > > > > > > Jon > > > > > > > I have a stand-alone real-time and off-line > > > plotting > > > > tool written in C/C++ (tested in > > > Cygwin/WinNT/Win2K & > > > > Linux) that is meant to be used as a flight > test > > > > engineer's station. It has just been completed > and > > > it > > > > works, but I am yet to put it to serious use. > The > > > code > > > > is designed to run a separate PC and recieve > data > > > via > > > > network from the FDM and the plots are > > > configurable > > > > via xml. Offline plots have zoom facility, > scales > > > (x/y > > > >... > > > > > > > > > > > > ___ > > > Flightgear-devel mailing list > > > [EMAIL PROTECTED] > > > > > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > > __ > > Do You Yahoo!? > > Try FREE Yahoo! Mail - the world's greatest free > email! > > http://mail.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 __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] UIUC models update
Hi All, I have updated our UIUC models and posted them here: http://amber.aae.uiuc.edu/~m-selig/apasim/Aircraft-uiuc.html Changes: - Updated gear parameters for all aircraft. Many aircraft before did not have any gear parameters which made it nearly impossible to takeoff from the runway. - Removed the Twin Otter files with icing. The reason is that I just have not got to those yet. They are very nonlinear models and lots of work. - Several aircraft include stall nonlinearities. Look for the "nonlinear models". - New aircraft added Schweizer SGS 1-36 (nonlinear model) 1903 Wright Flyer (nonlinear model) The Wright Flyer is really neat! Aerodynamically I'd say this is a "95% model," which is to say it's pretty close to the real thing (I think). I used NASA Ames wind tunnel data taken on the Wright Flyer, but I had to augment that because the test did not include everything. The full list: - Beech 99 (last update 3/6/02) - Boeing 747 (last update 3/6/02) - Cessna 172 (four versions, last update 3/6/02) - Cessna 310 (last update 3/6/02) - Cessna 620 (last update 3/6/02) - Cessna T-37 (last update 3/6/02) - Convair 880 (last update 3/6/02) - F-104 Starfighter (last update 3/6/02) - F-4 Phantom (last update 3/6/02) - Learjet 24 (last update 3/6/02) - Marchetti S-211 (last update 3/6/02) - Pioneer UAV (last update 3/6/02) - Piper Cherokee (last update 3/6/02) - Schweizer SGS 1-36 (last update 3/6/02) - Twin Otter (last update 3/6/02) - 1903 Wright Flyer (last update 3/6/02) - X-15 (last update 3/6/02) The files are setup to run with FGFS 0.7.8. We are in the process of getting 0.7.9 to work here, at which time I can update them again. If anyone has any recommendations on the webpage layout and/or how I am handling the files, let me know. (I still need to add one tarball of all the models.) I'd be happy to see these updates get into the CVS. It probably makes the most sense to wait until we have the 0.7.9 versions working. I am *very* unclear on what it takes to run the UIUC models w/ 0.7.9. It seems that several things have changed. If anyone has them, I'd like to get publicly released 3D models for: - Wright Flyer (I have one, but we have not yet got permission to give it out) - SGS 1-36 - Pioneer UAV - Marchetti S-211 - Learjet 24 - Piper Cherokee I included a link to Wolfram's site for all of the other 3D models. Back to more modeling! Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
I suggest that you submit it mostly as-is and have Curt place it into CVS so we can all see how it's implemented ... that way we will have a basis to give you realistic answers to those questions (instead of guessing). > OK. I will do so on Monday (11th March). Do you want > me to integrate it into SimGear so that its offline > plotting function could be used by people who work > with one PC and the stand-alone executable could be > used by those who have more than one PC.? Or Should I > just send the stand-alone code to Curt?. > As a first step I will just integrate it as is, test > it with our FDM (for real-time) and our ascii format > data file (for off-line) and send it to Curt. Once I > recieve suggestions from you I could get it to work > with other FDMs of FlightGear. > Regards > Ranga > --- Jon Berndt <[EMAIL PROTECTED]> wrote: > > This sounds ideal! I vote that you submit it! :-) > > > > What are the code dependencies? SimGear? > > > > Jon > > > > > I have a stand-alone real-time and off-line > > plotting > > > tool written in C/C++ (tested in > > Cygwin/WinNT/Win2K & > > > Linux) that is meant to be used as a flight test > > > engineer's station. It has just been completed and > > it > > > works, but I am yet to put it to serious use. The > > code > > > is designed to run a separate PC and recieve data > > via > > > network from the FDM and the plots are > > configurable > > > via xml. Offline plots have zoom facility, scales > > (x/y > > >... > > > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > __ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.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] idea ... (?)
OK. I will do so on Monday (11th March). Do you want me to integrate it into SimGear so that its offline plotting function could be used by people who work with one PC and the stand-alone executable could be used by those who have more than one PC.? Or Should I just send the stand-alone code to Curt?. As a first step I will just integrate it as is, test it with our FDM (for real-time) and our ascii format data file (for off-line) and send it to Curt. Once I recieve suggestions from you I could get it to work with other FDMs of FlightGear. Regards Ranga --- Jon Berndt <[EMAIL PROTECTED]> wrote: > This sounds ideal! I vote that you submit it! :-) > > What are the code dependencies? SimGear? > > Jon > > > I have a stand-alone real-time and off-line > plotting > > tool written in C/C++ (tested in > Cygwin/WinNT/Win2K & > > Linux) that is meant to be used as a flight test > > engineer's station. It has just been completed and > it > > works, but I am yet to put it to serious use. The > code > > is designed to run a separate PC and recieve data > via > > network from the FDM and the plots are > configurable > > via xml. Offline plots have zoom facility, scales > (x/y > >... > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 10 Mar 2002 04:21, you wrote: > ... or replaying a finished flight to study it, or watching a > student's progress in external view on a second monitor, or watching > the propeller from inside the airplane. Or looking out the left window and seeing your wing. > More importantly, I think that soon we won't be making the same > distinction between internal and external view -- we might even use > the same 3D model for both. In that case, the same animation code > that spins the propeller can move the yoke, throttle levers, rudder > pedals, etc. (I imagine that needles on gauges will still be done with > rotating textures). I think thats a very good idea. Only having the one model is a much better way than what is done by most sims. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ipxDF2H7v0XOYBIRAq82AJ9o9fC+S7eqijV+rz0LtNpmWI5qGgCgyNeL Nf1o8DDss7bi1+OGkPNROFo= =Bta5 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
David Megginson <[EMAIL PROTECTED]> said: > As far as I can figure out, there are only three situations we need to > deal with in the viewer code: > > 1. Looking away from a known position. > 2. Looking towards a known position from a known distance and >angle(s). > 3. Looking from one known position towards another. > > All of the views can still be managed by the view-manager class (a > proper subsystem), but we should try to remove all hard-coded > dependencies from the rest of the FlightGear codebase. For example, > the scenery code doesn't need to know which view is in use; it only > needs to know where the coordinates and VIEW matrix for the camera. > > Comments? Volunteers? I think that the easiest solution is probably > a clean rewrite, but paying close attention to how Norm used the > matrices and vectors in the original. This sounds interesting. Let me think about it for a bit and come back with sample properties in xml format. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
I have a couple of comments below. At 3/9/02, you wrote: >As far as I can figure out, there are only three situations we need to >deal with in the viewer code: > >1. Looking away from a known position. >2. Looking towards a known position from a known distance and >angle(s). With respect to the chase view (2), three potential options come to mind: 2.1 What you get now w/ the 'v' key, but with one tweak. This view always keeps the horizon horizontal on the screen. When the aircraft is flying straight down what you see is a plan view. When the aircraft is level what you see is a rearview. When the aircraft is doing a Dutch roll, the horizon is still level. All of this is good. Another tweak to this view, however, is where the view is not sort of tied to the body axis directionally. Right now for an aircraft that has a strong adverse yaw (or Dutch roll), the view sways from side to side (w/ horizon level), and this makes it hard to fly w/o getting airsick (for me). It would be better to simply see the aircraft yawing side to side w/ the view not swaying back and forth. So this view would be tied to the aircraft trajectory history. 2.2 A chase view. This would be a view that looks at the viewed aircraft from a following shadow aircraft. The horizon here would move like it does when flying from inside the aircraft. The viewed aircraft in this case would be centered on the screen as it is now w/ the 'v' key. There is no lag w/ the aircraft centered on the screen. 2.3 A chase view, but more realistic. If one were following the viewed aircraft from a chase plane, there would be some lag in the view. In this case, the viewed aircraft would not stay in the center of the screen. It will only be centered when flying steady state, but for, say, a rapid pull-up, the viewed aircraft would move up from the center of the screen. So the chase view is more or less what a human would see w/ binoculars from the following aircraft --- there would be lag. >3. Looking from one known position towards another. For the tower view, having a zoom feature would be really good. In fact, for all cases, it would be handy if the zoom-in/zoom-out increased the distance between the viewer and viewee. >An example of (1) is the view from inside the aircraft; an example of >(2) is a chase view; and an example of (3) is a tower view. The view >manager class should take care of setting up viewers appropriately for >different situations. > >In every case, we want to be able to specify offsets for all six >degrees of freedom. I think that it makes sense to put all of this in >a single, configurable viewer class, rather than having separater >viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that >duplicate most of each-others' code. > >The main required output is the VIEW matrix to pass to ssgSetCamera, >but several parts of FlightGear need vectors and matrices that are >byproducts of calculating VIEW as well (such as the world-up vector); >it would be nice to minimize these dependencies as far as possible. > >All of the views can still be managed by the view-manager class (a >proper subsystem), but we should try to remove all hard-coded >dependencies from the rest of the FlightGear codebase. For example, >the scenery code doesn't need to know which view is in use; it only >needs to know where the coordinates and VIEW matrix for the camera. > >Comments? Volunteers? I think that the easiest solution is probably >a clean rewrite, but paying close attention to how Norm used the >matrices and vectors in the original. > > >All the best, > > >David > >-- >David Megginson >[EMAIL PROTECTED] > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Wolfram Kuss writes:
> IMHO the decision for a 3D cockpit is not a decision for bad
> legibility. Worse than a pure 2D cockpit, hand optimized for the
> resolution, yes, but not bad.
The optimization is the key. FLY! uses a 2D cockpit (at least, FLY! 1
does), and the panel is blurry and hard to read on my 1600x1200 LCD
because it's optimized for 1024x768.
> In a 3D cockpit, this can be chosen via FoV. Actually, when I start a
> plane and click all the things in the cockpit, I reduce FoV a bit
> ("zoom in", "move my nose closer to the panel"). OTOH, when I land, I
> zoom out very much to see the horizon left and right to judge my angle
> etc.
With typical user-level technology, we might end up configuring things
like this: in her left hand, the user holds the joystick or yoke to
control the plane (possibly assisted by rudder pedals); in her right
hand, she holds the mouse to control the view direction and zoom
level. Fancier users can buy things they strap on their heads to
control the view, but my family would laugh at me if I did that (I
don't even have the nerve to buy a yoke).
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rationalizing view
As far as I can figure out, there are only three situations we need to deal with in the viewer code: 1. Looking away from a known position. 2. Looking towards a known position from a known distance and angle(s). 3. Looking from one known position towards another. An example of (1) is the view from inside the aircraft; an example of (2) is a chase view; and an example of (3) is a tower view. The view manager class should take care of setting up viewers appropriately for different situations. In every case, we want to be able to specify offsets for all six degrees of freedom. I think that it makes sense to put all of this in a single, configurable viewer class, rather than having separater viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that duplicate most of each-others' code. The main required output is the VIEW matrix to pass to ssgSetCamera, but several parts of FlightGear need vectors and matrices that are byproducts of calculating VIEW as well (such as the world-up vector); it would be nice to minimize these dependencies as far as possible. All of the views can still be managed by the view-manager class (a proper subsystem), but we should try to remove all hard-coded dependencies from the rest of the FlightGear codebase. For example, the scenery code doesn't need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera. Comments? Volunteers? I think that the easiest solution is probably a clean rewrite, but paying close attention to how Norm used the matrices and vectors in the original. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim wrote:
>Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more
>usable panel because of its inaccurate eye point when in use. Just as the
>panel disappears when you use the mouse scrolling and reappears with a click,
>it'd be easy enough to snap to an operational centered viewpoint.
In 3D, its easy to let the user move the eyepoint.
>It amazes me sometimes that people define "reality" in 3D as being something
>that looks like it was done with a video camera. To me its a more realistic
>experience if the gauge I'm looking at can easily be used
I agree. Strangely enough, just a few days ago I had the same
discussion on a forum and said what you say, legibility is more
important than just good looks. They had smudges on the faces,
different varieties of shadows, aging effects (white -> yellow) etc.
My only fear is - maybe I am missunderstanding - that we will
implement some scheme that was state of the art 5 years ago when
someone started work on a sim that was shipped 2 years later. As long
as we don't close doors to future development by choosing the wrong
scheme or waste time by doing several schemes, I am happy :-).
IMHO the decision for a 3D cockpit is not a decision for bad
legibility. Worse than a pure 2D cockpit, hand optimized for the
resolution, yes, but not bad.
>and is closer to
>what it would be in size and perspective from my eyes sitting in the chair,
>not the camera's little box on the screen.
In a 3D cockpit, this can be chosen via FoV. Actually, when I start a
plane and click all the things in the cockpit, I reduce FoV a bit
("zoom in", "move my nose closer to the panel"). OTOH, when I land, I
zoom out very much to see the horizon left and right to judge my angle
etc.
>Best,
>
>Jim
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
I do not own Fly!, so I can not comment on it. >It also appears that the >perspective is not consistant with the exterior view angle. In some cases it >makes sense to do this so that you can see the panel pretty much straight on >(necessary to read the gauges) and be able to see the runway well. Maybe I am missunderstanding you completely. There are two basic ways that I know you can do a cockpit. 1. Do a 2D bitmap and display it 1:1 on the screen. This was a good way when for example EAW came out years ago and all people had 640 x 480 resolution. Since you display the pixels 1:1, without stretching, (bilinear) filtering etc you can have them very nice looking and legible. You can do anti aliasing and optimize it pixel-by-pixel. There is still a very active EAW community and one of the things they hate most is the fixed 640 x 480 size cockpits. 2. You can do a real 3D cockpit with the gauge faces textured. If you have this, then I see no reason why looking at it in one direction should be better than others. Say a face is 256 x 256. Lets say you have 1280x1024 and the face is 1/7 of the width, so it is 183 pixels on the screen. So, it would not be "optimal", even if you look at it from straight ahead. I do not really see a middle way between these, apart from doing both. You can with much work optimize a 3D panel for exactly one resolution and view direction and switch off filtering for this part of the scene graph and maybe prefilter it offline, for exactly that resolution and viewing angle. The effect is that of a 2D cockpit, only that you have invested more time to reach it. The bad thing is that you would need to do this for every supported resolution. Off course you can do a 2D cockpit besides your 3D one and just map the 3D textures on, but if you do not optimize it for the resolution, I do not really see why it should look much more legible than a true 3D panel. I just looked at a true 3D cockpit and it is legible in 800 x 600, you can easily read the needles and the larger numbers of larger gauges. From 1024 x 768 upwards, it is very nice and only limited by the textures (some unimportant gauges have very low res textures since this sim was done for slow computers). Looking slightly angled at the panel it looks just as good as straight. It is a medium sparsely populated cockpit, so a 747 cockpit needs more resolution. Off course one question you always have to ask yourself is what computer to optimize for. I do not expect that if someone does a nicely working implementation now, someone else will completely reimplement it with another algorithm in say a year just to optimize it for better computers. So, we should IMHO optimize for a computer that is standard in say a year or even two. So, IMHO we can optimize for a resolution of 1280 x 1024. That does not mean you can not read the values of the gauges at smaller res, but maybe not all the smaller numbers etc. BTW, the GeForce 4 that just came out doubled the framerate of one flightsim in high resolutions with AA, so I go on thinking resolution and use of AA will increase in future. >These are in Fly!. And I have to say that the Fly! panels are the ones I like >the best. Compared to which? It is well known the ones in MSFS are badly implemented. >Best, > >Jim Bye bye, Wolfram ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim wrote: >While this is nice to have for some limited purpose, it adds nothing to >the realism of the simulator from the perspective of the person flying the >sim. I think more people use flight sims for fun or entertainment than for serious uses. Including me, although I am a pilot. But lets stop this discussion and agree that whether you find good exteriour 3D models fun is a matter of taste (additional to the serious uses David wrote about). >jj Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim Brennan jjb - writes: > The "photorealistic" instruments in some simulators are good to have, but > (IMHO) not as importaint as proper flight modeling. > > I personally see NO need for the nice views of the airplane, and its > moving parts as seen from other airplanes except if one is flying > formation or shooting at the airplane. ... or replaying a finished flight to study it, or watching a student's progress in external view on a second monitor, or watching the propeller from inside the airplane. More importantly, I think that soon we won't be making the same distinction between internal and external view -- we might even use the same 3D model for both. In that case, the same animation code that spins the propeller can move the yoke, throttle levers, rudder pedals, etc. (I imagine that needles on gauges will still be done with rotating textures). > While this is nice to have for some limited purpose, it adds > nothing to the realism of the simulator from the perspective of the > person flying the sim. No, but it might be useful for the instructor to watch, or for the student during a replay of a failed flight. > These efforts could better be used in improving the flight models, and > the functionality of the sim to interface to other sims and external > programs and more realistic views (such as those for KSJC). It's not a zero-sum game. The people who are good at flight models (Jon, Tony, Andy, etc.) are already spending pretty-much all their time on flight modelling; contributions to other areas from other people aren't taking away from that. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
> > It amazes me sometimes that people define "reality" in 3D as being something > that looks like it was done with a video camera. To me its a more realistic > experience if the gauge I'm looking at can easily be used and is closer to > what it would be in size and perspective from my eyes sitting in the chair, > not the camera's little box on the screen. > Any simulator should have as it primary function SIMULATING as closely as possable the real thing. This applies to both the flight model and the controls and instruments. The fact that most folks only have a single monitor complicates this greatly. The fact that most folks have controls that do not have the proper sizes and forces complictes this. The best way for a simulator (such as FlightGear) to approach this is to give the users the ability to add and interface with such programs at the project magenta instruments, or the "glass cockpit" being worked on by John and others. The ability to open and close additional views for operating controls (such as FLY and PS-1 do) is needed as well, for those who have to rely on a single monitor. The "photorealistic" instruments in some simulators are good to have, but (IMHO) not as importaint as proper flight modeling. I personally see NO need for the nice views of the airplane, and its moving parts as seen from other airplanes except if one is flying formation or shooting at the airplane. While this is nice to have for some limited purpose, it adds nothing to the realism of the simulator from the perspective of the person flying the sim. These efforts could better be used in improving the flight models, and the functionality of the sim to interface to other sims and external programs and more realistic views (such as those for KSJC). jj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Wolfram Kuss <[EMAIL PROTECTED]> said: > I agree, full 3D is the way new sims work and FGFS should have that as > well and not implement now a feature that was state of the art some > years ago. Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more usable panel because of its inaccurate eye point when in use. Just as the panel disappears when you use the mouse scrolling and reappears with a click, it'd be easy enough to snap to an operational centered viewpoint. > There may be small "artistic freedoms" to make things more > legible, for example shadows on gauges that partly and non-uniformly > shadow digits on gauge faces can make it more realistic and pretty, > but harder to read. Also, if in reality there is much space between > gauges, you can increase the size of the gauges. Yes, unfortunately reality occurs in much higer resolution than even the best monitor can deliver. How about when the sun is right in your eyes and you can't see anything, even with sunglasses? It amazes me sometimes that people define "reality" in 3D as being something that looks like it was done with a video camera. To me its a more realistic experience if the gauge I'm looking at can easily be used and is closer to what it would be in size and perspective from my eyes sitting in the chair, not the camera's little box on the screen. > I also love a fully > 3D, fully functional, fully clickable cockpit. But it is a lot of > work, more than exteriour models. Also, an artist can make an > exteriour model without help from a coder. If an aritist does a 3D > cockpit that holds a switch or gauge or whatever that has not been > coded before, he needs the help of a coder. Yeah they are pretty cool, but for me once you've got them figured out (solved the puzzle and repeated it a few times) it's pretty dull. When I first got Fly! a couple years ago I used it a lot for a few months. Now I just dig it out when I'm interested in how the developers might have done something. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
> Hi, > I have a stand-alone real-time and off-line plotting > tool written in C/C++ (tested in Cygwin/WinNT/Win2K & > Linux) that is meant to be used as a flight test > engineer's station. [...] That does sound useful. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon > I have a stand-alone real-time and off-line plotting > tool written in C/C++ (tested in Cygwin/WinNT/Win2K & > Linux) that is meant to be used as a flight test > engineer's station. It has just been completed and it > works, but I am yet to put it to serious use. The code > is designed to run a separate PC and recieve data via > network from the FDM and the plots are configurable > via xml. Offline plots have zoom facility, scales (x/y >... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
I agree, full 3D is the way new sims work and FGFS should have that as well and not implement now a feature that was state of the art some years ago. It is easy to make the yoke optional. While modelling the cockpit I would strive for realism and then let FGFS disable it if the user wants. There may be small "artistic freedoms" to make things more legible, for example shadows on gauges that partly and non-uniformly shadow digits on gauge faces can make it more realistic and pretty, but harder to read. Also, if in reality there is much space between gauges, you can increase the size of the gauges. I also love a fully 3D, fully functional, fully clickable cockpit. But it is a lot of work, more than exteriour models. Also, an artist can make an exteriour model without help from a coder. If an aritist does a 3D cockpit that holds a switch or gauge or whatever that has not been coded before, he needs the help of a coder. It should off course be possible to change the view direction. I have heard (IIRC from warbirds or Aces High users) that a very nice effect is if the eyepoint moves at the same time. If you sit and look in another direction, turning your head, the eyes move since you will probably hold your neck fairly constant. Also, it should be possible to move the eyepoint via keys so that you can look around things. This may go so far that you can open the canopy and stick your head out to look besides the large obstructing engine. If this is realistic (this technique is used for some planes in RL), then users appreciate this effect a lot. Also, g forces should move the eyepoint as an option (some people like me like this, some don't). AFAIK, this is already in the code. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.33,1.34
Bernie Bright wrote:
> "Curtis L. Olson" wrote:
>
>>Update of /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit
>>In directory seneca:/tmp/cvs-serv20681
>>
>>Modified Files:
>>panel_io.cxx
>>Log Message:
>>Sgi doesn't define the != operator for string != char[] so we need to cast
>>the char array into a (string) type before doing the comparison.
>>! if (mbgTexture != (string)"") {
>
> A better test for non-empty strings is
>
> if (!mbgTexture.empty())
>
> This is portable and faster than a string compare.
There are a lot (and I mean a lot) of places where a string comparrison
is made (either == "" or != ""). It might be a good thing to change that
then?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with sounds...
Jim Wilson wrote: > Found the problem and here's the fix. Type "once" sounds were never getting > stopped. > > Description of patch: > Minor patch. Basically just moved a line of code that was causing a check for > when sound should be stopped to be skipped. Now type "once" sounds get > stopped when they should. Which means they'll now play when needed a second time. Yep, that's correct. In an attempt to get out of the update() function as quick as possible I've changed this in a previous patch, but a patch I sent to David this week already corrected that. I'm still in the middle of implementing a bunch of other stuff to have more controll over the starting/stopping of the sounds using the XML configuration, so there are some things which should be addressed in the near future (rumble only plays when the nose gear touches the ground for instance). Thanks anyway Jim. > This file contains a patched fg_sounds.cxx file: > http://www.spiderbark.com/fgfs/fg_sound-patch-20020309.tar.gz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
