Re: [rp-ml] texturing on 3D data

From: Lee Eisinger <>
Date: Wed Jul 29 2009 - 23:46:57 EEST

Akron Metal Etching as a company that textures molds for the plastics, rubber and die casting industries has dealt the problems of wrapping textures around contours for many years. With the wide variety of textures required in the world of surface finishes, it can be a very complex issue. When CAD systems came into use we thought that our business would be immediately rendered obsolete, many years later we are still here. The advent of the laser also brought along the same concerns, but we are still here.
Most textures are less than .004" in depth and any layer lines caused by the growth of the part will become part of the texture creating a rough surface within the texture as well as the background. If you have to post process the part (ie: remove layer lines) you have changed the geometry of the part enough to prevent acceptable application of a texture to the surface using the dimensional data with which you built the part. Another item is the availability fo textures which are of good enough quality to use for this purpose. We have spent years developing patterns and do so on a continuing basis. Furthermore, in order to produce the detail in these patterns the file sizes become very large often over 1 gig for a 6" x 6" piece.
This is why we developed the Prototex process. We take the parts you grow and finish to dimension and build the textures onto the surface of your parts. The final product can look like a completed part from an injection mold when painted to the desired color.
So far, we have found that in most cases you spend more time and effort trying to program this type of information into a system than it takes to get a professional final result. If you are interested in the Prototex process please view our website,
Lee Eisinger
Akron Metal Etching
  ----- Original Message -----
  From: Stewart Dickson
  To: vinod
  Sent: Wednesday, July 29, 2009 9:36 AM
  Subject: Re: [rp-ml] texturing on 3D data


  I have thought about this problem for a long time. In short, this is a research problem.
  Representing texturing in computer graphics via a binary image-map is a practical response to a fundamental Level-of-Detail (L.o.D.) problem.

  The complete solution is to support evaluation of Displacement-Mapping in the R-P slicer.
  Short of that, extensible, programmable rendering languages, such as Pixar's RenderMan can actually perform
  this slicing in three-space, complete with displacement-mapping and will produce the slices as a set of binary images.

  Once upon a time, the RIKEN Institute in Japan developed a slice-wise interface to the Z-Corp. Z406 color 3D printer. Alas, if only Z-Corp, itself would only support such a feature, then you could certainly evaluate displacement mapping using RenderMan as the slicer.

  Sadly, without such support in software from the R-P vendors, we're reduced to generating Copious Mesh Data
  by explicitly evaluating surface displacement maps in Alias-Wavefront AutoDesk (D'oh!) Maya, which will support this. The problem here is that displacement shaders are typically defined on NURBS models and polygon meshes tessellated from NURBS models are rarely stitched, particularly displacement shading is typically not stitched across NURBS seams.

  Take a look at this: Rhino Displacement tools -- I haven't used Rhino in about 10 years, but it is popular among digital sculptors and it is stitching-cognizant.

  Evaluating displacement maps is integral to surface subdivision, however displacement mapping in subdivision surface representation is not as mature as it is in NURBS modeling.

  Good luck!

  -Stewart Dickson, Visualization Reseaqrch Programmer, Illinois Simulator Laboratory
  Beckman Institute - South Facility, Room 12
  2100 S. Goodwin Urbana, IL 61801
  Ph: 217-333-3923 Fax: 217-244-1827

  vinod wrote:

    Hello RPML users

    Does any one know how to do the texuring on solid file. is anyone having experience in editing texture to STL data?

    Best Regards
Received on Wed Jul 29 23:44:35 2009

This archive was generated by hypermail 2.1.8 : Thu Jan 07 2010 - 08:26:36 EET