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

Chris Huff <chr### [at] maccom> wrote:
: 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.

  There's one problem here.
  Suppose that you shoot two rays instead of one, to be sure. Then one
ray says that you are outside, the other one says that you are inside.
What do you do?

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

Post a reply to this message

>   There's one problem here.
>   Suppose that you shoot two rays instead of one, to be sure. Then one
> ray says that you are outside, the other one says that you are inside.
> What do you do?

	Check at least three rays in the x/y/z directions ?


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

Post a reply to this message

In article <39abe095@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   There's one problem here.
>   Suppose that you shoot two rays instead of one, to be sure. Then one
> ray says that you are outside, the other one says that you are inside.
> What do you do?

Easy: shoot a third one.

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

I have done this kind of triangle mesh "fixing" myself (in my triangle
mesh smoother program).
  The idea is quite simple:

  1. Take the first triangle and mark it as 'handled'.

  2. Search all the triangles which are adjacent to this one and are
     not marked as 'handled'. An adjacent triangle is one that shares two
     vertices with this one.

  3. Check if the adjacent triangle is ordered correctly. That is, if the
     shared vertices are listed in inverse order in the adjacent triangle than
     in the current triangle, then it's ok. If they are listed in the same
     order, then you have to swap the other triangle.

  4. Now mark these adjacent triangles as 'handled' and for each one of them
     make recursively steps 2, 3 and 4 until no more triangles are found.

  5. After that, search for some unhandled triangle. If the mesh consisted of
     one contiguous surface, you'll not find any, but you have to do this
     because the mesh may consist of several separate parts. If you find
     an unhandled triangle, make all steps 1, 2, 3, 4 and 5 for it.


  This works pretty well, but it's very slow, specially with big meshes.
The slowest step is the second one (ie. the searching). There's probably some
way of speeding it up using some tree structure or hash table.

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

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Easy: shoot a third one.

  Could it be possible that two of them are wrong and one is right?-)

  All right, all right, I know that it's more probable that two are right
and one wrong and the other way around is a very rare case.

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

Post a reply to this message

On 29 Aug 2000 12:24:28 -0400, Warp wrote:
>  I have done this kind of triangle mesh "fixing" myself (in my triangle
>mesh smoother program).
>  The idea is quite simple:
>
>  1. Take the first triangle and mark it as 'handled'.
>
>  2. Search all the triangles which are adjacent to this one and are
>     not marked as 'handled'. An adjacent triangle is one that shares two
>     vertices with this one.
>
>  3. Check if the adjacent triangle is ordered correctly. That is, if the
>     shared vertices are listed in inverse order in the adjacent triangle than
>     in the current triangle, then it's ok. If they are listed in the same
>     order, then you have to swap the other triangle.
>
>  4. Now mark these adjacent triangles as 'handled' and for each one of them
>     make recursively steps 2, 3 and 4 until no more triangles are found.
>
>  5. After that, search for some unhandled triangle. If the mesh consisted of
>     one contiguous surface, you'll not find any, but you have to do this
>     because the mesh may consist of several separate parts. If you find
>     an unhandled triangle, make all steps 1, 2, 3, 4 and 5 for it.
>
>
>  This works pretty well, but it's very slow, specially with big meshes.
>The slowest step is the second one (ie. the searching). There's probably some
>way of speeding it up using some tree structure or hash table.

You missed a step.  After you finish all the surfaces, you have to make sure 
they're correctly oriented.  Even if it's just one surface, you have to 
make sure you haven't inverted it.

The searching would be faster if each edge were a structure containing 
pointers to the two triangles that share it.  Building such a structure 
would be O(n log n).


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

Post a reply to this message

what kind of meshes does this work on?  can it convert from regular to
mesh2?

