[Flightgear-devel] RSYNC base package not up-to-date? (Was: 3d Panel problem)
Erik Hofman wrote: Andy Ross wrote: Hrm? I don't think that's possible in the new architecture; the panel renders into the model's scene graph, it doesn't touch the view information anymore. Are you sure you have current code? This sounds like you might be looking at a 2D panel while panning the view -- the 2D panels don't respect the virtual-cockpit property anymore and always render onto the screen, like they used to do. I have removed plib, SimGear, FLightGear and the base package and installed the latest from everything. Still the same problem, but it seems to be the 2D panel (it stays in front of me whatever I do and even zoom doesn't change is shape). I think I've found the problem. I grab the base package using rsync, and that version doesn't seem to be up-to-date. Even the new crop textures aren't included yet. Could someone please take a look at that? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dc3-yasim - observations from a tail-dragger pilot
I have been using FlightGear since 7.7 and have only recently begun to follow the CVS snapshot. I worked my way through college and a flight Instructor and have about 1500 hours in real ac. I also have flown many tail-draggers. I agree with your view of the tail-dragger ac and pilots. I have both the CH Products Flight Sim Yoke and the CH Pro-pedals. I have the joysticks.xml set up so I have differential toe brakes. I can repeatably take off in the dc3-yasim w/o the tail wheel lock and not using (I thought) any brakes. Three observations concerning the dc3-yasim. 1. If the tail wheel is not locked, I find it much easier to take off after removing the coupling of the rudder with the brakes for both main gear from the dc3.xml. I always thought when early-on I had trouble that it felt like I had some brake on durring the take-off roll. Since I am always very active with the rudder to keep the nose straight, I was always getting brake w/o knowing it. 2. It seems to me that the dc3 always leaves the ground before I can raise the tail (even with full down elavator). This is not what a real tail dragger does. That is why you get the sensation in the dc3-yasim of a bouncing wheel landing while accelerating to VMC as soon as the tail comes up. Could it be that the main gear are too far forward, or the affective size of the horizontal stab is too small? 3. In a real tail dragger, once you can raise the tail, the main gear are still on the ground, and the ac quickly accelerates and the rudder becomes very much more affective. So w/o tailwheel lock, one would expect to be very busy on the rudder (always ending any rudder correction with slight oposite rudder to stop any correction moment). As soon as the tail comes up, things get much easier, even in a cross-wind. Hope this helps improve the dc3 model! A good tail dragger is more fun, even in a simulator. Regards, Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3-yasim - observations from a tail-draggerpilot
Dave Perry wrote: 1. If the tail wheel is not locked, I find it much easier to take off after removing the coupling of the rudder with the brakes for both main gear from the dc3.xml. I'd be happy to junk this; David always hated it anyway. It was basically a hack to fix a problem I didn't understand properly anyway. :) 2. It seems to me that the dc3 always leaves the ground before I can raise the tail (even with full down elavator). This is not what a real tail dragger does. This is also really good to know -- if you want to try experimenting, try modifying the tail effectiveness. In the hstab tag, there can be an effectiveness=nnn attribute that multiplies the force generated by that surface. This is basically a guess right now, I find that for many of the jets, a value of 2 or so works well. In general, smaller surfaces generate more force per area, but there's no hard rule (too many other effects get in the way, like airfoil differences and wash effects). I think the DC-3 is still using the default effectiveness of 1, but that's only because it flew adequately when I tried it. I don't have any real world experience to compare against. Let me play with it tonight and see if I can get something that mimicks what you describe. 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] Jitterbug pinpointed
I spent some time over the weekend struggling with the jitterbug (sorry, couldn't resist). I haven't fixed it, but I have pinpointed the issue. In essence: yes, it's a precision problem; but no, Jim's calculations aren't the problem. The problem is actually the organization of the scene graph. Right now, it looks basically like this: Camera (move to terrain origin, orient to terrain/global frame) | +-- Terrain | +-- Transform (bring origin back to near viewpoint, orient to model frame) | +-- Aircraft Model That is, the top-level camera matrix includes a 1000m or so translation to the local tile centroid. This translation thus has to be undone by the aircraft model matrix in order to move the origin back to the region near the viewpoint. But this is exactly the problem -- in 32 bit float precision, two 1000m translations are only accurate to a few millimeters. Not good enough. Even if the number that generated the matrices were perfect, we'd still be seeing the jitter. And the simplest solution -- use doubles -- isn't even an option here because the math is happening inside OpenGL. Consumer graphics cards don't even *have* double precision GPUs. What I'd suggest, which still takes some surgery, is to reorganize the scene graph to remove the double-translation. Something like this, which pushes the tile centroid translation down into the terrain branch, should work well: Camera (orientation only, no position change) | +-- Transform (move to terrain origin) || |+-- Terrain | +-- Transform (move to model origin, orient to model frame) | +-- Aircraft Model I got started trying to figure out how to do this, but got a little lost. Jim, you know this code a lot better than I do, how hard would that be to do? 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] The string class fights back (was: Propertybrowser bugs)
Andy Ross writes: I'm not sure that there's a good answer here. We could consider interning constant strings like property paths into constant references that don't need allocation. But stuff like getStringValue() is always going to have to allocate a new string if we want to do this robustly. Actually, the trick is an old one from my C days that I've used a lot in Java (yes, even Java). Something like this would be 100% robust and still very efficient: char * getStringValue (char * buf, int max_length_) The only problem is that it adds extra work for the caller by forcing her to supply a buffer. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] The string class fights back (was: Property browser bugs)
Norman Vine writes: as far as I am concerned creating an ASCII property path is a waste of time and should not be used anywhere inside the 'main loop'. Inside the main loop, it's used only for things like interactive display in the property browser or through a network interface. It's getStringValue where the slowdowns happen (we were talking about that at the same time). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Panel problem
Erik Hofman writes: Well, I know that (for instance) mustang pilots had to land side-slipping, and taxi zig-zagging to get an eye on the runway. Forward slipping, probably (since that would have the plane's axis at an angle to the runway, while a side slip would have it lined up). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RSYNC base package not up-to-date? (Was: 3dPanel problem)
On Monday 01 July 2002 11:53 am, Alex Perry wrote: I think I've found the problem. I grab the base package using rsync, and that version doesn't seem to be up-to-date. Even the new crop textures aren't included yet. It's on my machine, but John Check had a cron job that pushd-updated it. John, could you see what the script does and let me know if I need to help ? Was thinking maybe he got caught in the lag. I really should have it run post checkin from cvs. Anyway lemme look and see ___ 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] RSYNC base package not up-to-date? (Was: 3dPanel problem)
On Monday 01 July 2002 6:14 pm, John Check wrote: On Monday 01 July 2002 11:53 am, Alex Perry wrote: I think I've found the problem. I grab the base package using rsync, and that version doesn't seem to be up-to-date. Even the new crop textures aren't included yet. It's on my machine, but John Check had a cron job that pushd-updated it. John, could you see what the script does and let me know if I need to help ? Was thinking maybe he got caught in the lag. I really should have it run post checkin from cvs. Anyway lemme look and see Alex, I'm getting: The authenticity of host 'scenery.flightgear.org (207.212.80.150)' can't be established. when ssh is called. I'll run the script manually to sync up, but I'll refrain from fixing it till I hear back from you. FWIW I suppress email from this particular job, so I don't know when this became a problem. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
I now have a practical solution for saving the compiler warnings: a wrapper script
replacement for the compiler.
rm config.cache # Otherwise it keeps the previous values of CC and CXX.
GCCFLAGS=-Wall -pedantic -Wpointer-arith
CC=saveoutp gcc CXX=saveoutp c++ CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS
./configure
where ~/bin/saveoutp contains:
#!/bin/bash
# Run a program, also capturing stderr to a file.
#
# Usage: saveoutp program option... filename
#
# Treat the argument list as a shell command. Run the command, displaying
# stderr but also capturing it into a file named .deps/filename.err.
# (Bug: the command's exit status is reduced to just true or false.)
if [ -d .deps ] ; then
# Make name of error file from last positional argument.
ERRFILE=.deps/${!#}.err
# Execute program; save stderr; display stderr; return true/false exit code.
{ $* 2 $ERRFILE cat $ERRFILE 2; } || { cat $ERRFILE 2; false; }
else
$*
fi
This wrapper script is specific to Bash, but it would be possible to write one for any
shell that can redirect stderr, or even write a compiled program.
Then you will always have the last warnings available for each C file and can run
(e.g.)
cat src/*/.deps/*.err
to see them.
[
My previous attempt was no good. I wrote:
2. Save the error output for each C file as (e.g.) .deps/*.err. E.g. in each
Makefile.in:
...
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
...
But if the compilation fails, 'make' will quit before displaying the error output
file. That's no good. It needs to be done within a single command. What I really
need is one of these:
gcc 2| tee file.err# No: stderr-pipe not available AFAIK, and exit
status is lost.
gcc 2 file.err 2 /dev/con# No: in Bash the first output file has nothing
written to it.
gcc 2(tee file.err) # No, though Bash can _almost_ do this on _some_
systems.
gcc 2 file.err || { cat file.err; false; } # This might just about work!
... but I don't know if I can get automake to put stuff like this in the generated
make files.
]
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
Along the lines of adding the -pedantic option, I would like to add an
ability (probably at ./configure time) to specify additional compile
options. Since one of my platforms is a Mac, I would like to be able to
add -wno_long_double, as it keeps telling me that their size is
non-portable.
Thanks,
Jonathan Polley
On Monday, July 1, 2002, at 05:43 PM, Julian Foad wrote:
I now have a practical solution for saving the compiler warnings: a
wrapper script replacement for the compiler.
rm config.cache # Otherwise it keeps the previous values of CC and CXX.
GCCFLAGS=-Wall -pedantic -Wpointer-arith
CC=saveoutp gcc CXX=saveoutp c++ CFLAGS=$GCCFLAGS
CXXFLAGS=$GCCFLAGS ./configure
where ~/bin/saveoutp contains:
#!/bin/bash
# Run a program, also capturing stderr to a file.
#
# Usage: saveoutp program option... filename
#
# Treat the argument list as a shell command. Run the command,
displaying
# stderr but also capturing it into a file named .deps/filename.err
.
# (Bug: the command's exit status is reduced to just true or false.)
if [ -d .deps ] ; then
# Make name of error file from last positional argument.
ERRFILE=.deps/${!#}.err
# Execute program; save stderr; display stderr; return true/false
exit code.
{ $* 2 $ERRFILE cat $ERRFILE 2; } || { cat $ERRFILE 2; false;
}
else
$*
fi
This wrapper script is specific to Bash, but it would be possible to
write one for any shell that can redirect stderr, or even write a
compiled program.
Then you will always have the last warnings available for each C file and
can run (e.g.)
cat src/*/.deps/*.err
to see them.
[
My previous attempt was no good. I wrote:
2. Save the error output for each C file as (e.g.) .deps/*.err. E.g.
in each Makefile.in:
...
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
...
But if the compilation fails, 'make' will quit before displaying the
error output file. That's no good. It needs to be done within a single
command. What I really need is one of these:
gcc 2| tee file.err# No: stderr-pipe not available AFAIK,
and exit status is lost.
gcc 2 file.err 2 /dev/con# No: in Bash the first output file has
nothing written to it.
gcc 2(tee file.err) # No, though Bash can _almost_ do this
on _some_ systems.
gcc 2 file.err || { cat file.err; false; } # This might just about
work!
... but I don't know if I can get automake to put stuff like this in the
generated make files.
]
- Julian
___
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] The string class fights back (was: Property browser bugs)
David Megginson writes: Norman Vine writes: as far as I am concerned creating an ASCII property path is a waste of time and should not be used anywhere inside the 'main loop'. Inside the main loop, it's used only for things like interactive display in the property browser or through a network interface. It's getStringValue where the slowdowns happen (we were talking about that at the same time). I wish that were true.. but see FGViewMgr::update (double dt) and IMO props.cxx parse_path() is a still a time sink but I guess most consider it a worth while one Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Andy Ross [EMAIL PROTECTED] said: Camera (orientation only, no position change) | +-- Transform (move to terrain origin) || |+-- Terrain | +-- Transform (move to model origin, orient to model frame) | +-- Aircraft Model I got started trying to figure out how to do this, but got a little lost. Jim, you know this code a lot better than I do, how hard would that be to do? I can see what you are saying...but the aircraft (in the cockpit view) is actually a different scene graph. Really I've got to get more into ssg to understand how all this works better. For some reason I seem to have an easier time understanding the lower level opengl stuff now than plib (which probably sounds backwards). My first concern would be about the overhead of transforming the terrain each frame (lots and lots of vertices). If it can be done, I think my earlier suggestion of rendering the Cockpit with no position offsets might work. Can't we render everything else and then lastly set the camera to the pilot's nose ( ie with only the offset from aircraft origin and no position offsets or orientation rotations applied). In other words just render it on top of the rest at 0,0,0 plus a little offset to the pilot seat so the cockpit looks right? Or is changing the camera like that not allowed? Note that if we did this we would still need to apply the view offsets so you can pan view and look down at the ruder pedals properly. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] The string class fights back (was: Property browser bugs)
Norman Vine [EMAIL PROTECTED] said: but see FGViewMgr::update (double dt) Yes, all those should be moved to nodes in the view class. How did this look in the last profiling run? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] The string class fights back (was: Property browser bugs)
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: but see FGViewMgr::update (double dt) Yes, all those should be moved to nodes in the view class. How did this look in the last profiling run? Can't remember FWIW - I don't really trust the profiler with Cygwin as I have learned that there are a still few problems with the port. Someone with a Linux machine should probably do a 'profile' again Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS base down temporarily
CVS for base package is down for a little bit. I'll have it back up ASAP. John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS base back up
Okay, we're back in business. J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dc3 effectiveness=nnn for both hstab and vstab
I added an effectiveness=nnn to both the htab and vtab. I was not able to get good control once the tail was up w/o the change to vtab also. I played arround with various values between 2 and 3. I was able to get good control (vtab effectiveness) and early tail up (htab effectiveness) with both values at 2.25. It was easier with both values at 2.5. I then shot a number of touch-n-goes using wheel landings. It still seems that it is very easy to over control in pitch while trying to stay on the mains. This is harder than say a real J3 Cub or a real Stinson 108 Voyager. But it is great fun! It would be great to get some feedback from an experienced DC3 pilot. What I remember from conversations with such, is the DC3 was not hard to handle durring the take-off roll, about like a cub or a Stinson 108, requiring constant attention on the rudder. W/o the vtab change, one cannot recover from even minor missalignment with the runway once the tail comes up which is again not realistic. With both htab and vtab effectivness = 2.25 or above, and careful rudder, one can accelerate on the mains to VMC and then climb out. Having rudder pedals seem like a must for tail draggers in flightgear. I have never flown a real DC3, but while working at Des Moines Flying Service while in high school, Ozark flew DC3's and converted C47's in and out of DSM. I was a lineman servicing both while I built up time (1961-1964). The tails came up early and they accelerated on the mains and the rudder was wagging back and forth durring the accelleration to keep the nose pointed down the runway. I would like to know if the standard procedure for the DC3 was to accelerate to VMC on the mains, or to get it in the air and then accelerate to VMC near the ground and then climb. The latter seems risky, but this is what the yasim model wants to do. You have to fly it on the mains slightly nose down to do the former and the pitch control is very sensitive. For normal full stop landings, it is best to lock the tail wheel and do a full stall landing, brake, get rid of the flaps, and then unlock the tailwheel to turn off the active. Regards, Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
