Look at http://www.cs.cmu.edu/~quake/tripaper/triangle0.html
Then make a search on Delaunay and Triangulation.
There really is a heap of stuff to look at on the subject but I have yet to
find a MS Win program (lots of Unix stuff)
I really think this material could be useful within POV.

David

Charles Fusner <cfu### [at] enternet> wrote in message
news:38B1B078.69A22723@enter.net...
> OK, I'm about 90% done with the experiment I described in my earlier
> thread "Simulated Surface Scanning". First I'll digress to say that
> I doubt this technique will ever practically yield more than medium
> quality results. Even with relatively simple test targets, it leaves
> cracking and incomplete scanning artifacts except at the most
> rediculous of mesh densities. The technique is especially ill
> suited to sharp edged surfaces, like the edges of a box, prism,
> or the flat top and bottom of a cylinder. A *real* solution would,
> I'm afraid, require being able to tailor the tesselation to
> specific primitives, and even then, the difficult mathematical
> prims would still be as much a problem as ever.
>
> Now, along the way, I encountered a few interesting things, like
> the fact that the trace() function doesn't like being used against
> mesh or mesh2 objects (it crashes MegaPOV entirely the instant
> such a situation is encountered) although it doesn't seem to mind
> an union of triangles (so it's definitely the mesh structure
> trace() doesn't like, not the triangles themselves). I also found
> that 3DWin doesn't like negative vertex references in OBJ files,
> as described in the OBJ file specs (crashes 3DWin to attempt to
> read such a file) So for practical reasons I decided to stick
> with RAW output.
>
> I also worked through a half dozen basic misconceptions I had
> about mesh geometry just to get this far, so I was fairly pleased
> up to this point, medium quality scans not withstanding. Even if
> the meshes aren't useful as anything but a scaling and positioning
> references to make other modellers easier to use when building
> specific objects for POV, it still might be of some value. Then,
> I tested the output results, and encountered something I have
> absolutely no idea how to explain anymore, so I'm hoping some mesh
> expert here can at least explain it to me:
>
> When I import any of the meshs I obtained through scanning into
> 3DWinOGL (or Poser 4 as a prop object) I get a mesh that seems
> to be missing about every other triangle. After paring it down
> to a simple handwritten file contain just two triangles and
> rotating the view around, I reasoned it has something to do
> with normals, since in the shaded previews, triangles vanish
> altogether when viewed "from the back" so I imported two copies
> of the same mesh into Poser, the second with "Flip normals"
> checked, and sure enough, the second mesh fills in the gaps left
> by the first, so I figured, "oh, so that's what flipped normals
> look like." But I'm scanning as smoothed RAW, therefore supplying
> the normals which resulted from the trace() function, so...
> why should they be imported with every alternate polygon having
> flipped normals when I supplied it with normals that weren't
> flipped? This doesn't happen with OBJ and 3DS models I
> have obtained from other sources, so I even tried using
> file i/o to output OBJ files directly (to make sure it wasn't
> something 3DWin was doing along the way -- it wasn't) so it's
> got to be something specificly having to do with what I'm doing
> during the trace() scan export.
>
> I realize if all this is good for is scaling and position
> references, then all I really need is a mesh that delineates
> the outline of the shape, yet, it bothers me that I can't find
> a reason for this behavior since it demonstrates some gap in
> my knowledge that I'd like to fill in.  So I ask any and all
> mesh experts: Is there something else I don't know about meshes
> normals and quick shading that might cause this?
>
> Charles
>

Post a reply to this message