Warp wrote:
> 
>   I have done this kind of triangle mesh "fixing" myself (in my triangle
> mesh smoother program).
>   The idea is quite simple:
> 
>   1. Take the first triangle and mark it as 'handled'.
> 
>   2. Search all the triangles which are adjacent to this one and are
>      not marked as 'handled'. An adjacent triangle is one that shares two
>      vertices with this one.
> 
>   3. Check if the adjacent triangle is ordered correctly. That is, if the
>      shared vertices are listed in inverse order in the adjacent triangle than
>      in the current triangle, then it's ok. If they are listed in the same
>      order, then you have to swap the other triangle.
> 
>   4. Now mark these adjacent triangles as 'handled' and for each one of them
>      make recursively steps 2, 3 and 4 until no more triangles are found.
> 
>   5. After that, search for some unhandled triangle. If the mesh consisted of
>      one contiguous surface, you'll not find any, but you have to do this
>      because the mesh may consist of several separate parts. If you find
>      an unhandled triangle, make all steps 1, 2, 3, 4 and 5 for it.
> 
>   This works pretty well, but it's very slow, specially with big meshes.
> The slowest step is the second one (ie. the searching). There's probably some
> way of speeding it up using some tree structure or hash table.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"ryan constantine" <rco### [at] yahoocom> wrote...
> > >, or do i need to convert to mesh2?  if so how?  or can i use
> > > uv mapping?  how?
> >
> > Yes.
>
> which?  all?

Yes, you can use uv mapping. You do not have to convert to mesh2.

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

Are you looking in the MegaPov documentation or the official POV 3.1
documentation?  I was referring to the 3.1 docs.  From that documentation,
in the "Mesh Object" section, you'll read:

------ begin quote -------
Now let's begin. We will create a simple box with differently colored sides.
We create an empty file called meshdemo.pov and add the following lines.

  camera {
    location <20, 20, -50>
    look_at <0, 5, 0>
  }
  light_source { <50, 50, -50> color rgb<1, 1, 1> }
  #declare Red = texture {
    pigment { color rgb<0.8, 0.2, 0.2> }
    finish { ambient 0.2 diffuse 0.5 }
  }
  #declare Green = texture {
    pigment { color rgb<0.2, 0.8, 0.2> }
    finish { ambient 0.2 diffuse 0.5 }
  }
  #declare Blue = texture {
    pigment { color rgb<0.2, 0.2, 0.8> }
    finish { ambient 0.2 diffuse 0.5 }
  }

We must declare all textures we want to use inside the mesh before the mesh
is created. Textures cannot be specified inside the mesh due to the poor
memory performance that would result.

Now we add the mesh object. Three sides of the box will use individual
textures while the other will use the global mesh texture.

  mesh {
    /* top side */
    triangle { <-10, 10, -10>, <10, 10, -10>, <10, 10, 10>
      texture { Red }
    }
    triangle { <-10, 10, -10>, <-10, 10, 10>, <10, 10, 10>
      texture { Red }
    }
    /* bottom side */
    triangle { <-10, -10, -10>, <10, -10, -10>, <10, -10, 10> }
    triangle { <-10, -10, -10>, <-10, -10, 10>, <10, -10, 10> }
    /* left side */
    triangle { <-10, -10, -10>, <-10, -10, 10>, <-10, 10, 10> }
    triangle { <-10, -10, -10>, <-10, 10, -10>, <-10, 10, 10> }
    /* right side */
    triangle { <10, -10, -10>, <10, -10, 10>, <10, 10, 10>
      texture { Green }
    }
    triangle { <10, -10, -10>, <10, 10, -10>, <10, 10, 10>
      texture { Green }
    }
    /* front side */
    triangle { <-10, -10, -10>, <10, -10, -10>, <-10, 10, -10>
      texture { Blue }
    }
    triangle { <-10, 10, -10>, <10, 10, -10>, <10, -10, -10>
      texture { Blue }
    }
    /* back side */
    triangle { <-10, -10, 10>, <10, -10, 10>, <-10, 10, 10> }
    triangle { <-10, 10, 10>, <10, 10, 10>, <10, -10, 10> }
    texture {
      pigment { color rgb<0.9, 0.9, 0.9> }
      finish { ambient 0.2 diffuse 0.7 }
    }
  }
