problems with depthcue ?

[Kurt Akeley]

In article <IRIS.91Feb19131752 at granny.engin.umich.edu>, iris at granny.engin.umich.edu (Yuval Roth Tabak ) writes:
|> 
|> I am developping an application using multiple windows.
|> In one of the windows I am using depthcuing (depthcue, RGBmode,
|> lRGBrange) to display the z-buffer, and I have encountered 
|> some disturbing inconsistencies with the description
|> in the standard documentation:
|> 1. The color range does not seem to be linear with respect
|>    to distances from the viewing position (it seems to be stretched
|>    much more closer to the viewer than further away).
|>    I did use lsetdepth before lRGBrange to set the smae MIN and MAX
|>    values.
|>    -- I was able to get around the problem by playing with the range
|>    in lRGBrange so that the colors change in the depth region that I
|>    am mostly interested in. However, this does not explain the inconsistency.

The problem here is that, while depthcue values are computed linearly wrt
screen z values, screen z values are NOT linearly related to eye z values.
In projected scenes, (i.e. scenes drawn with perspective/window projection
matrixes) screen z values are more closely related to eye z values by a
reciprocal function than by a linear function.  (The exact relationship is
detailed in the artical "Hidden Charms of the Z-Buffer", Iris Universe #11.)

|> 2. When the scene is drawn with depthcue, there seems to be a peculiar
|>    orientation preference.
|>    More precisely, when I rotate the scene around the viewing axis
|>    (by using lookat() and changing the twist angle) the colors in
|>    the window change drastically, also the color `gradient' seems to
|>    be going horizontally in the image regardless of orientation of 
|>    planes in the scene. If the colors represent z-values
|>    (distances from viewing point of planes perpendicular to the viewing axis),
|>    then the colors should not change this way (should they ?!).
|>    Another perplexing effect is that planes that intersect each other
|>    in the scene have different colors (in the depthcue window) at the 
|>    intersection line -- this is more puzzling since a similar window 
|>    displaying the same scene regularily displays the scene correctly, i.e. 
|>    the z-buffer itself is working properly.

You mention above that you specify different ranges values for lRGBrange and
lsetdepth.  While this may help with the problems of non-linearity, it hurts
when it comes to consistency.  The reason is that screen z values are converted
to colors only at vertexes, not at each pixel.  Thus, any primitive that
crosses the near or far plane specified to lRGBrange will interpolate
"incorrect" pixel values, because one or both ends will have been clamped
to values off the linear ramp.  (In other words, by limiting the linear region
of screen z to color mapping, you have changed that mapping from linear to
piece-wise linear.  Linear interpolations between samples of a piece-wise linear
function are not consistent with the actual piece-wise linear function values.)

|> 
|> If any body has encountered similar problems, and/or if someone can clear
|> some of my ignorance, I would appreciate it.
|> 
|> Yuval
|> --

The moral, as usual, is to minimize the ratio of the distances to the near
and far clipping planes, as specified using the perspective function.  The
closer this ratio is to 1.0, the more linear will be the relationship between
eye z distance and screen z distance, hence the better both the z-buffer
and functions of the z-buffer (such as depthcue) will work.  Unless your data
consist of many very small primitives,  specifying a piece-wise linear depthcue
mapping will result in obvious depthcue consistency problems, and therefore
isn't a good idea.

-- kurt