POV-Ray : Newsgroups : povray.advanced-users : Re: ..triangle? For Tim, ABX, Christopher Server Time
25 Nov 2024 05:41:02 EST (-0500)
  Re: ..triangle? For Tim, ABX, Christopher (Message 1 to 5 of 5)  
From: Jaap Frank
Subject: Re: ..triangle? For Tim, ABX, Christopher
Date: 8 Jul 2003 13:40:15
Message: <3f0b01ff@news.povray.org>
Hi,

thank you for your answers.
I think ABX is suggesting that there is no definite front or
back side and this correspond with my example file.
If Tim's and Christopher 's way is correct, then how can
the front side change with a simple translation up or down?
Did you try this file?

Jaap Frank


Post a reply to this message

From: ABX
Subject: Re: ..triangle? For Tim, ABX, Christopher
Date: 8 Jul 2003 13:50:46
Message: <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


Post a reply to this message

From: Jaap Frank
Subject: Re: ..triangle? For Tim, ABX, Christopher
Date: 8 Jul 2003 14:10:21
Message: <3f0b090d@news.povray.org>
"ABX" <abx### [at] abxartpl> 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

From: Christopher James Huff
Subject: Re: ..triangle? For Tim, ABX, Christopher
Date: 8 Jul 2003 15:27:33
Message: <cjameshuff-317238.14250208072003@netplex.aussie.org>
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

From: Jaap Frank
Subject: Re: ..triangle? For Tim, ABX, Christopher
Date: 8 Jul 2003 17:11:33
Message: <3f0b3385$1@news.povray.org>
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> In article <3f0b090d@news.povray.org>, "Jaap Frank" <jjf### [at] xs4allnl>
> wrote:
> ....
> 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)
> ....

In the answer to Shay I've changed his example.
Is this what you expected or is there something more?

Jaap Frank


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.