Joseph,
In a message dated 98-05-04 20:43:13 EDT, you write:
>i think your description of system sounds like a LOM-type of machine like
>Helisys or the last year new system from Texas which shows the system
>laminating a car model(cannot remember the name suddenly).
Yes indeed. {More on THAT at a later date.}
> the 1st Step
> ~~~~~~~~~
> but maybe the first step which we should look into is a new STL file with
> colour definition. shall it be only the 8 major colours defined by integer
> (1,0,0) or shades of the colours using real numbers???
This is a very interesting area, as Michael Rees also pointed out. Although I
admit severe programming limitations, I've given this some attention and
would like to pass along my thoughts, for what they may be worth. Of course,
it will take a great deal of expertise and effort to put any strategy into
practice. Each different system (powder/sheet/resin/extrusion/etc) will of
course have to analyze the data in a different way in order to direct the
layer-by-layer operations to the particular machine. First priority should
probably be a general strategy which would allow any such system to deal
efficiently with both shape and color - and users to select the system which
is most appropriate to the job.
The STL format was apparently designed to allow for a facet attribute such as
you describe. This would seem the logical approach for relatively simple
coloration - in which different models or even different facets of models are
built in appropriate colors. It would not, however, allow for complex
variation within facets. An obvious next step would be to reduce facet size
to allow the required color variation - but this would be computationally
intensive, probably impractical and perhaps illogical for the eventual "goal"
of 3D printing - photoresolution color.
If one explores the area of more complex color variation, he'll quickly reach
the question of whether the required data is stored along with the shape data
or in some companion format. Of course there are established alternatives
such as manipulation of "voxels," as used in medical imagery. Such methods
are appealing because they could allow an ideal "3D bitmap." Accepting the
STL dominance as a demonstration of its power, however, I propose a compromise
alternative.
First, it just doesn't seem practical to combine complex color data directly
into facet descriptions. Alternatively, it would be possible to handle all of
the required color data with six "elevation" views of a typical model
(postponing issues of obscured surfaces). This could be thought of as using
each elevation to "compress" one of the XYZ variables to "zero" - thereby
taking it "out of play." This could have a special benefit in the processing
described below.
Couldn't the six elevations described be formatted as "lookup tables" -
available for determining color at the appropriate point on the perimeter of a
layer being analyzed and fabricated? The software would be designed to
select the appropriate one of the six elevations by determining the
orientation of the normal of the facet being sliced. When the required data
is "looked up" on a particular elevation, it would not matter if the shape had
been slightly altered after the elevation was created - because the "depth"
was automatically "compressed out-of-play" in order to avoid this problem.
(Otherwise, even the most minor adjustment of mesh tolerances could wreak
severe havoc?)
For crude example, as the program works its way around a typical slice, the
facet normals would tend to vary around 360 degrees. Depending on the shape,
various conditions would exist at the transition angles (between views) -
duplication of data would sometimes allow for the data to be taken from more
than one elevation. For another example, a perfectly "level" facet could be
colored according to data on a either a "top" or "bottom" view, depending on
facet normal orientation, up or down.
Speculating even further on the elevational lookup tables, it might be
possible to include some or all of the STL triangle vertexes as "nodes" which
would allow for the program to "rubber sheet" the color data in response to
changes which may be made in the shape definition (such as stretching a brick
pattern when lengthening a wall on an architectural model, or shifting a
freckle when shortening a nose on a portrait sculpture?).
If none of this is directly helpful, I hope it stimulates some other
"brainstorm" which is more effective in advancing us toward the future
mainstream medium of 3D computer hardcopy. The challenge of handling both
shape and color is unavoidably complex but should not be insurmountable.
Discussion should help.
> the 2nd Step
> ~~~~~~~~~
> i don't know how to begin with this.....leave it to the developers.
It'll come.
Norm Kinzie
(781) 444-6910
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:45:30 EEST