Talk:A standard CDU framework for FlightGear

Can we have the standard CDU framework discussion here?

Anyway, about the layers, I was thinking - display animations (OSGText), 3D model, central functioning - MENU, FUNCTIONS/PAGES). About the menu and function/pages, we could use a common menu and have the best/most functional functions/pages from each of the CDUs combined.

- Omega

Scratching my head about what "my" CDU actually did do...

Well, hello (again, I should say)

Some initial information: I am not longer "working" with FlightGear. My project has moved on and "we" don't need a FlightGear CDU anymore, hence I won't be able to spend "work time" on it...

That aside, here are some things I think to remember from "my" CDU:

• It isn't "mine". I started of on Gjis CDU, took his 3D graphics and started to work my way in from his initial XML based approach so all the kudos to him as I learned from his. That said, I am going to drop the "" and call my CDU the one you can get from gitorious https://gitorious.org/~hcc23.
• Beware of NASAL and performance: I encourage you to checkout my CDU and run it (if it still is compatible)... The frame rate really really drops :( I remember having some IRC discussions about that and think to remember the problem being the NASAL garbage collector...
• I tried to generate a rather reusable piece of software.
  • The 3D model is seprate
  • The key binding is separate
  • The backend to generate (Honywell-)CDU style pages is independent from the code that defines the content of those pages
  • There is some documentation on how to actually generate content for the pages.

Overall I think having a CDU would make FlightGear an even better/cooler sim. Chopping the problem up also seems to be a great idea.

Unfortunately I won't have the same availability as when I coded the stuff that now sits in my gitorious account and most likely I won't be able to fully understand my code either. And to make matters worse, I most likely won't check this page very often (although I will keep trying to keep up at least a couple of days/weeks...) So send me a private message via the forum as that reaches me and I can then respond. (Or google any of my email addresses and ping me directly...)

Thanks for making FlightGear the really cool sim it is :)

Hcc23 18:05, 2 February 2012 (EST)

XML

Looking at the suggested XML markup, I'd really suggest to stick to the PropertyList format instead, despite its verbosity, there are so many advantages for XML files encoded in the PropertyList format.--Hooray 08:26, 3 February 2012 (EST)

Embedded Nasal code

The proposal says "Pages can retrieve property values #{property-tree} and call nasal functions ${NasalRef.nasalClass.function()}". The question is if, and how, that would ideally work for functions passing parameters between XML<->Nasal? The example is just using an empty argument list. Is this only going to be dealt with using "global" properties instead of Nasal arguments?--Hooray 03:09, 4 February 2012 (EST)

Embedding Nasal code

Looking at the suggested markup, it would definitely be possible to implement this without any changes to the C++ source code, i.e. by using Nasal itself: Nasal does have support for parsing XML (also non-PropertyList XML) and there are a bunch of helpers provided in $FG_ROOT/Nasal/io.nas. So it would in fact be possible to come up with our own XML schema, parse it in Nasal space and even support embedded Nasal. Nasal can dynamically compile(), bind() and call() code. If that's really the way we want to proceed, there's no need for C++ work.--Hooray 03:17, 4 February 2012 (EST)

Supporting CSS-type styles in XML

Looking at the markup, that should also be possible to support from Nasal without C++ changes. One would need to introduce a Nasal wrapper that dynamically maps the "CSS" markup to OSGText animations.--Hooray 03:21, 4 February 2012 (EST)

Performance considerations

