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

Philippe Debar wrote:
> 
> 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

Aha... this is a possibility I'll have to try. I wasn't aware
that this might make a difference, but if it does, it's possible
it could in fact be the problem. I use a rectagular strip of
test points that get output if valid triangles are found, and 
not being aware the order would matter, made no special effort
to put them in any particular arrangement at output time. I
just confirmed the normals are being recomputed "for" me, because
the normals that got output from a converted RAW file didn't
match up with the ones supplied in the source file.

So.. if the converters/modllers are throwing out my normals and 
computing their own based on the order of the point output... 
well, it's easy to see how that might create the problem I'm 
seeing. I haven't got a lot of time this evening, but it looks 
like tommorow I've got a new set of experiments to run.

Thanks!
Charles

Post a reply to this message

Peter Popov wrote:
> I can't help you much on the other issues but have you tried this in
> Rhino?
> 
> Render -> Options -> Render Tab -> Backface checkbox

Oh, that's ok, Peter. Rhino is the one package so far that is 
presenting the test object the way I expected so no mods needed
there :)
 
> As of fixing the normals, try exporting to non-smoothed triangles and
> give the John's SSS (Surface Subdivision Suite) a try.

Hmm... yes, I ought to try combining some low res scans with a
little VanSickle magic to see what happens. Although, if the
converters and modellers are throwing out my normals, I'll
still have to overcome that problem separately, but Phillipe
just gave me a new angle to try there, so (crosses his fingers)
maybe I'll actually figure this out yet! :/

Thanks
Charles

Post a reply to this message