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

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

Charles Fusner wrote:

> 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.

In the import options dialog do you have the unify box checkmarked ?

I believe this is supposed to unify the normals of the triangles
as it reads in the mesh. If you haven't tried it do so now.

If you have it checked try unchecking it and see if it makes a difference.

You might also give Crossroads a whirl. Is has a normalize triangles
option that might or might not help.

Bout all I have to offer...

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Mon, 21 Feb 2000 16:39:04 -0500, Charles Fusner wrote:
>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) 

This has been fixed in either the next or the current MegaPOV. It
was mentioned recently in the unofficial.patches newsgroup; check
there to see what its status is.

>why should they be imported with every alternate polygon having 
>flipped normals when I supplied it with normals that weren't
>flipped?

It's possible that it ignores the normals you gave it and instead
calculates its own using the cross product of two sides of the triangle.
Try reversing the direction of all the triangles and see if it has
any effect.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Check that the modeller is not performing back-face culling.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ron Parker wrote:
[re: trace vs. mesh crash]
> This has been fixed in either the next or the current MegaPOV. It
> was mentioned recently in the unofficial.patches newsgroup; check
> there to see what its status is.

Ah! Good to hear! I've been working around it by using an union
of triangles for the culling tests, but better to have it work
with the more modern (and efficient) mesh syntax as well. Guess
I'm too far behind in discovering it to be of help pointing it
out... you POV-Teamers are too quick for me :)

Charles

Post a reply to this message

Ken wrote:
> I believe this is supposed to unify the normals of the triangles
> as it reads in the mesh. If you haven't tried it do so now.
> 
> If you have it checked try unchecking it and see if it makes a difference.


Arg! So close! I checked unify and indeed, it did make a
remarkable difference both to the preview and the export, but
although it made the top 4/5ths of the test object solid, the
underside was still inverted (although, to its credit, it was
now inverted consistantly for all polygons across the bottom,
which, I suppose qualifies as an improvement in a weird, 
Dilbertian kind of way <g>)
 
> You might also give Crossroads a whirl. Is has a normalize triangles
> option that might or might not help.

Tried it. I've got both 3DWin and Crossroads installed, and
I'm getting pretty much equivalent results with Crossroads
conversions. The smoothing results don't help (although its
no worse than before)

Since my original post, I've tried a few tricks and outright
deceptions, like deliberately reversing the normal on every
alternate triangle (Poser didn't care or notice, and 3DWin did 
the software equivalent of saying "what the @#$@#$" and locked up
Windows) and I haven't found an option for backface culling as
Warp suggested, so my tentative opinion at this point is to go
with Ron's idea that the normals I supply are being for some
reason thrown out and new ones computed "for" me. Oddly, Rhino
couldn't care less, and both its shader and render modes show
a solid object, so I'm guessing it has something to do with what
manner of shaded preview is used by the package in question.
It just puzzles me that OBJ files I've obtained elsewhere don't
do it. I've even tried converting them to smoothed RAW and then
back to OBJ, so it isn't the process of going from RAW to OBJ,
so right now I'm doing a slow laborious line by line analysis 
looking for anything that isn't like my output. Current odds 
are 9:4 I get bored before I find something though :(

Thanks all for the suggestions. If I figure it out, I'll
follow up on this post.

Charles

Post a reply to this message

On Wed, 23 Feb 2000 21:12:09 -0500, Charles Fusner wrote:
>Ron Parker wrote:
>[re: trace vs. mesh crash]
>> This has been fixed in either the next or the current MegaPOV. It
>> was mentioned recently in the unofficial.patches newsgroup; check
>> there to see what its status is.
>
>Ah! Good to hear! I've been working around it by using an union
>of triangles for the culling tests, but better to have it work
>with the more modern (and efficient) mesh syntax as well. Guess
>I'm too far behind in discovering it to be of help pointing it
>out... you POV-Teamers are too quick for me :)

Perhaps, but remember that MegaPOV is an unofficial patch, so the
POV-Team doesn't really have anything to do with it (other than 
having a couple Team members contributing to it now and again.)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On Wed, 23 Feb 2000 21:44:51 -0500, Charles Fusner <cfu### [at] enternet>
wrote:

>Oddly, Rhino
>couldn't care less, and both its shader and render modes show
>a solid object, so I'm guessing it has something to do with what
>manner of shaded preview is used by the package in question.

I can't help you much on the other issues but have you tried this in
Rhino?

Render -> Options -> Render Tab -> Backface checkbox

As of fixing the normals, try exporting to non-smoothed triangles and
give the John's SSS (Surface Subdivision Suite) a try.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

Wild idea form someone who does not know much about all this - I:
Is the order in which the vertices are written always the same relative to
the direction of the normals? Paraphrase: looking always from the same side
of the mesh (inside/outside), are the vertices always written in clockwise /
anticlockwise order? I think some file formats / programs use this order to
determine inside/outside.
I do not know if this helps, but I hope it does


Povingly,


Philippe

Post a reply to this message