Hcc23 pointed out that his CDU implementation affected frame rate negatively, presumably due to some garbage collection related Nasal issues. While there are some GC related issues in the Nasal engine, I don't think that's necessarily the case here: I didn't do any debugging or profiling yet, but looking at the code in question, there isn't necessarily very much allocation and deallocation taking place (besides string concatenation), especially when compared to other complex Nasal systems such as the bombable addon or the local weather system. However, due to the lack of a 2D drawing API, we are working around some serious FG limitations and abusing the XML instruments system quite heavily meanwhile. For example, looking at Omega95's VSD instrument, there are some things pretty obvious: this is less than 10 kbytes of fairly simple Nasal code, compared to > 150 kbytes of XML animation code. The XML-configurable instrumentation system was probably never intended for such uses. 150 kbytes of XML animation code quite certainly means that there's a fair amount of processing involved, including some serious property tree I/O, too. So, I wouldn't be too quick pointing at the Nasal GC here. Invocation of the GC can be somewhat reduced by caching and reusing variables, i.e. by not always allocating new variables during each loop iteration, but rather reusing previously allocated variables, such as by using Nasal hashes ("objects") for this. So, before Nasal is completely disregarded here, it might be worth doing some profiling (SGTimeStamp) to see how much time is actually spent processing all those XML animations (in complex instruments). --Hooray 04:02, 4 February 2012 (EST)

In my mind the lack of a 2D drawing API and heavy use of XML animation code is also relevant when trying to implement "non-standard" HUDs, which easily could be considered displays as well. Johan G 07:30, 4 February 2012 (EST)

Do we currently have any HUDs that are truly complex? I was really just referring to the performance considerations mentioned earlier, because I am not convinced that all lag can be attributed to Nasal and its GC. Obviously, getting a 2D drawing API would be great at some point, for a number of reasons - but that's a long standing feature request, and core devs know and agree on that: FlightGear Glass Cockpits (5 years old now). In the meantime, it would be important to check where exactly the lag is created in the first place.--Hooray 08:41, 4 February 2012 (EST)

Access to a 2D drawing API is becoming essential to where my thinking is evolving, as can be seen in my rantings on the page. As for Nasal performance hits, I agree that it may not necessarily be the performance hog some make it out to be. I have written a lot of Nasal code the A380 and I believe I get frame rates that are better than some other aircraft with less Nasal. I think anyone who spends enough time in Nasal has a good idea of how to work within the performance bounds of how it is called. --Scotth1 09:11, 4 February 2012 (EST)

Agreed, the need for a 2D drawing API has been discussed for many years now. So, there's probably no need to jump on the same bandwagon now. The situation hasn't really changed, I guess everybody agrees that 2D drawing capabilities would be great to have and that they would finally make crude XML hacks obsolete. On the other hand, just take a look at what Omega95 is accomplishing even without a 2D drawing API currently: here . That's absolutely impressive, but it's obviously a huge XML-based workaround (not to say HACK) with lots of redundant XML code, just to work around the FG limitations, so that certain 2D primitives can be drawn. Looking at his XML code, it's actually obvious that a handful of additional XML tags, could make his work much easier and much more compact, too. I am thinking in terms of "meta programming" capabilities, like for example a "foreach" primitive (in the form of XPATH expressions). These XML files could then be written in a much shorter form, especially if properties are fully supported. I am just mentioning this because Omega95's work is obviously a result of not having a 2D drawing API and he's managed to work around many limitations already, so it might be possible to come up with additional XML primitives to simplify his approach until a 2D drawing API becomes available. The weird thing is that he's making progress pretty quickly now and that his XML-based instruments are pretty close to duplicating features only found in hard-coded C++ instruments that weren't maintained in a while. So, it's possible that his work may be favored by aircraft developers over the C++ equivalents because of the plethora of features he's adding at an impressive pace. This is somewhat unfortunate because this is overlapping with ongoing C++ core development , but I guess it's simply a symptom of users trying to do things that aren't yet supported otherwise. --Hooray 14:18, 4 February 2012 (EST)

Well, we don't have a 2D drawing API at the moment and which is why, as Hooray mentioned, I'm using such approaches. I don't see much of a frame rate impact with it either. Is there a way to create xml animations with nasal (like php with html)? If that's possible, we could make a function for it and we could simply call the function to draw the line for us. --omega1174 17:15, 5 February 2012 (IST) < (How do I put a sig. automatically?)

