Radar Display Imaging

I’ve coded up a working simulation of a radar PPI display using pbuffers (still working on a FBO variant). Everything works great, fast frame rates. Runs on both a high-end Dell GNU/Linux system as well as my Apple Powerbook. I’m taking in ~4600 samples per radial (with 5000 radials per rotation) and rendering them onto a texture, with a simple linear mapping of sample value to color – 0=RGB(0,0,0) --> 8192=RGB(0,FF,0). I have another texture filled with black but with an alpha gradiant that provides a simulated phosphor decay for older pixels. This texture gets rotated in sync with the radar beam. Looks pretty and is very fast.

The first improvement I’d like to make is to make the coloring and decay more realistic. For the phosphor, I’d like to change to a white at the high sample value, with the red and blue values decreasing rapidly, while the green value decreases at a slower rate. Any ideas on how to achieve this?



How about posting some movies or screenshots so we can comment on your existing stuff, too? :slight_smile:

Backward compatible solution:

  1. change your color-mapping function to produce 0=RGB(0,0,0) --> 8192=RGB(FF,FF,FF) - use linear function for green and non-linear for red and blue.
  2. apply your black texture in two passes:
    -first pass - use: glColorMask(TRUE, FALSE, TRUE, TRUE);
    -second pass - use: glColorMask(TRUE, TRUE, TRUE, TRUE);
    You can use glColor(0, 0, 0, fadeSpeed) to modulate alpha channel of black texture to manipulate fade speed.

Second solution is to use dependent texture reads which you can implement using shaders. Will require GeForce 3 class hardware.
You can also use GLSL shaders (requires GeForce FX / Radeon 9500 ompatible hardware).

Thanks for the responses. Sorry for the delay in writing back. First, here’s a movie that shows my display in action with sample data:


I’ll check out the use of glColorMask. I definitely have horsepower to spare with additional passes. Right now on the Linux box that is running this live, we are seeing 350 fps at full speed.

I was contemplating using a shader to do this, but I’m still learning that aspect of GL. Thanks again for your inputs.


