i posted a closeup of a section of the xwing scene i posted last month. 
it shows the torpedo tube area, but the pieces used to cut out of the
mesh show up as semi-transparent objects (which are kind of hard to
see).  i'm not sure what is going on.  the two tubes (one on each side)
are each cut with a cylinder and a sphere.  the four items are in one
csg union together under a difference with the mesh fuselage.  should i
union each set seperately so one tube is cut at a time?  does it matter
that the left tube doesn't touch the right tube but they are in the same
union?  might adjusting the inside_vector help?  and if i animate the
ship's movement, will i need to change the inside_vector to prevent such
errors?

and on another note, is it possible to texture individual triangles in a
solid mesh, or do i need to convert to mesh2?  if so how?  or can i use
uv mapping?  how?

  TIA.

Post a reply to this message

by the way, i know the image is hard to make out.  you may have to
increase monitor brightness.  sorry about that.

Post a reply to this message

"ryan constantine" <rco### [at] yahoocom> wrote...
> might adjusting the inside_vector help?

Yes.

> and if i animate the
> ship's movement, will i need to change the inside_vector to prevent such
> errors?

Possibly.  This implementation of solid meshes has some problems, as you can
see.

> and on another note, is it possible to texture individual triangles in a
> solid mesh

Yes.

>, or do i need to convert to mesh2?  if so how?  or can i use
> uv mapping?  how?

Yes.

Check the official POV documentation for instructions on texturing
individual triangles in a mesh object.  Just add the "uv_mapping" keyword
and the individual textures will be uv mapped.

-Nathan

Post a reply to this message

In article <39ab26ff@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Possibly.  This implementation of solid meshes has some problems, as 
> you can see.

Just an idea, but could it help to test multiple times with different 
vectors to avoid these errors? Just use the result that the majority of 
vectors produce.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> >, or do i need to convert to mesh2?  if so how?  or can i use
> > uv mapping?  how?
> 
> Yes.

which?  all?  right now i have a regular triangle mesh converted from
spatch.  i lost the spatch model so with your vague Yes above, i'm not
sure if i need to convert or not and how to do it if i do.  i assume
mesh2 is supposed to be made with a conversion tool and not by hand due
to the large number of triangles.
 
> Check the official POV documentation for instructions on texturing
> individual triangles in a mesh object.  Just add the "uv_mapping" keyword
> and the individual textures will be uv mapped.

i read it, but i'm a little foggy.  as a regular mesh, there are no face
entries right?  unless i'm blind i only saw instructions for texturing
mesh2 objects.  is there a uv mapping tut' out there?  i thank you for
your help.  modelling is fairly easy, but texturing is more difficult
for me.

Post a reply to this message

> > Possibly.  This implementation of solid meshes has some problems, as
> > you can see.
> 
> Just an idea, but could it help to test multiple times with different
> vectors to avoid these errors? Just use the result that the majority of
> vectors produce.

	Would be more expensive... but also more safe.
	Maybe the "inside" test could be simplified... For instance, instead
of counting the odd/even number of triangles that the test-ray hits, why
not to test the surface normal of the FIRST intersected triangle ? I'm
not sure, but I guess the dot product of the ray and this normal will be
positive if inside the mesh, negative if not (whatever is the mesh shape).
Anything wrong ?


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

On Tue, 29 Aug 2000 13:33:57 +0200, Nicolas Calimet wrote:
>> > Possibly.  This implementation of solid meshes has some problems, as
>> > you can see.
>> 
>> Just an idea, but could it help to test multiple times with different
>> vectors to avoid these errors? Just use the result that the majority of
>> vectors produce.
>
>	Would be more expensive... but also more safe.
>	Maybe the "inside" test could be simplified... For instance, instead
>of counting the odd/even number of triangles that the test-ray hits, why
>not to test the surface normal of the FIRST intersected triangle ? I'm
>not sure, but I guess the dot product of the ray and this normal will be
>positive if inside the mesh, negative if not (whatever is the mesh shape).
>Anything wrong ?

Yes.  The normals are not constrained to be consistent within the mesh.
However, with a little work, they could be made consistent, at which point
such a scheme would work.  It's just a matter of writing the code...

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

> The normals are not constrained to be consistent within the mesh.
> However, with a little work, they could be made consistent, at which point
> such a scheme would work.  It's just a matter of writing the code...

	Okay I thought it's the reason why this obvious test was not actually
used in MegaPOV. But how to make the triangle normals consistent ? I was
thinking about some simple (but slow) method like this:

1) Calculate the geometric center of all the mesh vertices
2) For each triangle
  a. calculate its geometric center from its vertices
     or even simply choose one of its vertex
  b. compare its normal vector to the (triangle center)-(vertices
     center) vector.
  c. revert the triangle vector if dot product is negative

	I'm not a genius in geometry/mathematics at all, but it sounds to
be a reasonnable approach to me... I'm waiting for comments from all you
clever boyz out there ;-)


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

On Tue, 29 Aug 2000 16:43:43 +0200, Nicolas Calimet wrote:
>> The normals are not constrained to be consistent within the mesh.
>> However, with a little work, they could be made consistent, at which point
>> such a scheme would work.  It's just a matter of writing the code...
>
>	Okay I thought it's the reason why this obvious test was not actually
>used in MegaPOV. But how to make the triangle normals consistent ? I was
>thinking about some simple (but slow) method like this:

The easiest way is to pick a face to be the reference, then realign all 
adjacent faces so they have the same "sense."  Continue until you've visited
all adjacent faces.  If an unvisited face still exists, repeat with that face
as the reference.  When finished, reorient as necessary to correct for the
possibility that an entire surface is inverted.

This only works on meshes that are well-behaved, though.  If an edge is 
shared by more or fewer than exactly two faces, the mesh is not well-behaved
and the procedure will fail.  (But in those cases, "inside" isn't well-defined
anyway.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Tue, 29 Aug 2000 16:43:43 +0200, Nicolas Calimet wrote:
>1) Calculate the geometric center of all the mesh vertices
>2) For each triangle
>  a. calculate its geometric center from its vertices
>     or even simply choose one of its vertex
>  b. compare its normal vector to the (triangle center)-(vertices
>     center) vector.
>  c. revert the triangle vector if dot product is negative
>

This algorithm is only guaranteed to work for convex meshes.  It 
fails for meshes with concavities or with multiple surfaces.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message