Yes, there is - that's why I suggested this approach in my message, I have replied to your PM and forum posting. Let me know if you need additional info. Basically, it's all about using write_properties() after dynamically writing your PropertyList structure to the property tree using setprop(). So that's fairly simple actually and should save you some time.--Hooray 07:03, 5 February 2012 (EST)

Well, I have no idea on how to animate models with nasal, is there a wiki page for this? I set the properties with nasal and then use xml to execute the animations. If there's a way to create animations with nasal, please do tell me soon. If there isn't a wiki page, it's alright if you tell me some aircraft which uses such animations. Thanks a lot! --omega1174 18:49, 5 February 2012 (IST) < (How do I put a sig. automatically?)

I was suggesting to use a separate Nasal script to automatically create the XML structure that you need. Did you see the example in posted [1] ? Now, what you are apparently asking for is a way to dynamically create, animate and display a model just within the property tree, right? To be honest, I have no idea if that's possible, but I don't think it is. But if that's what you are interested in, you could use a temporary workaround by 1) creating the XML structure, 2) writing it to a temporary location ($FG_HOME), 3) using geo.put_model() to show the model. But that's really just a guess, I have no idea if that works or not, never tried that. I will get in touch with you shortly. Regarding the sig: use the signature button above the entry form (upper right corner, second button from the right). Or just put 4 tilde characters manually --Hooray 08:25, 5 February 2012 (EST)

Questions raised by scotth1

• 1. How do declare what a page looks like (think not only CDU pages, but Primary Flight Displays, Nav Displays, anything that is becoming a LCD screen in a modern aricraft)
• 2. How do we create text, clickable input fields and other objects on a canvas like object from the page definition

Regarding 1), looking at the XML code you posted, you seem to envision some sort of layout mechanism that describes each page using some XML markup,right? I am not sure if that's flexible enough, especially because you are referring to "modern aircraft" - and not just a simple CDU from the 70s or 80s. Modern FMC front ends are more and more heavy on graphics, using real GUI widgets and such. Regarding 2), you also seem to be very focused on modern avionics, right? Are you specifically referring to the GUI requirements of the A380? Seems so to me, modern aircraft like the A380 have fairly complex GUIs, that make heavy use of widgets. That's the sort of thing that's hard to duplicate using just XML and Nasal. And even if we had a 2D drawing API, it'd be a lot of work to duplicate such features. Normally, these requirements are handled using ARINC 661 on modern aircraft, we've had some related discussions due to the j661 project which uses FG to visualize flight data. If that's your main area of interest, you might want to check out the j661 project (if you haven't already), because it already provides support for interfacing to FG, and it provides a GUI editor to create avionics and the corresponding GUIs. The project also includes a capability to render its instruments remotely (i.e. in a different process), so that it would be possible to create a new instrument type in FG that renders J661/A661 avionics, possibly even by dynamically assembling the GUI from the XML markup. In my opinion, the GUI needs of a modern airliner like the A380 are hard to meet with current FG technology. Especially, given that we are currently not even able to fully replicate the typical 80s/90s-style EFIS and MFDs (PFD/ND/EICAS) without resorting to some huge workarounds. So I am not sure if the A380's GUI needs aren't too amibitious for the moment? A661 represents a huge shift in HMI design and thinking, the GUI concept is still pretty novel.--Hooray 09:26, 5 February 2012 (EST)

"2. How do we create text, clickable input fields and other objects on a canvas like object from the page definition"

Take a look at [2] , I've defined whether a slot is clickable or a simple display for every page and then xml looks into it and there's a select animation to the clickable object (which is just a transparent square above the display area). —This unsigned comment was added by Omega1174 (Talk | contribs) 16:40, 5 February 2012 (UTC)

2D drawing API discussion

I have created another page detailing my thoughts on the 2D drawing API here: Howto: Create a 2D drawing API for FlightGear.--Hooray 15:36, 5 February 2012 (EST)