Re: [Flightgear-devel] forwarded message from Mike Marhoefer
On 4 Mar 2002, at 15:54, Curtis L. Olson wrote: Can anyone confirm or deny this? My virus checker (F-Secure) say's its clear, and the md5 sum is the same as the one in the original tar.gz file that I downloaded from Cygwin. I would be extremely surprised if it really is infected. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] view code. was Virtual Cockpit!
Martin Dressler writes: Thera are a lot of strange things in view code. It is initialized here and there. There is also problem with lat,lon positions. The code is too oriented towards FDM position not to viewer position. It's not problem with current view modes, but it could be problem with tower (or ground :) view. I agree -- it's a pretty serious mess (but it was useful having it up to now). I'm also planning to do some work on the view code, so let's make sure we don't end up duplicating each-others' work -- send in your changes frequently rather than saving them all up, and I'll do the same. Instead of rewriting from scratch, I'm thinking of trying to reorganize what we have first. Norm Vine did some of the work on the view code, and he knows an awful lot more than I do about how to write and optimize all the matrix and coordinate transforms. sim views view typepilot/type /view view typechase/type default radius-m25/radius-m /default /view view typechase/type default radius-m100/radius-m /default /view view typeground/type default left-m5/left-m before-m3/before-m agl-m2/agl-m /default /view /views /sim That looks good -- a single, configurable view manager would be better than a few ad-hoc, hard-coded ones. You'll need to be able to specify a few more parameters (i.e. draw the 3D model, look towards the plane, reverse view direction [for external], etc.). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fwd: Scenery generation from VPF
From: Roman Grigoriev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Scenery generation from VPF Date: Tue, 5 Mar 2002 13:42:04 +0300 Hi guys! I try to create scenery from VPF have latest terragear from CVS and got this error Could you please point me what should I fix? ./fgfs-construct --min-angle=0.05 --output-dir=/home/vpf/scen --work-dir=/ho me/vpf --lat=43 --lon=43 --xdist=1 --ydist=1 /home/vpf/dem-3 /home/vpf/GSHHS-LandMass /home/vpf/AirportArea /home/vpf/AirportObj /home/vpf/grass /home/vpf/Cities /home/vpf/Snow /home/vpf/Crops Triangulation with options = pczq0.05Aen Constructing Delaunay triangulation by divide-and-conquer method. Delaunay milliseconds: 1 Inserting segments into Delaunay triangulation. Segment milliseconds: 0 Removing unwanted triangles. Spreading regional attributes. Hole milliseconds: 0 Adding Steiner points to enforce quality. Error: Ran out of precision at (42.25, 42.1667962613). I attempted to split a segment to a smaller size than can be accommodated by the finite precision of floating point arithmetic. Try increasing the area criterion and/or reducing the minimum allowable angle so that tiny triangles are not created. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
David,
This is going to mess up rendering of distant mountains for people
with voodoo cards (i.e. 16 bit buffers).
Depth buffer precision is *very* sensitive to the near clip plane
distance:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
I'm really nervous about forcing this down to 0.1 for all cases. This
will mess things up for people with voodoo cards.
Can we change this back?
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that portion of the rendering.
Thanks,
Curt.
David Megginson writes:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
In directory seneca:/tmp/cvs-serv24655
Modified Files:
main.cxx
Log Message:
Changed the near clip plane to 0.1f regardless. Previously, it jumped
to 10m after takeoff, but that doesn't really make sense any more,
especially if models are going to have interior views. Is there any
real saving in pushing the near plane out anyway?
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Main/main.cxx,v
retrieving revision 1.245
retrieving revision 1.246
diff -C2 -r1.245 -r1.246
*** main.cxx 3 Mar 2002 22:20:55 - 1.245
--- main.cxx 5 Mar 2002 12:35:48 - 1.246
***
*** 662,673
globals-get_current_view()-get_v_fov() );
! double agl = current_aircraft.fdm_state-get_Altitude() * SG_FEET_TO_METER
! - scenery.get_cur_elev();
!
! if ( agl 10.0 ) {
! ssgSetNearFar( 10.0f, 12.0f );
! } else {
! ssgSetNearFar( 0.5f, 12.0f );
! }
current_model.update(0); // FIXME: use real delta time
--- 662,666
globals-get_current_view()-get_v_fov() );
! ssgSetNearFar( 0.1f, 12.0f );
current_model.update(0); // FIXME: use real delta time
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
--
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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
David Megginson writes: Changed the near clip plane to 0.1f regardless. Previously, it jumped to 10m after takeoff, but that doesn't really make sense any more, especially if models are going to have interior views. Is there any real saving in pushing the near plane out anyway? Putting the clip plane at 0.1 is an easy way to stop me doing demos of FGFS. I don't _have_ a machine with better than 16 bit depth buffering, and the notebook that I do most of the demos with cannot of course be upgraded. You could use a rule that detects when (a) outside view is on or (b) ground proximity is closer then 50m and move the clip plane appropriately. For the former, people are looking at the model a lot more than the scenery and for the latter you're in ground haze in any case. It would be handy to detect the near clip plane being moved in conjunction with a 16 bit card, and move the far clip plane to follow, with the fog (visibility) being forced to reduce by a corresponding amount to hide the shift. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
On 5 Mar 2002, at 8:40, Curtis L. Olson wrote: David, This is going to mess up rendering of distant mountains for people with voodoo cards (i.e. 16 bit buffers). And not just 16 bit cards - I get flashing polygons in the sky with two different 32 bit cards at 0.5, progressively cured by pushing out to 1.2ish, although no-one else seems to be afflicted by this. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Alex Perry writes: and for the latter you're in ground haze in any case. You Californians speak for yourselves! :-) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] view code. was Virtual Cockpit!
Hey people, Right, been a lurker for long enough and though I'd contribute to the tide of email into your inboxes. I still need to actually get flight gear to build on MSVC but once that is done will be able to invest a bit of time into flightgear. So... the question is... where to start? I'm tempted to try reorganising the start-up code in main to get the FDM interface into a more modular (Init / Bind / Update) pattern, ideally I'd like to get it separated enough that I can start up flightgear fdm-less and choose a plane / fdm from a menu / dialog box... that's my longish term goal anyway. Anyway, the reason this is replied to under the view thread is that I was thinking about the view code for a bit and thought that before you guys started working on implementing a configurable system, it might be worth considering the kinda things we'd want from it - for instance I think that any ground view should at least have the option of: view typeground/type max-distance-m1/max-distance-m //max distance from fdm before switch out or 0 for none start-up position left-m5/left-m before-m3/before-m agl-m2/agl-m fixedno/fixed /position rotation-deg130/rotation-deg pitch-deg130/pitch-deg zoom80%/zoom autos zoomon/zoom rotationoff/rotation pitchon/pitch /autos /start-up persistRotationPosition/persist //controls what if any settings are saved between view switches... //otherwise use startup settings rotation displayyes/display enabledyes/enabled autorotate enabledyes/enabled max speed-rad/spi/4/maxSpeed-rad/s /autorotate leftstop-rad0/leftstop rightstop-radpi/rightstop loopyes/loop /rotation pitch displayyes/display enabledyes/enabled autopitch enabledyes/enabled max speed-deg/s15/maxSpeed-rad/s /autopitch topstop-deg80/topstop bottomstop-deg-15/bottomstop /pitch zoom displayyes/display enabledyes/enabled autozoom enabledyes/enabled max speed-m/s100/max speed-m/s /autozoom upper-limit2000/upper-limit lower-limit100/lower-limit /zoom /view you could also associate sound effects with rotation / pitch / zoom and different ones for reaching limits. Finally, what would be great is if we could associate a ssg node (with special case for 2D things like panel) to each view that would let them have something displayed right in front of them (eg. A car model for someone parked at end of a runway, a vitual cockpit, etc. If we could specify individual ssg nodes for rotation with view (i.e. pilots glasses for pilot view... gun turret for gun view), pitch and zoom that would be even better... Anyway, just some ideas... will leave the view code alone for the minute so you guys can work on it. Alex Wolff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] solaris compile failure of simgear
I get errors like so: make all-recursive Making all in xml make[2]: Nothing to be done for `all'. Making all in debug make[2]: Nothing to be done for `all'. Making all in misc c++ -g -O2 -D_REENTRANT -L/folks/salman/bin/lib -L/usr/local/lib -o props_test props_test.o libsgmisc.a ../xml/libsgxml.a ../debug/libsgdebug.a -lm Undefined first referenced symbol in file __eh_pc /usr/local/lib/libstdc++.a(stdexcepti.o) ld: fatal: Symbol referencing errors. No output written to props_test collect2: ld returned 1 exit status make[2]: *** [props_test] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 What is going on? I have gcc 2.95.3 on my solaris box. Salman -- Salman Sheikh NASA/GSFC Code 564 Greenbelt, MD 20771 301-286-3763 301-286-0220 (fax) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Curtis L. Olson wrote: I'm really nervous about forcing this down to 0.1 for all cases. This will mess things up for people with voodoo cards. Can we change this back? Perhaps we need to do a separate pass for rendering the 3d model and change the near clip plane just for that portion of the rendering. I'm with Curt. Coming up with a single Z range for mountains and gauges isn't likely to work well. A better idea would be to investigate glDepthRange() to isolate the two regimes (this trades ~1 bit in depth buffer precision and allows you two or more completely separated clip plane sets). Or just turn the depth buffer off for the cockpit and sort the geometry; for most cockpit layouts, this should be pretty feasible. It won't work if the cockpit has moving parts (yokes or whatnot) that obscure other pieces. Or just eat the cost and clear the depth buffer between the scenery and aircraft/cockpit. On modern hardware, it's actually not that expensive. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Solaris compile error
Hello All, Got past the first error. Got a new one: Making all in NetworkOLK c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/folks/salman/bin/include -I/usr/local/include -g -O2 -c net_send.cxx net_send.cxx: In function `void fgd_init()': net_send.cxx:277: `INADDR_NONE' undeclared (first use this function) net_send.cxx:277: (Each undeclared identifier is reported only once net_send.cxx:277: for each function it appears in.) make[1]: *** [net_send.o] Error 1 make: *** [all-recursive] Error 1 Any ideas anyone? Salman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Curt wrote: Perhaps we need to do a separate pass for rendering the 3d model and change the near clip plane just for that portion of the rendering. Yes. That should be easy to do. BoB does it as well, they even have 3 or 4 different parts of the geometry that they render with 3 or 4 different near values. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery Strangeness
Gents, With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the textures in mountainous areas seem to walk across the ground and appear and disappear in a very strange manner. I am wondering if anyone else sees this problem. To demonstrate this problem I used the following .fgfsrc: --fdm=magic --disable-clouds --disable-panel --disable-sound --geometry=1024x768 --in-air --lat=35.88 --lon=-113.7 --altitude=9200 --heading=90.0 --start-date-sys=2002:04:16:17:56:00 After starting FGFS, hit PageUp several times to increase velocity and notice how some textured areas appear and disappear as you go by. Does anyone else see this effect? Thanks, Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
Alex Perry writes: Putting the clip plane at 0.1 is an easy way to stop me doing demos of FGFS. I don't _have_ a machine with better than 16 bit depth buffering, and the notebook that I do most of the demos with cannot of course be upgraded. I understand. How does everything look with the change, before I put it back? 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] Scenery Strangeness
Yes, I think this is due to a very recent change with the near clip plane that is about to be backed out. :-) Curt. Paul Deppe writes: Gents, With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the textures in mountainous areas seem to walk across the ground and appear and disappear in a very strange manner. I am wondering if anyone else sees this problem. To demonstrate this problem I used the following .fgfsrc: --fdm=magic --disable-clouds --disable-panel --disable-sound --geometry=1024x768 --in-air --lat=35.88 --lon=-113.7 --altitude=9200 --heading=90.0 --start-date-sys=2002:04:16:17:56:00 After starting FGFS, hit PageUp several times to increase velocity and notice how some textured areas appear and disappear as you go by. Does anyone else see this effect? Thanks, Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ 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
Re: [Flightgear-devel] Scenery Strangeness
Paul Deppe writes:
Gents,
With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the
textures in mountainous areas seem to walk across the ground and appear
and disappear in a very strange manner. I am wondering if anyone else sees
this problem.
You're almost certainly seeing some of the effects of bringing the
near clip plane right in, which occured in today's CVS. Try backing
out the change below and see if that helps. It will probably get
changed back (or to something else) at some point anyway.
Cheers - Dave
Index: main.cxx
=
==
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Main/main.cxx,v
retrieving revision 1.245
retrieving revision 1.246
diff -C2 -r1.245 -r1.246
*** main.cxx3 Mar 2002 22:20:55 - 1.245
--- main.cxx5 Mar 2002 12:35:48 - 1.246
***
*** 662,673
globals-get_current_view()-get_v_fov() );
! double agl = current_aircraft.fdm_state-get_Altitude() *
SG_FEET_TO_METER
! - scenery.get_cur_elev();
!
! if ( agl 10.0 ) {
! ssgSetNearFar( 10.0f, 12.0f );
! } else {
! ssgSetNearFar( 0.5f, 12.0f );
! }
current_model.update(0); // FIXME: use real delta time
--- 662,666
globals-get_current_view()-get_v_fov() );
! ssgSetNearFar( 0.1f, 12.0f );
current_model.update(0); // FIXME: use real delta time
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Scenery Strangeness
* Paul Deppe -- Tuesday 05 March 2002 21:53: With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the textures in mountainous areas seem to walk across the ground and appear and disappear in a very strange manner. I am wondering if anyone else sees this problem. Same here. It's a consequence of David's changes from today (see thread CVS: FlightGear/src/Main main.cxx,1.245,1.246) and will probably get reverted soon. :- m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rendering anomalies
Hello, With a NVidia 256 DDR, I get off-color polygons randomly on the surrounding hills of the default (KSFO) startup. Using CVS update of 3/5/02 08:24 EST. No problems noticed yesterday. -- Bill Earnest wde3@ptd-dot-net 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] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Andy Ross writes: Or just turn the depth buffer off for the cockpit and sort the geometry; for most cockpit layouts, this should be pretty feasible. It won't work if the cockpit has moving parts (yokes or whatnot) that obscure other pieces. I don't think this is an easy option, at least not with a true 3D model wrapped around the viewer. We'll have to find a more robust solution. To start, I can make the depth buffer 0.1 only when the interior model view is enabled, so no one loses without it; old hardware probably won't do well with the interior view anyway. 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] Scenery Strangeness
Paul Deppe writes: With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the textures in mountainous areas seem to walk across the ground and appear and disappear in a very strange manner. I am wondering if anyone else sees this problem. Mea culpa -- it's from changing the near clip plane to get 3D interior views working. I'm fixing it now (the problem doesn't show up on newer hardware, like the GeForce2). 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] view code. was Virtual Cockpit!
On Tue, 2002-03-05 at 08:04, Alex Wolff wrote: Hey people, Right, been a lurker for long enough and though I'd contribute to the tide of email into your inboxes. I still need to actually get flight gear to build on MSVC but once that is done will be able to invest a bit of time into flightgear. So... the question is... where to start? I'm tempted to try reorganising the start-up code in main to get the FDM interface into a more modular (Init / Bind / Update) pattern, ideally I'd like to get it separated enough that I can start up flightgear fdm-less and choose a plane / fdm from a menu / dialog box... that's my longish term goal anyway. I don't object to starting FDM-less, but it might be easier if you knew that FDM init doesn't take very long (at least to my observation) and that the reset menu item completely re-initializes it so that might be a good place to start. In other words, go ahead and start with an FDM and, let the user choose a different one (if desired) and internally trigger a reset with the new aircraft and FDM. From a usability point of view, I think it would be better if the user got *something* he could fly by default. Anyway, the reason this is replied to under the view thread is that I was thinking about the view code for a bit and thought that before you guys started working on implementing a configurable system, it might be worth considering the kinda things we'd want from it - for instance I think that any ground view should at least have the option of: view typeground/type max-distance-m1/max-distance-m //max distance from fdm before switch out or 0 for none start-up position left-m5/left-m before-m3/before-m agl-m2/agl-m fixedno/fixed /position rotation-deg130/rotation-deg pitch-deg130/pitch-deg zoom80%/zoom autos zoomon/zoom rotationoff/rotation pitchon/pitch /autos /start-up persistRotationPosition/persist //controls what if any settings are saved between view switches... //otherwise use startup settings rotation displayyes/display enabledyes/enabled autorotate enabledyes/enabled max speed-rad/spi/4/maxSpeed-rad/s /autorotate leftstop-rad0/leftstop rightstop-radpi/rightstop loopyes/loop /rotation pitch displayyes/display enabledyes/enabled autopitch enabledyes/enabled max speed-deg/s15/maxSpeed-rad/s /autopitch topstop-deg80/topstop bottomstop-deg-15/bottomstop /pitch zoom displayyes/display enabledyes/enabled autozoom enabledyes/enabled max speed-m/s100/max speed-m/s /autozoom upper-limit2000/upper-limit lower-limit100/lower-limit /zoom /view you could also associate sound effects with rotation / pitch / zoom and different ones for reaching limits. Finally, what would be great is if we could associate a ssg node (with special case for 2D things like panel) to each view that would let them have something displayed right in front of them (eg. A car model for someone parked at end of a runway, a vitual cockpit, etc. If we could specify individual ssg nodes for rotation with view (i.e. pilots glasses for pilot view... gun turret for gun view), pitch and zoom that would be even better... Anyway, just some ideas... will leave the view code alone for the minute so you guys can work on it. Alex Wolff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
David Megginson [EMAIL PROTECTED] said: I don't think this is an easy option, at least not with a true 3D model wrapped around the viewer. We'll have to find a more robust solution. To start, I can make the depth buffer 0.1 only when the interior model view is enabled, so no one loses without it; old hardware probably won't do well with the interior view anyway. Ummm...why not clear the z-buffer and use a seperate scene graph? Note that there are *lots* of people using pre-geforce generation hardware. Probably more than not. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Curtis L. Olson [EMAIL PROTECTED] said: David, Assuming all of this is being drawn via plib/ssg then you could put all the geometry in a separate ssgRoot node and call ssgCullandDraw() on this root after everything else has been rendered. We have a couple ssgRoot's already so we can have some high level control over sorting geometry ... sky, terrain, lights, cockpit ... Regards, Curt. Please, yes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on TechTV
On Tue, 2002-03-05 at 16:04, Tony Peden wrote: Chris Dibona (sp?) will, according to the teasers, be demoing FG on TechTV's show The Screensavers sometime within the next hour and a half. (4:00-5:30 PST) Well it turned out to be more of a piece on open source gaming in general and they didn't do much more than show the website. They did, however, have good things to say about FG and the exposure was really cool. -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Jim Wilson wrote: Ummm...why not clear the z-buffer and use a seperate scene graph? Note that there are *lots* of people using pre-geforce generation hardware. Probably more than not. Actually, it's those folks who are at risk. Clearing the whole z buffer soaks up big chunks of framebuffer bandwidth, and is a frame rate killer on early hardware. But I agree, it's the simplest and most robust solution. Folks who haven't looked at it before should definitely read the man pages for glDepthRange(). For this situation (the cockpit doesn't need a lot of z precision), it's a good fit. The only worry is that it's a relatively obscure feature and thus more susceptible to driver bugs and incompatibilities. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on TechTV
Is this a cable station? Public access? Something you can only pull in within 200' of the transmitter? Cable. website is http://www.techtv.com/screensavers/ Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on TechTV
Tony Peden [EMAIL PROTECTED] said: Well it turned out to be more of a piece on open source gaming in general and they didn't do much more than show the website. They did, however, have good things to say about FG and the exposure was really cool. Oh well. One of my websites appeared on an ecommerce thing they did on there once, but they didn't even mention what it was...just gave us 1 second of footage. Strangest thing is I don't even get techtv here. Was just sitting in a hotel room in Portland and it came on the screen. It is great that opensource gaming is getting some exposure in the popular press as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
Or just turn the depth buffer off for the cockpit and sort the geometry; for most cockpit layouts, this should be pretty feasible. It won't work if the cockpit has moving parts (yokes or whatnot) that obscure other pieces. Even if they obscure, it is only a problem if they swap places so that there isn't a single unique geometric stack order. Everything I've thought of, so far, has an obvious ordering though. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
David Luff writes: Alex Perry writes: and for the latter you're in ground haze in any case. You Californians speak for yourselves! [EMAIL PROTECTED] Ya see, here the temperature is _above_ freezing and _not_ raining at the same time 8-). I'll take poor visibility over days of drizzle... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] techtv
Looks like we are getting a few techtv visitors to the web site this evening: http://seneca.flightgear.org/webalizer/usage_200203.html Curt. -- 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main main.cxx,1.245,1.246
On Tue, 2002-03-05 at 18:16, Alex Perry wrote: David Luff writes: Alex Perry writes: and for the latter you're in ground haze in any case. You Californians speak for yourselves! [EMAIL PROTECTED] Ya see, here the temperature is _above_ freezing and _not_ raining at the same time 8-). I'll take poor visibility over days of drizzle... Don't move up here, then! (Seattle) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Jim Wilson writes: Ummm...why not clear the z-buffer and use a seperate scene graph? Note that there are *lots* of people using pre-geforce generation hardware. Probably more than not. Time -- I don't know if I'll have time to figure all that out this week. 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] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
Alex, Try doing a make clean inside JSBSim and then rebuild everything. Curt. Alex Perry writes: You likely don't notice any of this if you are running a card with a 32bit depth buffer (i.e. geforce.) Don't worry Curt, leave the change in, I don't see the problem on 16 bit ... Loading tile /usr/local/lib/FlightGear/Scenery/w120n30/w118n32/1023667 ESC[1mESC[4mJSBSim Flight Dynamics Model v0.9.1ESC[24mESC[22m ESC[2m[cfg file spec v1.57] ESC[22mJSBSim startup beginning ... ESC[4mReading Aircraft Configuration FileESC[24m: ESC[1mc172ESC[22m Version: ESC[1m1.57ESC[22m 13971 Segmentation fault 8-) ___ 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
Re: [Flightgear-devel] FlightGear on TechTV
On Tue, 2002-03-05 at 17:20, Curtis L. Olson wrote: Tony Peden writes: Chris Dibona (sp?) will, according to the teasers, be demoing FG on TechTV's show The Screensavers sometime within the next hour and a half. (4:00-5:30 PST) Is this a cable station? Public access? Something you can only pull in within 200' of the transmitter? Cable or satellite. As is probably apparent from their name and website, the focus on computers and other high technology material. Curt. -- 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
You likely don't notice any of this if you are running a card with a 32bit depth buffer (i.e. geforce.) Don't worry Curt, leave the change in, I don't see the problem on 16 bit ... Loading tile /usr/local/lib/FlightGear/Scenery/w120n30/w118n32/1023667 ESC[1mESC[4mJSBSim Flight Dynamics Model v0.9.1ESC[24mESC[22m ESC[2m[cfg file spec v1.57] ESC[22mJSBSim startup beginning ... ESC[4mReading Aircraft Configuration FileESC[24m: ESC[1mc172ESC[22m Version: ESC[1m1.57ESC[22m 13971 Segmentation fault 8-) If this is your idea of a joke, I'm not laughing ... :-) [you *are* joking, aren't you?!?!] Jon -- Jon S. Berndt Coordinator JSBSim Project http://jsbsim.sourceforge.net -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
13971 Segmentation fault [you *are* joking, aren't you?!?!] Err, no. Sorry. Curt suggest I recompile ... in progress ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does anyone have a new FGFS.exe?
I just built yesterday's (March 4, 2002) FlightGear for Win32. You can pull it down from: http://homepage.mac.com/eq_fidget/FileSharing1.html Jonathan p.s. It is 2.6 MB in size and was built with MSVC. On Monday, March 4, 2002, at 01:47 PM, Wolfram Kuss wrote: I need a fairly current windows binary. If I understand David correctly, then I can no longer set the pitch-offset and z-offset via parameters to fgfs, so I have to create a (temporary) XML file. Bye bye, Wolfram. ___ 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] Virtual cockpit update
Here's another batch of virtual cockpit stuff. There is a patch
attached, and the two modified files in full can be found at:
http://www.plausible.org/andy/vc-20020305.tar.gz
Folks who want to try the patch (it's easy, really!) can just get into
their just-updated FlightGear source directory and do:
patch -p0 vc.patch
The virtual cockpit now scrolls correctly using the mouse mechanism.
Really, this is a fix to mouse.cxx to use the standard view
direction mechanism and not to the virtual cockpit per se.
The HUD code transforms properly in virtual cockpit mode. This turned
out not to be so bad at all; the changes largely mirror those to the
panel and don't involve the rendering code. One significant
difference, however, is that the compress-fraction property on the
ladder has changed its meaning. It used to represent pixels per
degree, which was kinda dumb (it didn't correct for changes in the FOV
due to zoom or whatnot), and was essentially unworkable in a virtual
cockpit where pixels lose their meaning. Now, it's a a compression
relative to 1. That is, if set to 1, one degree on the ladder is
one degree in the field of view. If set to 10, ten degrees of ladder
pitch is represented as one degree of FOV. This requires new HUD
ladder files for your base package. Find them here:
http://www.plausible.org/andy/huds-20020305.tar.gz
The virtual HUDs aren't quite there yet, largely for authoring
reasons. The existing HUD descriptions are much (much) larger than a
real hud, and were designed to fill the screen. In particular, the
text in the corners (fps counters, etc...) looks really silly in
virtual cockpit mode. We should come up with smaller, more realistic
ones; typical early generation huds were no more than ten degrees
wide.
Which leads me to a random digression: does anyone have a good
reference on historic HUD symbology? Not MIL-STD documents about
current fighters, nor research papers on what would be cool, but
actual photos and descriptions of the HUDs installed on (just for the
sake of argument) the Harriers and late model A-4's. :)
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
? src/Cockpit/panel.cxx-andy
? tests/test-env-map
Index: src/Cockpit/hud.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/hud.cxx,v
retrieving revision 1.48
diff -u -r1.48 hud.cxx
--- src/Cockpit/hud.cxx 5 Feb 2002 14:57:46 - 1.48
+++ src/Cockpit/hud.cxx 6 Mar 2002 05:54:46 -
@@ -169,6 +169,8 @@
static instr_item * readCard ( const SGPropertyNode * node);
static instr_item * readLabel( const SGPropertyNode * node);
static instr_item * readTBI( const SGPropertyNode * node);
+static void drawHUD();
+static void fgUpdateHUDVirtual();
//$$$ end - added, Neetha, 28 Nov 2k
void fgHUDalphaInit( void );
@@ -308,6 +310,11 @@
nadir = node-getIntValue(nadir); //suma
hat= node-getIntValue(hat);
+// The factor assumes a base of 55 degrees per 640 pixels.
+// Invert to convert the compression factor to a
+// pixels-per-degree number.
+if(factor == 0) factor = 1;
+factor = (640./55.) / factor;
SG_LOG(SG_INPUT, SG_INFO, Done reading instrument name);
@@ -1032,7 +1039,12 @@
// all C++.
//
void fgUpdateHUD( void ) {
-
+
+if(fgGetBool(/sim/virtual-cockpit)) {
+fgUpdateHUDVirtual();
+return;
+}
+
static const float normal_aspect = float(640) / float(480);
// note: aspect_ratio is Y/X
float current_aspect = 1.0f/globals-get_current_view()-get_aspect_ratio();
@@ -1047,9 +1059,78 @@
}
}
+void fgUpdateHUDVirtual()
+{
+FGViewer* view = globals-get_current_view();
+
+// Standard fgfs projection, with essentially meaningless clip
+// planes (we'll map the whole HUD plane to z=-1)
+glMatrixMode(GL_PROJECTION);
+glPushMatrix();
+glLoadIdentity();
+gluPerspective(view-get_v_fov(), 1/view-get_aspect_ratio(), 0.1, 10);
+
+glMatrixMode(GL_MODELVIEW);
+glPushMatrix();
+glLoadIdentity();
+
+// Standard fgfs view direction computation
+float lookat[3];
+lookat[0] = -sin(view-get_view_offset());
+lookat[1] = tan(view-get_view_tilt());
+lookat[2] = -cos(view-get_view_offset());
+if(fabs(lookat[1]) ) lookat[1] = ; // FPU sanity
+gluLookAt(0, 0, 0, lookat[0], lookat[1], lookat[2], 0, 1, 0);
+
+// Map the -1:1 square to a 55.0x41.25 degree wide patch at z=1.
+// This is the default fgfs field of view, which the HUD files are
+// written to assume.
+float dx = 0.52056705; // tan(55/2)
+float dy = dx * 0.75; // assumes 4:3 aspect ratio
+float m[16];
+m[0] = dx; m[4
RE: [Flightgear-devel] Metakit
Duron 1000 MHz Redhat 7.2 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Perry Sent: 06 March 2002 09:15 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Metakit I'm extremely eager to start developing, but I can't because metakit won't compile on my Linux system. Which processor, distribution ? ___ 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
