Loading kml Overlays on Scenery

[Stevenj279]

I'd like to be able to load polygons that will be visible in the scenery during runtime/flight (from all views: pilot/copilot, chase, etc.). For example, the borders of an assigned flight route corridor, waypoint labels, military symbology, etc. Each kml object available would be selectable (or de-selected) via assigned keys, or via selections using a mouse. I've looked through the FlightGear documents and many other sources, but no joy. Any assistance would be appreciated!

[Hooray]

Yes, that's possible and has been done previously. I would suggest to run a forum search for airspace visualization and glide slope tunnel. You should find dozens of topics

[Johan G]

FlightGear currently is not able to drape images over the terrain. On the other hand it is very much be possible to have objects, textured or not, hovering over it.

While not exactly what you are asking for, if I understand you correctly, the topic Stand-alone mission system should be of interest.

[Stevenj279]

Thanks guys! I'll check out the sources you suggested. To get a better feel for what I'm looking to do, it's focused on ways to better visualize the battle space from a military aviator's cockpit perspective. Being able to display order of battle symbology, whether via glass cockpit displays or even simulated augmented reality (OTW) could improve situational awareness to reduce or mitigate task overload and is of definite value. I don't see the need to drape, or clamp overlays to the terrain; just being able to generate layers that show corridors, routes, target symbols, etc. would be more than adequate. FlightGear represents a viable means of experimentation, and it being open source is a definite plus! Hope that gives a better representation of my interest area.

[Johan G]

Disclamer: This is a late night post.

I am not sure how much you have read in on FlightGear yet, but I will try to briefly describe some concepts and features that most likely will be very useful to grasp.

First off, the property tree It is a tree of key-value pairs that practically is the backbone of FlightGear, and the way the very most parts of communicate. In addition, practically all of the configuration files are parts of the property tree, serialized in XML form, that are amended to the property tree as they are parsed by FlightGear.

Nasal, the embedded scripting language of FlightGear, can be used both as separate script files, modules, as well as embedded into the above mentioned configuration files. There are also some common libraries, like for example Nasal/view.nas for manipulation of the views.

All key and input control bindings for example are defined by a combination of the above. The joystick configuration dialog is only exposing the tiniest bit of the possibilities.

The aircraft and addons for FlightGear are almost completely made up by directory trees with a tree of configuration files, together with Nasal scripts and resources like 3D models and textures.


Lately, and I think this might be interesting to you, there have been added a mechanism to simplify adding addons, so that they can be added to FlightGear by simply dragging and dropping a directory with some configuration files, Nasal scripts and any other resources. For details on the addon mechanism see the FlightGear wiki article Addon (permalink).

In addition you might want to take a look at both the Stand-alone mission system topic mentioned above, and the /AI/... directory as it holds the various AI scenarios, many of which are using Nasal scripts to spawn and manipulate models, like for example carrier groups (IIUIC complete with for example carrier aircraft elevators that can be manipulated in FlightGear).

Also, IIUIC there is a Nasal module that can parse some elements of SVG files (an XML formatted vector graphics format), Nasal/canvas/svg.nas, so it is not unlikely that you could modify that (or maybe write something better) and and use that in an addon that can parse KML files into (possibly manipulatable) objects shown within FlightGear.

[Hooray]

You could also use a scripted HUD using the canvas system to draw arbitrary stuff onto it

[Johan G]

And while Canvas can be used for HUDs it is also used for EFIS displays in models ranging from variants of the J3 Cub all the way to the Space Shuttle, but there is no reason to only use it on various displays. IIUIC it could just as well be used as a texture on pretty much any 3D model. Searching the forum and wiki for Canvas could be interesting.

[vanosten]

I do not get it entirely, what you want to do. But here are two considerations:
* Apparently you want to see the stuff in "any" view and angle - so it could be (dynamic) scenery objects instead of being drawn on a screen. One consideration is: does this only have to be visible for one pilot - or for multiple pilots over multiplayer? The solution might be quite different.
* There is a military simulation community for FG - see my signature. I do not think OPRF has what you want, but some of the stuff I am doing over MP might be related to what you want.

