Re: [Flightgear-devel] A Question about External FDM and different viewpoints
On Thu, Feb 25, 2010 at 3:26 PM, Grimes, John R Mr CTR USAF AFMC AFRL/RWGG < john.grimes@eglin.af.mil> wrote: > I am currently running FlightGear 2.0.0 (snagged from the ibiblio ftp > site) that I compiled on my Ubuntu 9.10 64 bit system. Compiled up no > problem, but I have noticed that when I attempt to setup a master/slave > scenario that I get some odd artifacts on slave display. The scene on the > slave looks as if the position of the aircraft is lagged behind, and then it > suddenly tries to jump to the correct location. These artifacts don’t seem > to appear in cockpit view or tower view, but they make all the other views > almost unusable. I have checked the developers lists, and I have seen > people mention problems similar to this, but nobody seems to have a good > solution. It could be a double precision problem, or it could be the FG is > propagating the view forward by a certain amount of time and correcting the > view when a new frame of data comes in. > > > > Here is the master system’s command line I am using. > > ./fgfs –aircraft=c172p –native-fdm=socket,out,30,192,168.1.9,5500,udp > > > > Here is the slave’s command line. > > > > ./fgfs –aircraft=c172p –native-fdm=socket,in,30,192.168.1.8,5500,udp > –fdm=external > Hi John, Sorry for the slow reply. Since you are using the --native-fdm protocol, all the values you are sending are full precision binary doubles. There shouldn't be any precision problems like is possible with the "generic" protocol. I've used this sane mechanism with up to 7 slaved displays from a single master machine with pretty good results. I haven't tried with the v2.0.0 code. It's possible something slipped in and broke something, but I think the chances of that are pretty low. For the inbound socket command line, you shouldn't need to specify an ip address, only the sending side needs to know where to send the data to. You've specified an update rate of 30 hz in your command line options. You might double check that your hardware is able to drive the displays at that rate. There is a menu option to turn on a small frame rate counter (or you can find the frame rate in the property tree under /sim/ I believe it is.) It would be good to double check what frame rates you are really getting and do that on both ends. One possible reason the remote end is lagging would be if the sending end is lagging. Data is only sent (or accepted) once per frame, so you can never do better rates with your data transfers than the update rate of the visual scene. In other words, if you requested an output rate of 60hz, but your "master" machine is only able to draw the display at 10hz, then that will be the rate of your data output. Another thing to consider or look for is pauses due to loading scenery or multiplayer aircraft. The multiplayer aircraft can generate a big frame rate hit ... up to several seconds depending on particular aircraft that needs to be loaded. If you have multiplayer turned on, that could be a source of lags. (One small trick is to watch for the hard drive activity light to be pegged on when you see a pause ... that could be an indication the system is busy loading a new model.) > I have played with the update rates of both the socket inputs and outputs > and it did not make much difference. I have relatively a hot system and > video card, so I have tried frame-rate-throttle-hz settings of 30 or 60 to > see if would help (it did not). Am I missing something in the command lines > or is this the expected operation of the views? > Sounds like you have covered most of the obvious things. Another possible thing to check is your network. If it's highly loaded, that could affect how fast packets get through ... While I'm at it, let me put in a plug for some great work that Tim Moore did about a year or so ago. He leveraged our OSG scene graph engine to support multiple cameras and displays on a single machine. Many video cards (most nvidia cards) support 2 monitor outputs, and with the PCI Express bus, it's possible to install as many as 4 video cards in some PC's. I worked on a system last summer that had 4 dual head video cards and drove 8 simultaneous displays from a single PC with pretty good results. Depending on what you are trying to accomplish, this might be another option to consider. When the entire visual system is driven from a single PC, you don't have to worry about synchronizing clouds, multiplayer traffic, AI traffic, random objects, weather, and time of day across several PC's. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev_
Re: [Flightgear-devel] A Question about External FDM and different viewpoints
On 02/25/2010 02:26 PM, Grimes, John R Mr CTR USAF AFMC AFRL/RWGG wrote:
> I am currently running FlightGear 2.0.0 (snagged from the ibiblio ftp
> site) that I compiled on my Ubuntu 9.10 64 bit system. Compiled up no
> problem, but I have noticed that when I attempt to setup a master/slave
> scenario that I get some odd artifacts on slave display. The scene on
> the slave looks as if the position of the aircraft is lagged behind, and
> then it suddenly tries to jump to the correct location.
It's a bug. Actually at least five bugs.
> These artifacts
> don't seem to appear in cockpit view or tower view, but they make all
> the other views almost unusable.
Yes.
> I have checked the developers lists,
> and I have seen people mention problems similar to this, but nobody
> seems to have a good solution.
I assume you found the threads on
--[Flightgear-devel] multiple --generic record/playback errors
--[Flightgear-devel] null-FDM and UFO-FDM instrument outages
Note that the "external" FDM is a synonym for "null" FDM.
> It could be a double precision problem,
There are at leaast two such double precision / float / roundoff
bugs, although perhaps only one is biting you at the moment since
you are using the "udp" protocol. So far I have
-- patched the "playback" protocol,
-- patched io/sg_file.cxx,
-- patched generic.cxx, and
-- patched some of the aircraft's nasal files...
... which solves some of the shudder and jitter problems but not all,
especially not in the non-cockpit views.
http://gitorious.org/~jsd/fg/sport-model/commits/sport
http://gitorious.org/~jsd/fg/sport-simgear/commits/sport
> or it could be the FG is propagating the view forward by a certain
> amount of time and correcting the view when a new frame of data comes
> in.
Something like that wouldn't surprise me.
> Here is the master system's command line I am using.
Thanks for the detailed, professional bug report
=
If you want to pursue it, please go ahead. You won't be
duplicating any effort of mine, because I'm kinda busy at the
moment. I doubt I will have large amounts of time to devote
to this set of bugs in the next week or so ... but feel free
to ask questions.
Suggestion: A majority of the jitter / shudder in non-cockpit
views is readily observable with the ascii "playback" protocol,
not just with the binary "udp" protocol. And I got as far as
fixing gs_file.cxx so that it can read from a named pipe (FIFO)
which I reckon might make the debugging faster and easier.
Suggestion: Scrutinize the console log for Nasal error messages.
If you see something about "nil used in numeric context" then
some .nas file somewhere is referencing a variable that is not
being set by the FDM. Bear in mind that this is treated as a
serious error, and defeats all the functionality in that .nas
file. Such things are easy to fix; in particular, for the
default c172p, the following patch helps a lot:
diff --git a/Aircraft/c172p/Nasal/action-sim.nas
b/Aircraft/c172p/Nasal/action-sim.nas
index 7e79f51..d5defe3 100644
--- a/Aircraft/c172p/Nasal/action-sim.nas
+++ b/Aircraft/c172p/Nasal/action-sim.nas
@@ -26,6 +26,11 @@ var panelLights =
props.globals.getNode("controls/lighting/panel-norm", 1);
var dhN_ft = props.globals.getNode("gear/gear[0]/compression-ft", 1);
var dhR_ft = props.globals.getNode("gear/gear[2]/compression-ft", 1);
var dhL_ft = props.globals.getNode("gear/gear[1]/compression-ft", 1);
+
+dhN_ft.setDoubleValue(dhN_ft.getValue() or 0);
+dhR_ft.setDoubleValue(dhR_ft.getValue() or 0);
+dhL_ft.setDoubleValue(dhL_ft.getValue() or 0);
+
var propGear0 = props.globals.getNode("gear/gear[0]", 1);
var propGear1 = props.globals.getNode("gear/gear[1]", 1);
var propGear2 = props.globals.getNode("gear/gear[2]", 1);
... or you could patch the protocol to set a fuller set of
variables ... or both.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A Question about External FDM and different viewpoints
I am currently running FlightGear 2.0.0 (snagged from the ibiblio ftp site) that I compiled on my Ubuntu 9.10 64 bit system. Compiled up no problem, but I have noticed that when I attempt to setup a master/slave scenario that I get some odd artifacts on slave display. The scene on the slave looks as if the position of the aircraft is lagged behind, and then it suddenly tries to jump to the correct location. These artifacts don't seem to appear in cockpit view or tower view, but they make all the other views almost unusable. I have checked the developers lists, and I have seen people mention problems similar to this, but nobody seems to have a good solution. It could be a double precision problem, or it could be the FG is propagating the view forward by a certain amount of time and correcting the view when a new frame of data comes in. Here is the master system's command line I am using. ./fgfs -aircraft=c172p -native-fdm=socket,out,30,192,168.1.9,5500,udp Here is the slave's command line. ./fgfs -aircraft=c172p -native-fdm=socket,in,30,192.168.1.8,5500,udp -fdm=external I have played with the update rates of both the socket inputs and outputs and it did not make much difference. I have relatively a hot system and video card, so I have tried frame-rate-throttle-hz settings of 30 or 60 to see if would help (it did not). Am I missing something in the command lines or is this the expected operation of the views? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