--------- end quote --------

>  is there a uv mapping tut' out there?

I don't think there currently is.  Sorry.

-Nathan

Post a reply to this message

thanks, i was thinking that uv mapping was megapov only so i was only
looking there.  no i just have to figure out which tringle is which and
what i want to texture it with.

Nathan Kopp wrote:
> 
> "ryan constantine" <rco### [at] yahoocom> wrote...
> > > >, or do i need to convert to mesh2?  if so how?  or can i use
> > > > uv mapping?  how?
> > >
> > > Yes.
> >
> > which?  all?
> 
> Yes, you can use uv mapping. You do not have to convert to mesh2.
> 
> > 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.
> 
> Are you looking in the MegaPov documentation or the official POV 3.1
> documentation?  I was referring to the 3.1 docs.  From that documentation,
> in the "Mesh Object" section, you'll read:
> 
> ------ begin quote -------
> Now let's begin. We will create a simple box with differently colored sides.
> We create an empty file called meshdemo.pov and add the following lines.
> 
>   camera {
>     location <20, 20, -50>
>     look_at <0, 5, 0>
>   }
>   light_source { <50, 50, -50> color rgb<1, 1, 1> }
>   #declare Red = texture {
>     pigment { color rgb<0.8, 0.2, 0.2> }
>     finish { ambient 0.2 diffuse 0.5 }
>   }
>   #declare Green = texture {
>     pigment { color rgb<0.2, 0.8, 0.2> }
>     finish { ambient 0.2 diffuse 0.5 }
>   }
>   #declare Blue = texture {
>     pigment { color rgb<0.2, 0.2, 0.8> }
>     finish { ambient 0.2 diffuse 0.5 }
>   }
> 
> We must declare all textures we want to use inside the mesh before the mesh
> is created. Textures cannot be specified inside the mesh due to the poor
> memory performance that would result.
> 
> Now we add the mesh object. Three sides of the box will use individual
> textures while the other will use the global mesh texture.
> 
>   mesh {
>     /* top side */
>     triangle { <-10, 10, -10>, <10, 10, -10>, <10, 10, 10>
>       texture { Red }
>     }
>     triangle { <-10, 10, -10>, <-10, 10, 10>, <10, 10, 10>
>       texture { Red }
>     }
>     /* bottom side */
>     triangle { <-10, -10, -10>, <10, -10, -10>, <10, -10, 10> }
>     triangle { <-10, -10, -10>, <-10, -10, 10>, <10, -10, 10> }
>     /* left side */
>     triangle { <-10, -10, -10>, <-10, -10, 10>, <-10, 10, 10> }
>     triangle { <-10, -10, -10>, <-10, 10, -10>, <-10, 10, 10> }
>     /* right side */
>     triangle { <10, -10, -10>, <10, -10, 10>, <10, 10, 10>
>       texture { Green }
>     }
>     triangle { <10, -10, -10>, <10, 10, -10>, <10, 10, 10>
>       texture { Green }
>     }
>     /* front side */
>     triangle { <-10, -10, -10>, <10, -10, -10>, <-10, 10, -10>
>       texture { Blue }
>     }
>     triangle { <-10, 10, -10>, <10, 10, -10>, <10, -10, -10>
>       texture { Blue }
>     }
>     /* back side */
>     triangle { <-10, -10, 10>, <10, -10, 10>, <-10, 10, 10> }
>     triangle { <-10, 10, 10>, <10, 10, 10>, <10, -10, 10> }
>     texture {
>       pigment { color rgb<0.9, 0.9, 0.9> }
>       finish { ambient 0.2 diffuse 0.7 }
>     }
>   }
> --------- end quote --------
> 
> >  is there a uv mapping tut' out there?
> 
> I don't think there currently is.  Sorry.
> 
> -Nathan

Post a reply to this message

