20,741
edits
Property Tree/Native Protocol Slaving: Difference between revisions
Jump to navigation
Jump to search
→Slaving Dynamics (FDM): http://flightgear.org/forums/viewtopic.php?f=36&t=19858
m (→Syncing multiple instances: www.inkdrop.net/dave/multimon.pdf) |
(→Slaving Dynamics (FDM): http://flightgear.org/forums/viewtopic.php?f=36&t=19858) |
||
| Line 122: | Line 122: | ||
== Slaving Dynamics (FDM) == | == Slaving Dynamics (FDM) == | ||
There is a sample implementation that shows how to do this in the sourcecode under FlightGear/examples/netfdm. | There is a sample implementation that shows how to do this in the sourcecode under FlightGear/examples/netfdm. | ||
== Example: Syncing custom properties (animations etc) using a generic protocol == | |||
For the full thread, see [http://flightgear.org/forums/viewtopic.php?f=36&t=19858]. | |||
(Required background reading: $FG_ROOT/Docs/README.IO and $FG_ROOT/Docs/README.generic) | |||
=== Multi-Instance Setup === | |||
* I was under the impression that using only one computer and multiple displays with FlightGear would be too taxing on the computer and graphics hardware. I've done multiple screens with GEFS (Google Earth Flight Simulator) and got some pretty slow frame rates doing it. Multiple computers with FGFS though is *so* much smoother most of the time. Much, much better. | |||
* After much trial and error, I've succeeded in setting up slave computers for displaying different camera views, and it's pretty freaking awesome. I'd like to do some fine tuning now and hope I can find some help here on the forum. | |||
* I've pretty much been working with just one aircraft in getting the multi-computer thing going. The way I implemented it was to add a new view to the Aircrane aircraft on each computer - slave left view, master view, slave right view. | |||
=== Syncing Shadows === | |||
* The first thing I'd like to tackle is - how to not have inappropriate shadows - in the slave displays. The aircraft can be well above the ground and yet cast *in the air* the shadow it would cast if it were on the ground. And possibly related to that, the props/rotors/etc. are frozen and don't move at all. Is there anything that can be done about this? I'm using native-fdm and native-ctrls between the computers but know next-to-nothing about the capabilities of the other options/protocols. I had some success with native-gui (I think it was), but so far, the fdm and ctrls combo works best for me. | |||
* One more thing I noticed today was that while the attitude may change, there doesn't seem to be a corresponding change in the shadow. It always looks like it would look if the aircraft were parked on the ground | |||
* sounds to me like you are using a combination of I/O protocols that isn't suitable to synchronize aircraft properties to update the slave instances. | |||
* This is an aircraft-specific issue, due to the limitations of the protocols that's used - basically, the aircraft uses animations and properties that are not synchronized with other instances. So that animations from the main/master instance are not properly propagated to the slaves. | |||
=== The Problem === | |||
* The way you described your setup, you are running multiple instances of FG, which are connected in a master/slave fashion - which basically means that important properties need to be replicated/copied over to the slaves instances. These are properties like position, orientation, view, velocities etc - each FG instance will then individually compute a corresponding view. The frame/image itself will never be copied to the other instances - just the variables. | |||
* So are there additional protocols I should/could be using maybe? Is sending just the master computer's camera views - without its fdm etc. - something that's possible, or does that require too much work from the master's graphics card and defeat the whole purpose of using multiple computers? | |||
* Meanwhile, I'm thinking the wierd shadows are only a symptom, and the props/rotors not moving is another sympton. It's as though the aircraft models in the slave computers get no instruction to be anything but parked on the ground with the engines off. You see (at least I see) the changes in attitude as you fly, but that's it. Nothing else ever changes... | |||
* the animation properties don't seem to be properly synchronized - you'll need to handle that explicitly using another sync protocol, the FDM/input protocols don't transmit animation properties - they just transmit the "fundamental" properties. Basically, your slaved instance knows nothing about the properties that it needs to get from the master instance. | |||
=== Using a custom protocol to sync properties === | |||
* Also, you can easily come up with your own custom protocols by editing/creating XML files [[Generic Protocol]] | |||
* it looks like generic protocol might be the way I want to go, but how do I determine which properties need to be included and which ones don't? Or am I asking the wrong question? | |||
* You could try to run a single master instance and check the values of the properties via the property browser. That should give you an idea of working values, even without understanding all the XML/animation magic. | |||
* We've been discussing weird shadows, and propellers not spinning and such, but my focus is primarily on the shadow problem. I can put up with animations of flight control surfaces not working in the 'at aircraft' views, because I'd probably only use those views occasionally. However, in views from the pilot's perspective, pitching down and banking can cause extremely distracting dark shadows to come into view that darken huge chunks of real estate below. The size of the shadow is constant, regardless of altitude; it's the shadow that would be cast on the ground when the aircraft is on the ground. I nearly jump out of my seat sometimes when they suddenly appear during a dive etc. | |||
* Well I've started thinking it might simply be a matter of *altitude updating* of the aircraft's shadow casting properties that's not being received by the slave instances via the native-fdm protocol. The 'shadowcasters' of the slaves, so to speak, always think the aircraft is on the ground. If this is the case, I would imagine that somewhere in the properties browsers of the master and the slaves I would see the values of certain altitude properties being updated in the master and remaining constant in the slaves? | |||
=== Finding relevant properties === | |||
* So if any following this thread think I'm on the right track here, could you offer some suggestions as to what properties I might look at or what altitude related keywords in the xml files and properties browser might be worth taking a look at? I've done some searching on "agl" (above ground level, I assume)and "elev*" and "shadow*," but haven't come across anything yet that looks all that promising. Of course looks can be deceiving, so any insights at all would be greatly appreciated. | |||
* if this is "stock" FG in non-Rembrandt mode, the shadows are unlikely to be actually computed - they are just a "hack" added by modelers, in the form of semi-transparent 3D models usually. | |||
* In the master computer's view, the same shadows I've been talking about *change* as altitude changes. It's the ground shadow you see with all aircraft. The higher the aircraft goes, the smaller the shadow on the ground appears to the pilot. In the slave views, the shadow doesn't change at all with change in altitude. The shadow is always the same size to the pilot; it's always the size it is when the aircraft is on the ground. What I need to know (I think) is what properties effect that change in the master's views that are missing in the slave instances. Would it matter whether or not that change is caused by a hack or whether or not it's a hack that gets changed? Couldn't such a change be transmitted via the generic protocol nevertheless? | |||
* Regarding the shadows: that'd depend on the animations that are used there - so, you'll want to check out the animations on the master, see how they work exactly, and then provide the correponding data (=properties) by sync'ing them from the master to the slaves. Given your progress, that should be all do-able now, you just need to find the animations and check what properties are used. A fair deal of stuff can be learned just by using the property browser or the Nasal console and playing around with various properties, and changing them at runtime - no slaves needed for that, just to make sense of how the animations and properties hang together. | |||
* Actually, the shadow is 95% generic/standard across aircraft, and only has two rotates (/orientation/pitch and /orientation/yaw) and a translate (/position/altitude-agl or /position/gear-agl-ft) and sometimes one more for the rotors (I forget the property, but it's under /rotors/main and it's absolute position in degrees). I think it will work, but it's odd that the shadow is not showing up (I wonder if it is possibly below-ground?). | |||
* I meant to say was that it was the /position/gear-agl-ft property I wanted to try, because when I inspected that property in the slave with the internal properties browser, it showed a value of ' ' (blank), whereas the same property on the master did show a value. | |||
* I'm trying to set up generic protocol communication between a master and slave computer. | |||
=== The generic protocol === | |||
* I created an xml protocol file with an output block for the master and opened a generic protocol output. | |||
* A protocol file can contain either or both of <input> and <output> definition blocks. | |||
* Well, I think I'm on the right track. First of all, I took the protocol file with the output block for the master and copied it to the slave computer and simply changed both output tags to input tags. | |||
* Then I created the input generic protocol on the slave and gave her a shot. Well, lo and behold, the shadows are gone, although not as I had hoped. I was thinking I would still see *appropriate* ground shadows, but it turned out there are now no shadows at all...which is a far cry better than it was before. I can definitely live with this, but if anyone can think of any tweaks to get the appropriate shadows back, that would be way cool. | |||
* In the protocol files I used, I wasn't sure what value to put in for the 'format' tag, so I edited it out. I didn't know how to find out what it should be. Wouldn't it be great if the correct value for that would bring back the appropriate shadows? | |||
* Someone with more expertise could probably look at the value for the /position/gear-agl-ft property in the properties browser and determine by the number that's displayed what the format is, but I'm not in possession of that knowledge at the moment. | |||
* I'm making progress. I have shadows behaving pretty well and am starting to get rotors moving, but the rotors are behaving badly. They spin in the slave when they're stationary in the master. They start looking like they're robo-spider-legs, drawing in and out and in and up and in and down, all with quick jerky moves and blurring going on. It's wild! | |||
=== Format tags === | |||
* Well I've not put in many format tags at all, and I'm wondering if that can matter. The values of a property in the slave property browser can be radically different from the values of the same property in the master's property browser. Is there a way to find out which format tags to use for properties on the tree? | |||
* Generally, I think you will be wanting to use %f. Read up on printf formatting flags: %d is an integer and %f a float/double. I think that all properties will almost certainly be doubles. | |||
* I use "type" tags to declare property values as double, float, etc. When you, for instance, declare a type to be float, what does formatting as %f do? I know you can dictate how many decimal places there should be on either side of the decimal point with something like %xx.xf, but what does %f default to? It's the number of places on either side of the decimal point that I was wondering what would be best. | |||
* I guess I'll go ahead and experiment with it while I wait for any reply you might be able to offer. I don't think I'd do too much damage doing that... | |||
* the type attribute tells the property tree how to store a value internally, using the most appropriate data type saves memory and reduces conversion overhead (bool, int, float, double, string). Using the printf-style format strings in a generic protocol XML file, merely tells the I/O system how to encode/decode a property - so that it can be saved/transmitted and restored properly. Using the wrong type and/or format string in a binary protocol, would cause wrong data to be transmitted/processed by FG. Basically, each type specifier tells FG how long each data type is in memory (bits-wise). For example, a boolean value is just 0 or 1 - so it only requires a single bit. A byte, on the other hand, requires 8 bits - and an integer (int) 4 bytes (32 bit). So telling FG that something is a bit, will cause the data to be truncated to just a bit - which is what the format specifiers are all about: you can affect the re-interpretation of values from the property tree. In addition, there's the concept of signed-ness, i.e. numbers being positive or negative, or numbers having a mantissa - these affect how the values are stored in memory, and accordingly, the receiver must know how a value was encoded, to transform it back to what you want it to be. | |||
=== Success ! === | |||
* Well I'll be! I added %f formatting to everything, and now everything appears to be working almost perfectly. The shadows are appropriate and the main rotor on the slave appears to be behaving exactly like the one on the master. This is awesome. The only difference I can see is that the animated main rotor shadow appears to have fewer blades on the slave, but if I never find out why and fix it, it will barely matter. I'm completely stoked! All I basically have left to do is put in pretty much the same code for the tail rotor that I did for the main rotor. | |||
== Examples == | == Examples == | ||