Newsgroups: comp.graphics
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!orca!mesa!rthomson
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: SunPHIGS's pcellarray
Message-ID: <1991May21.203355.29337@dsd.es.com>
Sender: usenet@dsd.es.com
Nntp-Posting-Host: 130.187.85.21
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
References: <1991May20.203703.24007@philabs.philips.com>
Distribution: usa
Date: Tue, 21 May 91 20:33:55 GMT


[By the way, please try to use 80 character lines -- it really helps
all of us]

In article <1991May20.203703.24007@philabs.philips.com>
	kkt@philabs.philips.com (Kim-Kiat Tan) writes:
> I am trying to display a 2d image using cellarray, however, what
> I get is the outline drawn around my 2d array rectangle), and according
> to sun's documentation, it stated that SunPHIGS supports the minimal
> allowed simulation for the CELL ARRAY primitive by drawing the
> transformmed boundaries of the cell array [...]

The cell array primitive is somewhat of an odd beast and often I've
wondered what it was really good for.  I suspect that it was invented
as a way of getting an image that originated from a raster device to
display on a calligraphic device, however I don't know its ancestry.

It is true that the minimal support for a PHIGS compliant
implementation just has to transform the boundary of the cell array
and do nothing for the interior of the primitive.  In this respect,
SunPHIGS is compliant with PHIGS, but the cell array primitive becomes
pretty useless as you are noticing.  [Was it ever that useful to begin
with? :]

The problem with providing what you're expecting to happen -- a copy
of your "image" appearing on the screen -- is that cell arrays can be
placed on the display surface at arbitrary orientation since they are
subject to coordinate transformations.  Thus to really do this
properly for a "raster image" amounts to texture mapping, which will
be unacceptably slow for interactive applications without hardware
support for texture mapping.

There are several alternatives, though.  If you have anti-aliased
polylines, you can do quite a good job at simulating texture mapping
by using POLYLINE SET 3 WITH DATA structure elements.  Use one a
polyline per scan-line of the source image and place a vertex at each
pixel location in the image.  Choose the vertex colors from the source
image.  By using SET LINE SHADE METHOD structure elements, you should
be able to toggle interpolation of color between vertices of the polyline.

If you don't have anti-aliased polylines, it won't look as nice, but
will have the same effect (anti-aliasing helps most when the polylines
are occupying fewer pixels on the screen than the source image would,
and also in the case where the polyline isn't aligned with the raster
grid of the CRT).

You might also want to try using a quad mesh or triangle strip to
simulate the image, but it will necessarily take longer to render (you
have to scan convert the interiors).  However, with a QM/TS approach,
you don't have any inter-scan-line "gaps" at large magnifications.

						-- Rich
-- 
  ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon
	    Disclaimer: I speak for myself, except as noted.
UUCP: ...!uunet!dsd.es.com!rthomson		Rich Thomson
ARPA: rthomson@dsd.es.com			PEXt Programmer
