Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Sat, 2003-02-08 at 19:53, Curtis L. Olson wrote: > I agree with Michael though that whatever we do with respect to > providing motion queues through the visual system should be user > selectable. Any time your eyes (visuals) disagree with your butt eh, hemm. Inner ear. > (motion) you risk getting the user sick. Some people are a lot more > sensitive to this than others. People who suffer migrains seem to > suffer more simulation sickness and being an older male seems to also > be a risk factor. > > Regards, > > Curt. > > > David Culp writes: > > Just to add my two cents, the eyepoint motion sounds like an interesting way > > to add some cues to make up for the cues missing in a motionless sim. Only > > small movement in the x and y planes would suffice to provide the cues. > > There is some movement in the z axis, mainly from the springiness of the soft > > seat cushion. There is also the "bouncing eyeball" effect, which is most > > noticable at night (I suppose in the daytime the brain can more easily smooth > > the effect of step inputs). This effect can be demonstrated by going into a > > very dark room and staring at an LED display while eating something crunchy, > > like an apple. (If someone asks, tell him you're doing a scientific > > experiment). This can really increase the difficulty of nighttime instrument > > flying. > > > > There are two other cues that are helpfull. One is pre-stall buffet. For > > instance, the T-38 flies the entire base turn in pre-stall buffet. One reads > > the visual, tactile and audio severity of the buffet to estimate the angle of > > attack. The initial "tickle" is low-amplitude and periodic, about 10 hz, > > give or take. It progresses with increasing AOA to "elephant", high > > amplitude and about 4 hz. The buffet can be applied to almost any airplane at > > some point in its AOA range. It can also model mach buffet or severe > > engine/prop vibration. > > > > Another cue, like someone else mentioned, is the grey/black/red-out effect. > > It is nearly impossible to do a proper loop in the T-38 without this cue > > (unless you have a very prominent g-meter installed). I'd recommend a > > graying of the entire screen starting at about 3 g's and increasing linearly > > to black at 6 g's (without g-suit) or 8 g's (with g-suit) or 9 g's (f-16). > > This is important in acrobatic and fighter airplanes because much of the > > basic maneuvering is done at the 3 to 4 g level, with eyes outside. (The > > audio level diminishes at the same rate.) > > > > A really accurate blackout (as modeled in AW3, a great sim) will last about 2 > > or 3 seconds, and the return to normal senses will occur gradually, say three > > seconds. In a *really* accurate sim, which I haven't seen yet, the return to > > normal senses will be accompanied by "seeing stars" during that time. > > > > Dave Culp > > > > ___ > > 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
[Flightgear-devel] cygwin problems linking fgfs.exe
I thought I successfully compiled and installed SimGear-0.3.1. However, whem making FlightGear-0.9.1 under cygwin (xwindows was removed), I get this message: Making all in Main make[2]: Entering directory `/home/annunzio/FlightGear-0.9.1/src/Main' g++ -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 -L/usr/local/lib -o fgfs.e xe main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAi rcraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Coc kpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/li bControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../s rc/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/F DM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/ LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI .a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../ ../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScen ery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Netw ork/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjec ts.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environme nt/libEnvironment.a -lsgroute -lsgsky -lsgclouds3d -lsgephem -lsgtiming -lsgio - lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lop engl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinm m -lm Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _glPushAttrib by linking to _glPushAttrib@4 Warning: resolving _glDisable by linking to _glDisable@4 Warning: resolving _glBlendFunc by linking to _glBlendFunc@8 Warning: resolving _glLoadMatrixf by linking to _glLoadMatrixf@4 Warning: resolving _glMatrixMode by linking to _glMatrixMode@4 Warning: resolving _glLoadIdentity by linking to _glLoadIdentity@0 Warning: resolving _glColor3f by linking to _glColor3f@12 Warning: resolving _glPopMatrix by linking to _glPopMatrix@0 Warning: resolving _glClear by linking to _glClear@4 Warning: resolving _glClearColor by linking to _glClearColor@16 Warning: resolving _glOrtho by linking to _glOrtho@48 Warning: resolving _glPushMatrix by linking to _glPushMatrix@0 Warning: resolving _glViewport by linking to _glViewport@16 Warning: resolving _glGetIntegerv by linking to _glGetIntegerv@8 Warning: resolving _glEnd by linking to _glEnd@0 Warning: resolving _glBegin by linking to _glBegin@4 Warning: resolving _glVertex3fv by linking to _glVertex3fv@4 Warning: resolving _glTexCoord2f by linking to _glTexCoord2f@8 Warning: resolving _glColor4fv by linking to _glColor4fv@4 Warning: resolving _glTexEnvf by linking to _glTexEnvf@12 Warning: resolving _glAlphaFunc by linking to _glAlphaFunc@8 Warning: resolving _glFogfv by linking to _glFogfv@8 Warning: resolving _glFogf by linking to _glFogf@8 Warning: resolving _glColorMaterial by linking to _glColorMaterial@8 Warning: resolving _glEnable by linking to _glEnable@4 Warning: resolving _glMaterialf by linking to _glMaterialf@12 Warning: resolving _glMaterialfv by linking to _glMaterialfv@12 Warning: resolving _glVertex2f by linking to _glVertex2f@8 Warning: resolving _glColor4f by linking to _glColor4f@16 Warning: resolving _gluOrtho2D by linking to _gluOrtho2D@32 Warning: resolving _glTexImage2D by linking to _glTexImage2D@36 Warning: resolving _glTexParameterf by linking to _glTexParameterf@12 Warning: resolving _glBindTexture by linking to _glBindTexture@8 Warning: resolving _glGenTextures by linking to _glGenTextures@8 Warning: resolving _glDeleteTextures by linking to _glDeleteTextures@8 Warning: resolving _glutGet by linking to _glutGet@4 Warning: resolving _glLightf by linking to _glLightf@12 Warning: resolving _glLightfv by linking to _glLightfv@12 Warning: resolving _glPolygonMode by linking to _glPolygonMode@8 Warning: resolving _glMultMatrixf by linking to _glMultMatrixf@4 Warning: resolving _glTranslatef by linking to _glTranslatef@12 Warning: resolving _glLineWidth by linking to _glLineWidth@4 Warning: resolving _glTexParameteri by linking to _glTexParameteri@12 Warning: resolving _glGetString by linking to _glGetString@4 Warning: resolving _glPixelStorei by linking to _glPixelStorei@8 /usr/local/lib/libsgclouds3d.a(SkyCloud.o)(.text+0x19c8): In function `_ZN8SkyCl oud10IlluminateEP8SkyLightP21SkyRenderableInstanceb': /home/annunzio/SimGear-0.3.1/simgear/sky/clouds3d/SkyCloud.cpp:469: undefined re ference to `_glGetDoublev' /usr/local/lib/libsgclouds3d.a(SkyCloud.o)(.text+0x19de):/home/annunzio/SimGear- 0.3.1/simgear/sky/clouds3d/SkyCloud
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
I agree with Michael though that whatever we do with respect to providing motion queues through the visual system should be user selectable. Any time your eyes (visuals) disagree with your butt (motion) you risk getting the user sick. Some people are a lot more sensitive to this than others. People who suffer migrains seem to suffer more simulation sickness and being an older male seems to also be a risk factor. Regards, Curt. David Culp writes: > Just to add my two cents, the eyepoint motion sounds like an interesting way > to add some cues to make up for the cues missing in a motionless sim. Only > small movement in the x and y planes would suffice to provide the cues. > There is some movement in the z axis, mainly from the springiness of the soft > seat cushion. There is also the "bouncing eyeball" effect, which is most > noticable at night (I suppose in the daytime the brain can more easily smooth > the effect of step inputs). This effect can be demonstrated by going into a > very dark room and staring at an LED display while eating something crunchy, > like an apple. (If someone asks, tell him you're doing a scientific > experiment). This can really increase the difficulty of nighttime instrument > flying. > > There are two other cues that are helpfull. One is pre-stall buffet. For > instance, the T-38 flies the entire base turn in pre-stall buffet. One reads > the visual, tactile and audio severity of the buffet to estimate the angle of > attack. The initial "tickle" is low-amplitude and periodic, about 10 hz, > give or take. It progresses with increasing AOA to "elephant", high > amplitude and about 4 hz. The buffet can be applied to almost any airplane at > some point in its AOA range. It can also model mach buffet or severe > engine/prop vibration. > > Another cue, like someone else mentioned, is the grey/black/red-out effect. > It is nearly impossible to do a proper loop in the T-38 without this cue > (unless you have a very prominent g-meter installed). I'd recommend a > graying of the entire screen starting at about 3 g's and increasing linearly > to black at 6 g's (without g-suit) or 8 g's (with g-suit) or 9 g's (f-16). > This is important in acrobatic and fighter airplanes because much of the > basic maneuvering is done at the 3 to 4 g level, with eyes outside. (The > audio level diminishes at the same rate.) > > A really accurate blackout (as modeled in AW3, a great sim) will last about 2 > or 3 seconds, and the return to normal senses will occur gradually, say three > seconds. In a *really* accurate sim, which I haven't seen yet, the return to > normal senses will be accompanied by "seeing stars" during that time. > > Dave Culp > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] 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] Question about METAR updates
Is it possible to use a metar file to give flightgear the current weather conditions for the world. Are there special setup or options required to set this up? Are there any mac os x compatible apps (java probably ok, too) to download metar info periodically (from http://weather.noaa.gov/weather/metar.shtml ) so that flightgear can (possibly) use it? Thanks, Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] James/Darrell: plib macos x 10.2 -- SL and JS
James, Sorry, your PLIB JS fixes are working great. I also had the -framework problems, but forget I'd updated the makefile to fix them so a new config.ac would be nice eventually but I so far am remembering to update things. I also needed to make the changes for flightgear (fgfs and js_demo/fgjs makefile). Darrell, while the new PLIB with JS fixes is working great, sound is breaking up with the cvs SL. I take it that I still need to run with your SL code from your mac x build kit. I seem to have accidentally erased your sl.tar.gz changes for macos x. Is there someplace to get them separately, or should I download your macos x build changes file again? Are there any plib sl changes recently that might have hit your sl code? thanks to both of you for great work! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] switching views (trivial)
Jim Wilson wrote: Hi Geoff, I've got several changes and fixes to the viewer code, one of which changes the view manager to allow what you are describing. It is actually a little more flexible than just reversing, you can select the view through a property. This allows going forward, backward and directly to any specific view without using a special command. It's been done for a couple weeks now. I'll try and get it together and submit the changes in the next day or two. Best, Jim Got the best of both worlds now :) v forward cycle shift-v reverse cycle control-v return to view 0 Cheers, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Viewer suggestion: acceleration effects
Just to add my two cents, the eyepoint motion sounds like an interesting way to add some cues to make up for the cues missing in a motionless sim. Only small movement in the x and y planes would suffice to provide the cues. There is some movement in the z axis, mainly from the springiness of the soft seat cushion. There is also the "bouncing eyeball" effect, which is most noticable at night (I suppose in the daytime the brain can more easily smooth the effect of step inputs). This effect can be demonstrated by going into a very dark room and staring at an LED display while eating something crunchy, like an apple. (If someone asks, tell him you're doing a scientific experiment). This can really increase the difficulty of nighttime instrument flying. There are two other cues that are helpfull. One is pre-stall buffet. For instance, the T-38 flies the entire base turn in pre-stall buffet. One reads the visual, tactile and audio severity of the buffet to estimate the angle of attack. The initial "tickle" is low-amplitude and periodic, about 10 hz, give or take. It progresses with increasing AOA to "elephant", high amplitude and about 4 hz. The buffet can be applied to almost any airplane at some point in its AOA range. It can also model mach buffet or severe engine/prop vibration. Another cue, like someone else mentioned, is the grey/black/red-out effect. It is nearly impossible to do a proper loop in the T-38 without this cue (unless you have a very prominent g-meter installed). I'd recommend a graying of the entire screen starting at about 3 g's and increasing linearly to black at 6 g's (without g-suit) or 8 g's (with g-suit) or 9 g's (f-16). This is important in acrobatic and fighter airplanes because much of the basic maneuvering is done at the 3 to 4 g level, with eyes outside. (The audio level diminishes at the same rate.) A really accurate blackout (as modeled in AW3, a great sim) will last about 2 or 3 seconds, and the return to normal senses will occur gradually, say three seconds. In a *really* accurate sim, which I haven't seen yet, the return to normal senses will be accompanied by "seeing stars" during that time. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
Paul Morriss <[EMAIL PROTECTED]> said: > Hi all, >I am new to Flight Gear, but not to flight > simulation, thats my line of business ;) Anyway I > would like to propose (and develop) a server or system > that can be used to manage the environment. What I > mean is that the scenario system manages: > > * Other plans in the air, these can add the reality > of busy airspace near large airports. > > * Weather system controlled through scenarios, this > would include clouds, rain etc... > > * Ground vehicles movement (aircraft ready to taxi > for takeoff etc. > Sounds great. Actually I was recently thinking that this might be the best way to do traffic. You should be able build a property tree under /sim/traffic (or whereever) with multiple entries for the "position" and "orientation". See the current /position and /orientation property paths for example. The setup xml configuration files for the models you want to include, specifing the paths to the property for each position and orientation data item (e.g. latitude-deg-prop, longitude-deg-prop, altitude-ft-prop, etc). Then all that is left is to set the position and orientation values via the network interface and the models will move accordingly. Of course the work will be in developing whatever technique you want to use to move these around. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)
On Saturday, February 8, 2003, at 03:23 am, Jonathan Polley wrote: Hmm, that's odd. Out of the box, the version of the Mac joystick code that is in CVS does not compile. As I reported to the plib group, if I incorporate the non-CVS versions of jsMacOSX.cxx and js.h, I get the following errors in the FlightGear joystick code: ld: Undefined symbols: jsJoystick::read(int*, float*) _CFArrayApplyFunction _kCFAllocatorDefault I've been trying to help David Drum get his FlightGear to build and he discovered that adding -framework Carbon to the Makefile reduces the link errors down to ld: /Users/david/FlightGear/FlightGear-CVS/lib/libplibjs.a(jsMacOSX.o) illegal reference to symbol: _IOCreatePlugInInterfaceForService defined in indirectly referenced dynamic library /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit Sorry, I thought I'd covered this : you need to add '-framework IOKit -framework CoreFoundation' to configure.ac, around link 168. I've attached my version of configure.ac, let me know if you have any other problems. H&H James configure.ac Description: Binary data -- The lack of planning on your part does not constitute to an emergency on mine
