RE: Re(2): Point cloud data from rendering - or tooling

From: cwho (
Date: Fri Aug 24 2001 - 03:29:14 EEST

Sam and All,

Perhaps this is the most promising process. Maybe if Elaine or annother
university guru or guress (f?) is listening they might suggest it to a
student as an interesting project as I do not have 5 axis software.

I will give it a go with the resources that I have. A simple test case
probably can be made from any tool path. However, I would need to know what
a scan file looks like so that I could edit the tooling path data to a
similar format. Also I am not sure how to get the tooling software to output
regular points instead of move to points. I can get it to go in absolute
coordinates but on a flat surface I would still not have intermediate
points. . The inStep and direction certainly would be preferable to using
stripped dxf or slt vertices which is what I have tried.

Any help anyone?



-----Original Message-----
From: []On
Behalf Of S Taneja
Sent: Thursday, August 23, 2001 4:25 PM
To: Charles Overy; James Carruthers;
Subject: Re: Re(2): Point cloud data from rendering - or tooling


I think that reverse engineering applications should be able to work with
dense x,y,z points created by 3 axis milling. Points created from each
direction by milling software are like points created in one setting
(direction) of a scanner.

Points generated for each direction must be saved in separate files. These
files can then be imported into reverse engineering software where all the
files will need to be aligned with respect to each other. There must be
enough overlap area for each set of points to facilitate alignment.

Using 5 Axis milling software will parhaps save time as need for alignment
will be reduced.

Sanjeev(Sam) Taneja

----- Original Message -----
From: Charles Overy <>
To: James Carruthers <>; <>
Sent: Thursday, August 23, 2001 4:31 PM
Subject: Re(2): Point cloud data from rendering - or tooling

> James and all,
> I have posted here before about a sort of a shrinkwrap application. That
is exactly how I had initally conceived of the idea but I had never seen any
sort of algoritm that would do it. The idea with the generation of point
cloud data from an existing 3D model was based on being able to adapt and
cobble together existing parts and create a new use.
> I am very sorry to hear that you do not think that a render engine will
work. I had assumed by the term "ray traceing" that the software was
detecting the surface of the model and calculating how a "ray" would bounce
off. All I want is the coordinates at which the "ray" hits the surface of
the model. Here I am clearly demonstrating my ignorance of the underlying
software methodology. Do you know of a library of papers and such that
would help me out with the conceptual models that are used in graphics
> The other engine, that I think I mentioned, is the type of thing that is
being done in tool path generation software. Here the tool is driven over
the surface of a model, totally ignoring what is going on underneath. We
routinely use MillWizzard (becasue it is cheap and simple for everyone to
use ) for milling terrain forms. At first we thought we had to union all
the parts but Mill wizzard does not care if there is one part of 1000,
unioned or not, and I only very very rarely have a problem with any other
STL errors. Perhpas this is a better way to go as the utility for creating
an x,y,z path at a variety of resolutions is already in place. One would
only have to sample the tool path at regular intervals. Does anyone
think this is doable and if the points were generated would any of the
reverse engineering applicaitons be able to work with them?
> Thanks
> Charles
> -----Original Message-----
> From: James Carruthers <>
> To: <>;
> Sent: 8/22/01 9:15 PM
> Subject: RE: Point cloud data from rendering
> > JIm,
> >
> > Thanks for your note. I would be happy to send you a file to
> > illustrate why
> > it is not practical or in many case feasible to "clean up and
> > output an STL"
> > from the original application. Consider 10,000 objects, Many of them
> > interior or partially interior to the building. Just attempting to
> > these objects (assuming there are no errors) brings the mightiest
> > workstation to its knees. Plus once it is unioned, say you want to make
> > change to one of the parts, you have lost the original data and
> > most of the
> > utility of RP.
> >
> > Can you help me out a bit more with what you mean by ""Reverse
> > Engineer" the
> > mesh?" I have tried using Rhino for instance to create a solid from a
> > suface mesh and actually the Rhino site steers one towards
> > applications like
> > Geomagic and Rapid Form. The problem with these programs is that
> > they fall
> > down when the data points are not fairly regular. For example a
> > large face
> > on a dxf mesh has only four points, one on each corner. The
> > algortihms used
> > to surface the data in Geomagic and RapidForm don't like this and dont
> > that as a surface. If one pulls in the face data then you are back to
> > patching just like in programs like MagicsRP. My thinking then is to
> > generate regular suface data from a virtual object.
> >
> > Our end result right now is that we do use Rhino and FormZ to redraw the
> > structures but this, for obvious reasons, is suboptimal.
> >
> > Looking forward to hearing your thoughts.
> >
> > Charles
> Ah, I didn't catch your second message. You need some sort of "shrinkwrap"
> functionality. I don't think a "virtual scanner" is really going to help,
> least not coming at it from the direction of the rendering engine, they're
> very "dumb" and rely on tricks and fakery, they have very little idea what
> they're doing.
> Jim
> ----------------------------------------------------------------------
> James Carruthers
> Hydraulic Design
> --3D Modeling and Design
> --Rhinoceros 3D Sales and Training
> ----------------------------------------------------------------------
> For more information about the rp-ml, see

For more information about the rp-ml, see

For more information about the rp-ml, see

This archive was generated by hypermail 2.1.2 : Fri Jan 04 2002 - 09:57:41 EET