Page seems to be broken - HTTP error 500 ((

Interesting, but how do you deal with radar shadow areas? And how do you cover long distances (100 miles, for example), even very small metallic building (which woul be less then 0.001 pixel even with 4096 texture resolution) on 100 miles would get very bright point on radar view.

Or may be, I’m talking on navi radar, and you mean something else…

Anyway, waiting for screens or movies!

Jackis, just checked the link myself. Did not get the 500. Perhaps Apple’s site was down for maintenance.

Not sure I understand your comment about resolution, but one cannot get finer resolution than that provided by the radar in terms of range gates and azimuth encoding.

You can still plot returns on as averages on even a one pixel display, but your ability to determine accurate position is a little problematic. For surveillance radars such as the one I’m working on (which can see over 300 km), one usually gets several hits during one rotation, and the hits are far enough apart in azimuth to fall on several pixels, even at 1024x1024 texture sizes.

For my display, I’m not looking to provide a replica of what is being illuminated, only to detect with some level of accuracy. Using the mouse pointer, one can use simple trig to get a pretty good fix on the target, but nothing like milimeter or even meter accuracy. And one can always use texture tiling to increase stored resolution, at the cost of blitting additional bits during each refresh.

Update: I had been using pbuffers to encode and store data from the data receivers, since that is what Qt supported on my PowerBook. However, I just finished getting framebuffer objects to work. Not sure why Qt reported FBOs as unavailable. I did get a noticable bump in performance with the change.


OK. Here are some screen shots. How long are flickr URLs good for?

Here is a shot of the PPI display in glorious green. Note the realistic phosphor fade :smiley:

And here it is in false-color, along with some fake target plots I manually placed. They fade out over time.

that looks nice, but why display it like that at all? ( unless for a ascetic oldfashioned feel)
surely that display method was only used due to the limited technology.

anyways since it looks like youve solved your problem.
in a 3d world flightsim etc, what the best method to implement a radar?
im using the following, which is a forward + rearview but this doesnt display dist or size, (perhaps can be shown with pixelsize or alpha)
does anyone know of any decent 3d radars used in games or elsewhere?

Back in 1993, X-Wing had those radars, same as yours, with distance coded as luminosity. dark red = far, red = medium range, bright red = near.


Pretty effective.
Just find the darkness vs. distance scale adapted to the game.

thanks again ZbufferR, i think ill do that, also placing the front/back viewpoints on either side of the screen is a good idea as well. i might try a 3d radar as well (just to see how it looks, prolly gonna be less useful than the two 2d ones)

Something simple like drawing the sweep leading edge twice with a different color when you actually display the radar and using modulate with vertex color and a blend with independent fade would do it. You could also just render to a sweep wedge each frame with all contents to the texture and erase the old, leaving the persistent green to fade over time.


Has anyone ever really improved on the Elite system:


It’s an elipse in your plane of orientation with bars extending up or down from a point on the planeto a blip for the targets. It’s very intuitive and gives you the full spatial relationship.

These days you could do a nice high quality 3D version with blending color and mabe even velocity or ‘ion trails’ etc.

To render it you need the object locations in eye space, it’s basically an eyespace representation, but then so are all 3D radars.

I second that. Elite’s scanner was bang on the money.

theres one game i never enjoyed (lots of my mates did though)
theres quite a bit of info on the net about elite (being the cult/mainstream hit it was)
but nothing that describes the radar

thus if i understand it the oval represents the xz plane, with the lines representing how far along the y axis the spaceships are
thus in the screenshot http://www.mobygames.com/game/amiga/elite/screenshots/gameShotId,132078/
theres a spaceship to the right + slightly below,
one to the left + a further distance below.

the radar ive got at the moment makes the game a bit to easy, ie just move the green dots into the cross + press fire (u dont even need to look at the main screen)

that looks nice, but why display it like that at all?
You nailed it smack dab on the head there, zed: it looks nice :wink:

I’m a bit nuts about the old CRT look and feel. My favorite example of that is the teletype display console in the movie Alien (dededlelateeededeep…ch ch ch dom). That movie is a beautiful blend of the old and the new, and it’s done in a way that really makes sense, somehow.


Definitely the fade is an anachronism, but try telling that to controllers who are used to it. Its weird. Some of them just feel lost without it. And there is a checkbox to disable it.

As to the game depictions, they look very cool. But this is not for a game. Its for a real-world radar. I do like the thought of a 3D effect, if only for the cool factor. Around here, one has to be careful to show “wow!” stuff only when it is really useful, or with the caveat that it is only eye candy. I had to do that once with a VTK visualization that showed a days worth of traffic for DFW airport in Texas. The graphic looked way cool, and one could even see some surveillance anomalies, but immediately people began criticizing it for its lack of analytical utility. Duh. But that is liike criticizing a beautiful painting because it does nothing.


What if looking at it from a display-POV? Seems that min(width/2,height/2) will be smaller than 1024. If true, and assuming 16s/revolution, can you use a 1024^2 8-bit luminosity (i.e. only 1MB vram used) texture and refresh_rate*16 triangles? (16 = 4 seconds/quadrant * 4 quadrants)? Example: 960 triangles @60Hz.

That way you could update (and upload) only one line of already scaled- (and mixed-) down sample->texture data each frame (assuming you already scale-down and mix in software), and render it as a kind of fan, compressing the left edge of the texture to the single center-point, and evenly spread the right edge to the displayed circle.

That way, I think, you could then using a tweaked-the-hell-out-of static falloff texture multiply the echo texture with it, and get whatever falloff you want (so long as it’s 8-bit). Actually, I suspect the falloff could be smaller than the echo texture, and save you both memory and bandwidth there too.

Just an idea. If it works, I suspect it’d work even for GL 1.2.

As to the game depictions, they look very cool. But this is not for a game. Its for a real-world radar. I do like the thought of a 3D effect, if only for the cool factor.
i cant really see it helping much, 2d stuff for a lot of things is a lot easier to see the info with. unfortunatly a lot of games (like mine quake etc) are just simply line enemy up in sights + press fire (fancy graphics are all just windowdressing), thus actually sticking in the radar shows how basic the game premise is, thus a 3d radar hides this from the player a bit.

Around here, one has to be careful to show “wow!” stuff only when it is really useful, or with the caveat that it is only eye candy.
well of course then u could spit back at them the above radar shot, the fade out doesnt show them anything useful, better to have the trails showing the direction or height, that should shut them up :slight_smile: ie they cant have both viewpoints