Sensor simulation is possible using Performer and OpenGL, texture lookup tables, noise effects, automatic gain control and convolution are demonstrated here.
Typical visual simulation scenes are designed with the visible spectrum in mind and the associated display technologies like colour CRTs. There are other types of simulation for non visible wavelengths where an artificial sensor is used to detect radiation at longer wavelengths and present them either to a human operator or some digital control system. Both of these scenarios, called man in the loop and machine in the loop, give rise to a wide variety of simulation requirements which vary greatly in fidelity. There may for example be a requirement for a simple low resolution appended visual trainer for some kind of crew gunnery trainer where some representative range of brightnesses is required with a few effects like noise all the way up to an extremely high fidelity multi-resolution high bandwidth high precision multi-band simulation with realistic physically based atmospheric and radiation model.
Every thermal simulation begins with calculating the radiance of the database for a given band of wavelengths, this is analogous to the component brightness of red, green and blue colours in visual simulation, but unlike the visible spectrum there and no standard set of wavelength bands for sensors and often there is just a single band. This radiance may be calculated offline prior to the simulation of form a part of the simulation with dynamic environment and realistic material properties. A simulation may contain a combination of different sources of data, some measured, some simulated offline and still others calculated dynamically. The calculated information can be stored as texture information or polygon/vertex information of a combination of both. The quality of information is critical since it is a common requirement that this information be processed or enhanced after rendering while retaining sufficient precision to avoid artifacts. This means that internal formats like GL_LUMINANCE12_EXT, GL_LUMINANCE16_EXT, GL_LUMINANCE12_ALPHA4_EXT, GL_LUMINANCE12_ALPHA12_EXT, GL_LUMINANCE16_ALPHA16_EXT are extremely important for this type of simulation since they offer enough precision to permit significant processing before quality loss becomes an issue.
In our example we have an object which has temperature described by a single component texture map nominally holding radiance information, this radiance map is applied to white polygons to give a radiance mapped object for a single band.
When dealing with sensors designed to react to a range of inputs and temperature ramps which may vary over time it is usefull to be able to map arbitrary temperature or material properties to a particular radiance or to determine sensor response to a particular radiance value. Another obvious use is the application of white hot and black hot displays for a single set of radiance values. This is easily done for texture information by mapping one table of input texture values to another arbitrary table of output characteristics, so a linear temperature gradiant may be used to look up a sensor response profile or to completely invert the intensity to produce a blackhot image as shown below.
The OpenGL calls used in the example are:
The one dimensional table of data contains the arbitrary sensor profile and the look up is extremely fast on Indigo2 IMPACT, Octane, ONYX and ONYX2 systems. In our example this table is applied in the draw callback around the call to pfDraw.
Most sensors have at least some means of automatically adjusting the sensitivity of the receptor to a range of brightness. A simple image readback mechanism creates a feedback loop which can easily perform automatic gain control, as shown below the same image with different gain and bias settings gan have a dramatic effect on the visibility and regognizability of an object: This code reads the framebuffer a line at a time and tries to cumpute the minimum and maximum screen brightness which is used elsewhere to recompute the lookup table profile, note that only the green component is read since the display in monochrome. This code is fairly inefficient on our hardware due to the overheadof so many glReadPixels so it's probably worth experimenting with trading a reduced number of calls to this function against reading more data.
Noise due to stray thermal radiation or sensor artifacts is another required feature most types of noise are easily added in the image generator using image writes or textured polygons, our example just uses a blended glDrawPixels with a random offset into an oversized data array, there are hundreds of ways to achieve different types of noise and this is just presented as one simple example.
The application of convolution filters over a rendered sensor image, is extremely usefull for simulating environmental, optical and image processing effects. Using OpenGL can give access to extremely rapid hardware accelerated convolution filters in the pixel processing path with the right implementation such as Reality Engine2, Infinite Reality or MXI. We can therefore apply programmable convolution kernels of various sizes to any image in the framebuffer by transferring that image through the gl image pipeline with an operation like glCopyPixels. These arbitrary filters are usefull for high pass and low pass filters as well as some more exotic filters. A variety of results are shown here:
It is easy to apply a convolution kernel to the image processing path:
To apply this convolution to an image is now a simple matter of passing the image through the imaging pipeling, we have some choice here, glCopyPixels and glDrawPixels will have the same effect but glCopyPixels shouldn't have to read the image back to the host, the relative performance should be tested on the target platform before deciding on either. Note that the convolution will be applied to image reads as well as image writes so the convolution should only be applied for the write portion for the image transfer. In the case of glCopyPixels only one convolution is applied for the single pixel transfer.
Not that above only a single component is read and drawn as luminance format, this should save bandwidth and processing time an alternative to glDrawPixels is to use glCopyPixels:
|
Corporate Office 2011 N. Shoreline Boulevard Mountain View, CA 94043 (650) 960-1980 |
U.S. 1(800) 800-7441 Europe (44) 118-925.75.00 Asia Pacific (81) 3-54.88.18.11 Latin America 1(650) 933.46.37 |
Canada 1(905) 625-4747 Australia/New Zealand (61) 2.9879.95.00 SAARC/India (91) 11.621.13.55 Sub-Saharan Africa (27) 11.884.41.47 |