On Apr 23, 2008, at 4:09 PM, Adam Dershowitz wrote:
On Apr 21, 2008, at 2:17 PM, Melchior FRANZ wrote:* Adam Dershowitz -- Monday 21 April 2008:I did make the minor change that Alex suggested in this discussion: [...] and then rebuilt and it seems to be working. Is that essentially the change that you were referring to?It's the correct thread. The fix isn't and will probably cause other problems (jitter in some newer view modes, IIRC), but as long as it works for you, all is well. :-) m.I have run into what might be different issue...and might be what you are talking about. With playback data the ground slightly jumps back and forth. It looks almost like a vibration. It seems to happen with all of the views. At first I thought that it had to do with how smooth my Lat/Long data was, so I tried fixing that. But it didn't help. So I finally just did a recording of a simple takeoff at high frequency, with everything at the defaults: fgfs --generic=file,out,32,/Users/dersh/Documents/Cases/587\ Animation/DFDR\ data/test_out.csv,playback and then did a playback: fgfs --generic=file,in,32,/Users/dersh/Documents/Cases/587\ Animation/DFDR\ data/test_out.csv,playback --fdm=null and I get this "jitter" of the ground back and forth on playback. It is not much (perhaps a couple of feet back and forth). I started to wonder if it might be that the code that reads in the lat/long is not reading in enough significant digits? Internally clearly there are enough because it looks smooth when I am recording. Is there some rounding, or reading in as float instead of a double? Any ideas on this one? Is it the same bug that was fixed in CVS? I have not yet tried to rebuild from CVS since Alex's suggestion to change the order of: globals->get_viewmgr()->update(delta_time_sec); upwards after the line fgUpdateTimeDepCalcs(); seemed to be working for me. But did I hit another issue related to this? Melchior, is this also what you fixed? I am a little nervous about doing a new build because I am using Tat's download/build instructions for a Mac and then I applied Pigeon's patch to capture video. All seems to work, but I am not sure which pieces of that process might break if I do a full CVS update and rebuild. That is also why I have stayed with PLIB. --Adam
I spent a while trying to track this down, and finally figured out what is going on. The problem is that generic.cxx can only handle floats, and that is not enough resolution for latitude and longitude, so the last few digits are lost in the conversion.
I found a simple solution, that is working for me to be able to read in data correctly:
So I changed line 208 of generic.cxx from: _in_message[i].prop->setFloatValue((float)val); to read in a double: _in_message[i].prop->setDoubleValue(val); Now, if I play my data files the aircraft moves in a smooth way.So I figure the more general solution is to add a new type to the generic protocol which is "double". That way there is no change to any existing examples. I have attached a few diff files that work for me.
playback.xml.diff
Description: Binary data
generic.hxx.diff
Description: Binary data
generic.cxx.diff
Description: Binary data
the only changes are to generic.hxx and generic.cxx to add the new double type. I have also added a diff to playback.xml that make it use doubles for latitude and longitude so that I could test it out. And it worked fine both to record and to playback in a nice smooth way.
If there is a better way to submit this patch please let me know. --Adam
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
