zakalawe wrote in Mon Jul 29, 2013 11:02 am:Looks interesting - I think several similar systems have been done by different research and academic groups before, but not have made it into Git. Part of the issue is that some have been quite domain-specific. E.g if they're intended for small-areas of flight, loading in a arbitrary route-manager route can create enough marker objects to bring the frame-rate crashing down.
Can you speak in rough terms about the approach you're using to get the markers into the scene, and constrain the total number visible in the view?
This is a good point. Bounds checking and testing would need to be done to determine how this system effects the frame rate. Currently, there are no constraints on the number of beads drawn, and I am not doing anything to hide beads that aren't visible.
This implementation is fully scripted in Nasal. To get the markers into the scene I use geo.put_model(). Waypoints are pulled directly from the route manager, which allows routes to be modified/saved/loaded from inside FlightGear.
Hooray wrote in Mon Jul 29, 2013 12:44 pm:Hi & welcome!
As the most basic implementation, there's the fully scripted "glideslope tunnel" script:
http://wiki.flightgear.org/Glideslope_Tunnel(see glideslope image above).
A more recent variation of it is called "Hoops", also fully scripted: (see hoops image above)
http://flightgear.org/forums/viewtopic. ... ilit=hoopsgit repo at:
https://gitorious.org/hoopsThere's been talk about integrating this into FG/git and adding it as an optional component to the tutorial system, so that tutorial could use such trajectory markers for different visualization purposes - i.e. not just ILS and/or route manager trajectories, but anything.
Ideally, we would look at all these implementations and generalize/unify them, and get them committed to fgdata - there should be no need for C++ changes here, it's all supported in Nasal space - and if something isn't, it would be better to expose it to scripting space.
Thanks! The glideslope tunnel script was a very helpful starting point for the script I wrote. I had not seen hoops before. It looks very useful. I like the idea of these implementations being unified/generalized. That could produce an effective tutorial.
I have been speaking with Curt Olson about all this. He mentioned that it would be nice to be able to show desired roll angles at the waypoint positons (I've been looking through the code for hoops and it seems like a variable pitch and roll are supported), although the bank angles would depend on your airspeed, which complicates things.