Re: [Flightgear-devel] BUG when replay with generic protocol
On Thursday 21 February 2008 Melchior FRANZ wrote If anyone could tell me which command line exactly was used to record, and which to replay then I'd check this out. I got it when flying UFO and recording flight with --generic=file,out,100,flight.dat,playback FDM was running at 100Hz. Then I change FDM to external and play recorded flight with --generic=file,in,100,flight.dat,playback As I understand jitting amplitude depends on airplane speed. The problem was solved by mowing the line globals-get_viewmgr()-update(delta_time_sec); upwards after the line fgUpdateTimeDepCalcs(); But I'm not sure that this is a good solution. With respect, Alex - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG when replay with generic protocol
On Sat, Feb 9, 2008 at 8:24 AM, Alex Buzin wrote: I have write the flight to the file using generic protocol (with playback.xml). When replaying flight in Cockpit View all is fine, but when I switch to Chase View picture starts to jitter. I got this at Flightgear-1.0.0 at v0.9.10 this effect is not present. I build FG from sources at Windows, is someone have the same feature at other systems. And how this can be fixed? Hi Alex, I've noticed this too when driving a copy of FlightGear from an external source. I believe the view system was substantially reworked to incorporate some additional nasal flexibility, but the timing of incoming packets now affects the view positioning code which causes problems if a remote data source isn't in perfect sync with the local frame rate (which it is not likely to be unless you are extremely careful with your hardware selection and setup.) I have filed this under sigh not something I have time to look into myself right now, but is something I've brought up before, but not something I have the time/energy to push on right now./sigh It is good to hear that I'm not the only one that has run into this problem of horribly jittery external views when driving the visuals from anything other than the built in flight dynamics. This one is going to bite us in the future because it effectively kills FlightGear's biggest use in research and industry ... as a visualization tool for people's flight dynamics, autopilot, and airframe development. For what it's worth, I ran into this most recently at SCALE when I tried to setup my laptop as an external view of Jack's 747 cockpit simulator. The cockpit view worked ok on my laptop, the fly-by view worked ok, but none of the chase views were even close to usable. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG when replay with generic protocol
* Curtis Olson -- Thursday 21 February 2008: sigh not something I have time to look into myself right now, but is something I've brought up before, Yes, you wrote me about it. I couldn't reproduce, but told you about a bug in the replay system and what you could try. You didn't seem to have done that, but otherwise didn't reply either. So I considered it resolved. If anyone could tell me which command line exactly was used to record, and which to replay then I'd check this out. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG when replay with generic protocol
* Curtis Olson -- Thursday 21 February 2008: If you can setup two flightgear machines [...] Unfortunately not. But if someone wants to donate some good hardware, I'd try that variant. :-} If you don't have the hardware to setup two PC's simultaneously, I could walk you through some other ways to reproduce this. Two command lines would be enough -- one to record, one to replay. Let me point out that in the past, the chase views computed their positions as a direct offset from the aircraft. So the chase view position was always exactly some distance and direction from the aircraft and directed at the aircraft. The way how chase view works hasn't changed. Only the order of some of the actions in the main loops have. I explained the changes on the devel list. (BTW: I also told you to just revert my changes if you couldn't make your test case work without.) With the new nasal code there seems to be a timing element that is introduced so the relative view position jumps forward and backwards every frame compared to the aircraft, No, Nasal has nothing to do with it. It's only the order in the main loop. But whoever wrote the replay system got the interval handling wrong. I told you about it, but didn't want to change it myself without having a way to reproduce. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG when replay with generic protocol
On Thu, Feb 21, 2008 at 11:25 AM, Melchior FRANZ [EMAIL PROTECTED] wrote: Yes, you wrote me about it. I couldn't reproduce, but told you about a bug in the replay system and what you could try. You didn't seem to have done that, but otherwise didn't reply either. So I considered it resolved. If anyone could tell me which command line exactly was used to record, and which to replay then I'd check this out. Ok, perhaps some miscommunication on this issue, but here's one way to reproduce it. If you can setup two flightgear machines and use the --native-fdm= protocol to drive one of the machines from the other, you will see the bug on the receiving machine that is being driven by the sending machine. This is where I see the problem. But I'm certain that the same issue exists when you control flightgear from any remote source (either replaying a saved flight from a file or driving flightgear from live flight data, or driving flightgear from another copy of flightgear.) Notice that this issue has nothing to do with FlightGear's built in record/replay system that can replay your last few minutes of flight. If you don't have the hardware to setup two PC's simultaneously, I could walk you through some other ways to reproduce this. Let me point out that in the past, the chase views computed their positions as a direct offset from the aircraft. So the chase view position was always exactly some distance and direction from the aircraft and directed at the aircraft. With the new nasal code there seems to be a timing element that is introduced so the relative view position jumps forward and backwards every frame compared to the aircraft, this makes the aircraft (and possibly the scenery if you are close to it) appear to jump backwards and forwards every frame. Oh, and this issue only seems to be a problem with the chase views. The cockpit views and the fly-by view seems to be ok. Thanks for taking a look at this, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG when replay with generic protocol
* Melchior FRANZ -- Thursday 21 February 2008: No, Nasal has nothing to do with it. It's only the order in the main loop. Well, Nasal has indirectly to do with it: the change in execution order put the event manager right before the view handling, so that Nasal code (or other event driven stuff) could manipulate it without jitter. Shouldn't be too hard to fix once I can reproduce. m. :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
