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

From: Charles Overy (
Date: Thu Aug 23 2001 - 23:31:54 EEST

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 generation?

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?



-----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 union
> these objects (assuming there are no errors) brings the mightiest
> workstation to its knees. Plus once it is unioned, say you want to make a
> 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 see
> that as a surface. If one pulls in the face data then you are back to stl
> 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, at
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.

James Carruthers
Hydraulic Design
--3D Modeling and Design
--Rhinoceros 3D Sales and Training

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