glassner (04/21/83)
Gang:
I've been trying to solve a problem for the
last few days, and I think I have about run out of new
approaches. Hence, a letter and hopefully a solution.
I'm currently adding some extra features to a
polygon display system comprised of a high-level input
language and a display tiler for the 8-bit deep, color-
mapped AED 512 monitor.
My problem involves how to provide highlights
on the AED subject to the constraints of also providing
multiple colors and having a 256-color colormap. It
seems to me a real shame to not offer highlights, but
I don't see how to do it. Let me digress for a moment
and offer my analysis of the problem, and maybe something
can grow from that.
The best space I have found to describe this issue
in is HSV space. Then what I provide now for diffuse
reflection is a linear ramp from the central axis of the
HSV model (saturation=0) to the color point the user has
selected as the "object color" along constant hue. Sort
of like this:
---
/ \
/ \
/ + \ where + = central axis of HSV model
\ | / | = linear path to user's color
\ ./ . = color of object
slice of constant hue \ /
---
If I want to provide hightlights then I must account
for the fact that they can appear anywhere on the surface. So
if I model the highlight as pure light-source refelection (all
lights are white by definition!) then I need colors from the
particular color (or saturation of that color) around the highlight
all the way to white. This amounts to another linear ramp from
the saturation at the point surrounding the highlight to pure white,
a line parallel to the value axis.
Now I need one of these lines at every point along the
saturation line pictured above, because the highlight might be
in the midst of a well-illuminated and very colorful (highly
saturated) area, or in a pooly-illuminated (low saturation) area.
To properly interpolate these colors to white I need a ramp to
white (parallel to the value axis) for each color.
So I really need an area of colors, or table:
+---white-----+ (singularity)
! : !
! :<-!--- one of many vertical ramps
! : !
+-diffuse ramp+
A 256-color table gives me 16x16 colors, which I don't
think would be enough. Accomodating four colors lowers that
to 8x8 which I also belive is too little.
The only alternatives I see are to
1) forget about providing highlights,
2) compute the whole picture in 24-bit
RGB color space and crunching it down to 8 bits and a carefully
composed color map for display (which is complicated, expensive,
and time consuming),
3) allow just one color at a time (which
sounds like losing one cue for realism at the expense of another),
4) allow only perfectly polished surfaces (which
would cause highlight aliasing that a monkey would object to!),
5) buy a new, 24-bit framebuffer with working
memory and no synchronous-counter glitches (presumably with the
coupon in my pocket good for $.24 off on a bag of Fritos),
and 6) ask other people for help.
I am currently persuing options 5 and 6.
I would appreciate any help on this problem from near
or abroad. Thanks for your attention...
-Andrew