Bernard Leclerc (bleclerc++at++cae.ca)
Thu, 4 Jan 1996 19:01:05 -0500
It takes quite long to describe the problem I'm faced with. For that reason I
decided to describe it in a separate document attached to this mail.
If you feel you could contribute to solve the problem of a 9-channel visual
system requiring dynamic shadowing and focus effects, then take a look at the
attachment.
I really welcome any comment that could help me with this project...
Thanks in advance!
--
___/ | ___/ Bernard Leclerc e-mail: bleclerc++at++cae.ca
/ / | / Systems Engineer voice: +1 514 341 2000
/ / | __/ CAE Electronics Ltd. extension 2275
/ / | / 8585 Cote De Liesse fax: +1 514 340 5496
/ ____ | / P.O. Box 1800
_____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4
An important customer requires a visual system capable of displaying
nine different views of the same database. These views are 3 VGA
channels at 30 Hz (called CCTV), 5 VGA channels at 10 Hz and 1 high
resolution channel at 30 Hz.
A CCTV channel is used to simulate a Closed Circuit Television
cameras. For that reason, we need to simulate the effect of adjusting
the focus and controlling the aperture (iris) and exposure. Also, the
environment simulated requires the addition of dynamics shadowing for
the proper training of the operator. Shadows from two light sources are
required on CCTV views. It is allowed to reduce the update rate when
dynamics shadowing is enable, but a minimum of 5 Hz must be
maintained.
We decided to base the visual system on an ONYX with two RE2, each pipe
with four RM5s and a MCO. By configuring the MCO with 6++at++640x480_60 and
2++at++640x480_60+1++at++1280x1024_60, it is possible to obtain the required
number of channels.
On a camera, since lenses are not perfect, adjusting the focus
introduces some blurring in the image for objects closer or farther
from the focal plane. This is called depth of field. In order to
implement this effect, the image is first created as usual and then
post-processed by reading both the Z-buffer and the normal frame
buffer. The processing consist in blending every pixel with its
neighbours according to the pixel's depth. If the blending wasn't
dependant of the pixel's depth, we could use the normal GL convolve()
function. Unfortunately, it's not possible. So we must bring the image
in the main memory and process it.
We tried to read the Z-buffer but it took so long we decided to
transfer the relevant portion of the Z value into the 8 bits of the
alpha component. After the transfer is done, we have a RGBZ image
instead of the normal RGBA.
We also did some investigation on how fast can we read/write the frame
buffer to/from the graphics card. It appears to me that the ONYX
graphics subsystem is connected to the main bus through the FCI
interface. This bus runs at 160 Mb/s only. So I computed the
theoretical transfer time of a 4-component VGA image and obtained
640 x 480 pixels x 4 bytes/pixel
-------------------------------- = 7.3 ms
160 Mb/s
We did some timing and measured approximately 10 ms. Which seems
reasonably close to the predicted transfer time. So I decided to use
that figure for my estimate. Here is a summary of the timing I've used:
rectcopy from Z buffer to Alpha component = 5 ms
lrectread 4-component RGBZ image = 10 ms
lrectwrite 3-component RGB image = 10 ms
Note: 1) RBGwritemask() is used to preserve the RBG value while
transfering the Z value into the alpha component.
2) Theoretically, writing a 3-component RGB image should take
5.5 ms. However, I purposefully decided to use the same
figure as the read operation.
The time necessary to perform the actual image processing is limited to
less than a frame since a separate process (called IMGPRC) will do the
job while the DRAW process continue with the next image. This
architecture adds one stage to the Performer pipeline, the latency is
increased by one frame. The DRAW process will lrectread() frame "n" and
lrectwrite() frame "n-1" which is expected to be complete at that
moment. Here, the DRAW process will spend approximately 25 ms
transferring back and forth a VGA image.
Next, casting shadow requires multi-pass rendering for every light
source. We assumed it would take the same time to draw the scene from
the light source point of view than it takes to render the same scene
from the normal eye position. Since, two light sources are casting
shadows, the channel will be rendered three times: one time for each
light source and one time for the eyepoint. Remember that Performer 2.0
has formal support for shadow through the appropriate pfLightSource mode.
We also budgeted it would take 5 ms to draw a medium complexity VGA
scene and 10 ms would be necessary to draw the same scene at high
resolution. Given these numbers, here are the estimated time:
a) one CCTV without shadow = 5 + 25 = 30 ms
b) one CCTV with shadows = 3*5 + 25 = 40 ms
I guess you have noted that one CCTV without shadow takes almost the
whole period of time available if we want to update at 30 Hz. So, we're
in trouble since other channels must be drawn as well on the same pipe.
I have two questions for you folks:
- Have you heard of a different approach than the one described
here for simulating the focus effect?
- How can we render 2 channels at 2 different update rates when
they're rendered on the same graphics pipe?
We've already considered simulating depth of field (focus) with a
multi-pass technique as described in the OpenGL dof.c example. However,
we found the results rather poor and extremely costly in terms of time
to draw.
We've also noted that a third graphics pipe would be necessary to
handle the three separate CCTV views at 30 Hz. But even that will not
give us enough time to render other channels on the pipe.
For those of you still reading at this point, I appreciate the fact
that you took so long of your time to help us with that problem.
Any help would be greatly appreciated -- I really mean it ;-)
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:13 PDT