When I read about the "project and rubber-stretch image data on facetted
geometry" - idea, I fee uncomfortable.
The problem is like in 3D scanning - you have to solve the problem for
all geometrical cases, including undercuts, hollow parts, complicated
technical geometry or even medical files derived from CT data.
You are only able to apply this technique in a very limited region where
the surface is convex, i.e. one bitmap for each STL triangle.
What do you think ?
Regards
Juergen Bauer
Siemens AG, EC CS A PD, Siemensstr. 13, 67346 Speyer, Germany
E-Mail Juergen.Bauer@spy.siemens.de
Tel. +49 6232 30 2501 Fax +49 6232 30 2110
> -----Original Message-----
> From: Nkin [SMTP:Nkin@aol.com]
> Sent: Tuesday, May 05, 1998 2:45 PM
> To: istpl@singnet.com.sg; rp-ml@bart.lpt.fi
> Subject: Re: Selling RP, color questions
>
> 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/
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:31 EEST