ryan constantine wrote:
> 
> thanks, i was thinking that uv mapping was megapov only so i was only
> looking there.  no i just have to figure out which tringle is which and
> what i want to texture it with.
> 
	uv mapping is megapov only. For a tutorial on uv mapping, you can look
here: http://www.mediaport.net/Artichaud/Tran/sources/tutuve.htm

		Jérôme
-- 
******************************* Jérôme M. BERGER
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: You missed a step.  After you finish all the surfaces, you have to make sure 
: they're correctly oriented.  Even if it's just one surface, you have to 
: make sure you haven't inverted it.

  Well, this is an interesting question. How do you determine for a closed
mesh surface, which side is inside and which one is outside?
  What about open mesh surfaces?

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

Post a reply to this message

ryan constantine <rco### [at] yahoocom> wrote:
: what kind of meshes does this work on?  can it convert from regular to
: mesh2?

  It reads a pov-file with meshes and writes and identical pov-file with
the same meshes, except that all the triangles are smooth_triangles. Everything
else is preserved.

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

Post a reply to this message

On 30 Aug 2000 10:14:04 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: You missed a step.  After you finish all the surfaces, you have to make sure 
>: they're correctly oriented.  Even if it's just one surface, you have to 
>: make sure you haven't inverted it.
>
>  Well, this is an interesting question. How do you determine for a closed
>mesh surface, which side is inside and which one is outside?
>  What about open mesh surfaces?

Open mesh surfaces are impossible, but that's because the term "inside" has
no meaning for one.

For a closed mesh surface, fire a ray from outside the bounding box and check
the normal.

Some "well-behaved" "closed" surfaces will still fail; a 3-d projection of a
klein bottle, for example, would fail.  Those are the fault of the modeler
and shouldn't concern us.

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

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Open mesh surfaces are impossible, but that's because the term 
> "inside" has no meaning for one.

A height field is an open mesh surface with an "inside". :-)
Of course, it has a specific definition of "insideness", which I think 
is "Any point below the surface".

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

On Wed, 30 Aug 2000 11:02:08 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg 
>wrote:
>
>> Open mesh surfaces are impossible, but that's because the term 
>> "inside" has no meaning for one.
>
>A height field is an open mesh surface with an "inside". :-)
>Of course, it has a specific definition of "insideness", which I think 
>is "Any point below the surface".

Lots of open surfaces have "insides."  Consider, for example, an open cylinder
or a clipped object.  But those are a matter of definition and might not do
what you expect them to in CSG.

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

Post a reply to this message

what are the benefits of smooth triangles?  do they have explicit
normals in the file?

Warp wrote:
> 
> ryan constantine <rco### [at] yahoocom> wrote:
> : what kind of meshes does this work on?  can it convert from regular to
> : mesh2?
> 
>   It reads a pov-file with meshes and writes and identical pov-file with
> the same meshes, except that all the triangles are smooth_triangles. Everything
> else is preserved.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

thanks everybody.  i haven't started yet, but i think you have given me
enough information to do what i want.

ryan constantine wrote:
> 
> 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

Ron Parker <ron### [at] povrayorg> wrote:
: For a closed mesh surface, fire a ray from outside the bounding box and check
: the normal.

  And hope that the ray hits the mesh? If it doesn't, shoot another ray? What
if after shooting 100 rays you still haven't hit the mesh? :)

  I think there should be a more "secure" way of doing it.

  I was thinking about how to make sure that the mesh really is closed. I think
that it's enough to check that every triangle has three and only three
adjacent triangles.
  It's not usual, but very possible that a triangle has more than three
adjacent triangles, but I think that in that case we are in trouble.

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

Post a reply to this message

ryan constantine <rco### [at] yahoocom> wrote:
: what are the benefits of smooth triangles?

  This should be obvious when you see a mesh rendered with regular triangles
and then with smooth triangles.
  For examples, see:
http://iki.fi/warp/PovUtils/smooth.html

