On board Radar

[Hooray]

right, I did ... actually I was thinking about it, but I thought that this would now be dynamically done - but I was wrong, that's the old stuff in *.layer files that I changed ...
But we could also add a simple "registration" API and load certain files by default to process registration calls, so that people can easily register their own MapStructure files

The other thing is, things like RADAR/ATC views are primarily about filtering traffic, analogous to the existing positionedSearch mechanism, which we would ideally extend to provide custom filtering heuristics - i.e. he mentioned "terrain", "heat", "range", "radio propagation" etc - it would make sense to just generalize positionedSearch and allow people to use these in a cascaded fashion, so that each filter would provide its result as the input to the next stage - that would be pretty efficient and generic, and would encourage encapsulation - i.e. we could be reusing those filters in different areas - in fact, I am thinking about introducing a *.filter file just for these purposes, because it's gonna be such a common thing to do - just look at Gijs' layers, and it is foreseeable, that people are going to have more sophisticated filtering needs.

Also, it would make sense to move shared Nasal code out of the dialog and use io.include() instead

[Hooray]

So I still have the VOR displayed. How, with an arrray[] can I feed this Canvas to display (with same picture for begining) the plot spotted by the radar ?
For info this array will be an array of "Target" object.

Once the previously outlined steps are working, I would consider customizing the searchCmd in your lcontroller file.
At the moment, TFC.lcontoller works like this https://gitorious.org/fg/fgdata/source/ ... roller#L90

• get a list of AI and MP traffic (two vectors)
• foreach list of AI and MP traffic
• determine if each aircraft is within the range specified via in_range: https://gitorious.org/fg/fgdata/source/ ... roller#L50
• **** PLACEHOLDER ***
• if it is in range, the aircraft will be appended to the result vector
• the result vector will be returned, and later on used to call the draw/update routines in the *.symbol file (e.g. TRAFFIC.symbol)

The line where I added PLACEHOLDER is where you could insert your own logic, i.e. the radar-specific stuff from xiii's code - such as checking distance, azimuth, altitude - radar profile/signature, terrain etc - and only append the aircraft if the whole check evaluates to true.

You will find that the whole lcontroller file uses a wrapper called "TrafficModel" - you can either extend this to use your "Target" class directly, or change your Target class accordingly.
The main thing is that your class should be derived from a geo.Coord object, so that it has the lat/lon/alt methods available and can be directly processed by MapStructure without requiring further changes.

You will see that the TrafficModel class is used in a few places - so this would need some changes if you use some different approach, but it's still simple.
The external interface is all about having lat/lon/alt (positions) and the .equals() method
Overall, TrafficModel is just a dumb helper class that is a wrapper for geo.Coord() objects, so there's no reason why you shouldn't be able to extend your own Target class accordingly, you can use the TrafficModel as a template. I would just suggest to maintain the MVC separation at all times.

Analogous to the in_range() helper, you could add other functions for your own filtering needs (altitude, terrain-obstruction etc) - it's better to use separate functions for each, than inflating a single function unnecessarily. As you can see, the in_range() function is unaware of TrafficModel specifics -it deals directly with lat/lon pairs..

So it's simple to reuse as is.
TrafficModel itself is typically directly used via the constructor call: .new()

There's now a separate article detaliing all the steps outlined above, to provide a dedicated place for people interested in this - or even in getting involved, but also to document the whole effort: http://wiki.flightgear.org/Canvas_Radar

I have also extended the "demo" in the MapStructure article, so that it now contains a button to reload the dialog from disk, for more rapid prototyping - without having to exit/restart FG.

[5H1N0B1]

Analogous to the in_range() helper, you could add other functions for your own filtering needs (altitude, terrain-obstruction etc)

This is what I panned

I'll follow the different step you wrote, and try to do something...(Not sure it can be done in the next 15 days...)

Just I want a advice for terrain detection :
I have to way of doing it in mind :
1) The same way of b1 terrain detection : create a non graphic "particle" submodels and send it at lightspeed to the target aircraft and use "impact" property if it meet terrain.
2) Do a kind of "for loop" , with a 100m step (discutable but difficult to hide a plane behind less a 100 m wide terrain...)
3) look how the 1) is calculated, wich function is used and see if it can be "reused", especially if it's a C++ compiled function, which is (if I guess right) faster than Nasal
What do you think guys ?

- I'll also add heat detection, RCS management (but I thing this RCS depend of the frequency used by the radar so...perhaps this can quickly become too complicated...)
- I think I'll also add a "Doopler" Function, which make the airccraft disapear in terrrain, if : the target fly at low alt (and lower than us). If Doppler is active, a way to "lock" the target when it have a speed...
- The radar will have a default heading and pitch that coould be change : We could simulate advance rear radar like those we can find on some Russian bird like Sukkoi, or simulate "look down radar"
- The selection of RWR/indrared/radar will be stored in target class. Then they could be reused for each layer

[adrian]

Just I want a advice for terrain detection :
I have to way of doing it in mind :
1) The same way of b1 terrain detection : create a non graphic "particle" submodels and send it at lightspeed to the target aircraft and use "impact" property if it meet terrain.

You need to iterate through terrain vertexes for that. It's a C++ job, not only because it's performace hungry, but also because it's already done in simgear.
Look into the BVH OSG node visitor if you want a glimpse.

[Hooray]

@5H1N0B1:

Just for prototyping purposes, you can do what you described there - but otherwise I tend to agree with Adrian.
In fact, I got in touch with him over the weekend to discuss with him how to best integrate his Radio Propagation code into FG: http://wiki.flightgear.org/Radio_Propagation
The main idea here is to use existing code doing similar things, and to move critical stuff out of Nasal into C++ space, via TheTom's cppbind framework.
Integrating RP will take some more time obviously, and it will be primarily useful to people able to wait for a release or "nightly" build-otherwise, this will only be available to folks who build from source in the meantime.

So this is a long-term thing, that may take 2-3 release cycles - depending on how much time we find to work out the details here.
There are some things that need to be done first to make sure that the RP code can pass a review, i.e. to make it entirely optional, a runtime-option, but also to ensure that it behaves well with existing code/features.

But otherwise, there's no good reason why we shouldn't be able to leverage existing FG/SG code to do some things here - adding a ton of Nasal to come up with a half-baked implementation isn't doing us any good. So I would focus on the framework, and not so much on the specifics of terrain/radio wave handling, as that is something that existing code is already doing, and which could be exposed to Nasal via a handful of hooks (classes/functions).

What can be done in the meantime, is using TorstenD's terrain presampler, as previously discussed in this thread.

regarding heat/doppler effects - I would not make this overly complicated for starters, stubs will do to make it work reasonably well - and once it is adopted, and can be refined over time.