[wkitty42]

AIUI, the OP wants to use google maps KLM data to visualize the flight paths in the same way we see the glide scope tracks using the square red "U" shapes... with them displayed, either in the scenery like the glide scope or just in the craft's HUD, one could then fly the tunnel made by the KLM points...

[Stevenj279]

Thanks all - Much appears possible with FlightGear. The visualization of data based on what's happening in the Battle Space for pilot awareness is critical given how quickly events occur and change. Survivability and effectiveness will hinge on the availability of vital data elements in a many-on-many scenario and within the cockpit, whether through HUDs, glass panels, or AR. That's what I'm investigating and my focus is more on the rotorcraft platforms, given they are essentially "low and slow" and vulnerable to a wider variety of threats (not to mention unexpected "encounters" with terrain or cultural features). Anything that can be tested in a simulated environment can be integrated into the real world through demonstrating a concept and letting the defense industry figure out how to implement such capabilities.

I'm also curious as to if FlightGear can be modified to enable collisions with objects such as trees, poles, towers, power lines, buildings etc. From what I've seen so far, the only time the platforms actually "crash" is if it impacts the terrain.

[Hooray]

https://www.cobbin.com/synthetic_vision ... ision.html


viewtopic.php?f=36&t=19210&hilit=Oshkosh#p177820

[Thorsten]

I'm also curious as to if FlightGear can be modified to enable collisions with objects such as trees, poles, towers, power lines, buildings etc. From what I've seen so far, the only time the platforms actually "crash" is if it impacts the terrain.

No, you can crash also into 'certain' buildings and trees - which is to say, those which are actual 3d models and not shader-instanced objects (the former class is 'really there' on the CPU and is available for intersection tests, the latter only exists on your graphics card and on your screen, but the CPU knows nothing about them).

You can (easily) modify FG to represent trees as 3d models rather than instanced objects, but I'm not sure you get a usable framerate out of the exercise, there's a reason they're not done that way (same for generic buildings etc.)

[wlbragg]

those which are actual 3d models and not shader-instanced objects (the former class is 'really there' on the CPU and is available for intersection tests, the latter only exists on your graphics card and on your screen, but the CPU knows nothing about them).

For the shader or land classed variety of trees, something I never considered and which is not the most elegant solution, is what a developer of the c182 did. He created a nasal algorithm/loop to catch certain land classes (forest) plus polled aircraft elevation above ground and when the condition was met threw a collision flag. Obviously a hack, but for simple aircraft to virtual tree collision, it works.

[Hooray]

I guess Thorsten could comment on the specifics, but it might also be an option to procedurally generate a noise texture to determine the exact location/type of tree(s) - that way, the effect/shader could generate the visuals of the trees, whereas the underlying texture could be used (on the CPU) to model collision boundaries, e.g. cylinders for each tree with varying height/diameter - this could be done with an aircraft centric LOD scheme, analogous to how Thorsten's weather system uses/used a 3x3 grid of tiles with the center tile being the one where the aircraft currently is located. That way, you could use differentiate between trees that are sufficiently far away, and those for which you'd like to run collision detection - and possibly use 3D models for those instead of "just" shaders.
As someone else said, 3D models can be dynamically textured using the Canvas system, and they can obviously also apply effects/shaders.

Collision detection itself could then be implemented via property rules and/or in a Nasal background thread

I think geo.nas has most of the tooling necessary to compute volumes in 3D space, and since trees are static, these would only be computed once for each visible tile - for each tile, you'd instantiate a number of trees (3D cylinders) with varying dimensions. I think we even once had a topic about modeling rotor wash

In other words, FG hasn't been designed with this stuff in mind (mainly because people wanted it to be a civilian/peaceful piece of software), but most of the building blocks should actually be already in place.

In some way, this is analogous to how the wingflex/traffic shaders came to be - without explicit support by the core (developers).

[Stevenj279]

Thanks hooray for your detailed reply! The methods of making this so are a bit beyond my skills right now, but at least it's possible. Also, I know rotor wash has been done using SpeedTree, but that's proprietary and also expensive...not viable for open source products like FG.