:  do they have explicit
: normals in the file?

  Yes.

  Although the mesh smoother calculates single normals for each vertex,
it's perfectly possible that in a pov mesh there could be different normals
for the same vertex, one for each triangle (actually there is, but they
are often the same vector, but they could be different).

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

Post a reply to this message

Oh, and there's another problem with the ray-shooting technique:

  Even if your ray hits the mesh, if the mesh consists of separate parts
(all closed) you'll only be able to fix the part that the ray hit. The other
parts will still have the problem.

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

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
:   And hope that the ray hits the mesh? If it doesn't, shoot another ray? What
: if after shooting 100 rays you still haven't hit the mesh? :)

  Fool me!
  Of course it's easy to shoot a ray that will certainly hit at least one
triangle (and thus at least two triangles since it's a closed mesh)!
  Just choose a triangle and make the ray go through its center.

  This also solves the problem of isolated mesh parts. After fixing one part,
just check if there are non-fixed triangles and choose one of them and repeat
the same thing described above.

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

Post a reply to this message

where is the utility?  i looked in the newsgroups and looked for your
website but didn't find one.

Warp wrote:
> 
> ryan constantine <rco### [at] yahoocom> wrote:
> : what are the benefits of smooth triangles?
> 
>   This should be obvious when you see a mesh rendered with regular triangles
> and then with smooth triangles.
>   For examples, see:
> http://iki.fi/warp/PovUtils/smooth.html
> 
> :  do they have explicit
> : normals in the file?
> 
>   Yes.
> 
>   Although the mesh smoother calculates single normals for each vertex,
> it's perfectly possible that in a pov mesh there could be different normals
> for the same vertex, one for each triangle (actually there is, but they
> are often the same vector, but they could be different).
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 30 Aug 2000 18:51:43 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: For a closed mesh surface, fire a ray from outside the bounding box and check
>: the normal.
>
>  And hope that the ray hits the mesh? If it doesn't, shoot another ray? What
>if after shooting 100 rays you still haven't hit the mesh? :)

No, fire it at a known triangle.  Determine the normal by which triangle it hit 
first, rather than the triangle you fired it at.

>  I was thinking about how to make sure that the mesh really is closed. I think
>that it's enough to check that every triangle has three and only three
>adjacent triangles.

That's what I'd think.

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

Post a reply to this message

On 30 Aug 2000 19:05:10 -0400, Warp wrote:
>  Oh, and there's another problem with the ray-shooting technique:
>
>  Even if your ray hits the mesh, if the mesh consists of separate parts
>(all closed) you'll only be able to fix the part that the ray hit. The other
>parts will still have the problem.

That part is guaranteed to be the outside shell of that part of the mesh.
Take that part (all of its triangles) out of the list of triangles, then
fire another ray.  The first surface it hits is either inside the fixed set
of surfaces or not.  If it's inside, its normal should face away from the ray.
If it's outside, the normal should face toward the ray.  Continue removing
these subsurfaces from the list of triangles until none are left.  Now
they're all corrected.

I've done this algorithm in 2D.  It does work.

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

Post a reply to this message

nevermind found it. i also found that my mesh is already in smooth
triangle form. now about texturing...

ryan constantine wrote:
> 
> where is the utility?  i looked in the newsgroups and looked for your
> website but didn't find one.
> 
> Warp wrote:
> >
> > ryan constantine <rco### [at] yahoocom> wrote:
> > : what are the benefits of smooth triangles?
> >
> >   This should be obvious when you see a mesh rendered with regular triangles
> > and then with smooth triangles.
> >   For examples, see:
> > http://iki.fi/warp/PovUtils/smooth.html
> >
> > :  do they have explicit
> > : normals in the file?
> >
> >   Yes.
> >
> >   Although the mesh smoother calculates single normals for each vertex,
> > it's perfectly possible that in a pov mesh there could be different normals
> > for the same vertex, one for each triangle (actually there is, but they
> > are often the same vector, but they could be different).
> >
> > --
> > main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> > ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message