|
 |
"ABX" <abx### [at] abx artpl> wrote in message
news:1i0mgvo027ljh8obcp0e1qk4kt3us4vop5@4ax.com...
> On Tue, 8 Jul 2003 19:42:42 +0200, "Jaap Frank" <jjf### [at] xs4allnl> wrote:
> > I think ABX is suggesting that there is no definite front or
> > back side and this correspond with my example file.
>
> What I'm suggesting is that you shouldn't rely on such definition because of the
> nature of triangle.
>
> > Did you try this file?
>
> No. Because assuming the reference I posted I would drop it and use
> "workaround". What about plane with well defined inside clipped_by union of
> three planes to form triangle (+ manually bounded_by). Do you need more
> triangles? IIRC mesh{} can "find" its inside using inside_vector.
>
> ABX
Thanks ABX,
I am working with a closed mesh() and wanted to see if there were holes in it
(I think there are) and used 'interior_texture'. It gave many triangles with the
'interior_texture'. If I altered the sequence of the vertices of some triangles,
it didn't matter much. Some did change, but other didn't.
I did remember something about 'clock wise' or 'counter clock wise' but
my example file told me something different. That's why I asked.
I will try the 'inside_vector' and see if it helps.
Thanks any way.
Jaap Frank
Post a reply to this message
|
|
|
|
In article <3f0b090d@news.povray.org>, "Jaap Frank" <jjf### [at] xs4allnl>
wrote:
> I am working with a closed mesh() and wanted to see if there were
> holes in it (I think there are) and used 'interior_texture'. It gave
> many triangles with the 'interior_texture'. If I altered the sequence
> of the vertices of some triangles, it didn't matter much. Some did
> change, but other didn't.
It is known to work in meshes. The height field macros, for example,
were designed to give triangles with the correct ordering, so
interior_texture works with the resulting meshes. It should work with
plain triangles as well, the normal is computed internally as:
VSub(V1, Triangle->P1, Triangle->P2);
VSub(V2, Triangle->P3, Triangle->P2);
VCross(Triangle->Normal_Vector, V1, V2);
However, part of the code in Compute_Triangle() changes the ordering
of the points (after the normal has been computed). Transforming the
triangle causes this function to be called again, this time using the
swapped around vertices to compute the normal, so the original winding
is lost. This could be considered a bug, but never mattered before the
inside_texture feature. The best solution would be to call the
Compute_Triangle() function just once, after all the changes to the
triangle have been made, but this would take a fairly large amount of
work. It should have no effect on triangles in meshes, as the
transformation is applied to the entire mesh. (the mesh data can not be
transformed, because it may be used by other mesh objects)
As a workaround, you could simply transform the triangle vertices
instead of the entire triangle.
#macro TransformedTriangle(P1, P2, P3, Trans)
#local TransFn = function {transform {Trans}}
triangle {TransFn(P1.x, P1.y, P1.z),
TransFn(P1.x, P1.y, P1.z),
TransFn(P1.x, P1.y, P1.z)
}
#end
This could also be useful in meshes, where you can't apply
transforms to individual triangles.
> I did remember something about 'clock wise' or 'counter clock wise' but
> my example file told me something different. That's why I asked.
> I will try the 'inside_vector' and see if it helps.
The inside_vector feature only affects solidity, it will have no
effect here.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
