 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have some questions about polygons (when used in meshes in particular)
that are probably going to seem sorta dumb. First of all, are they limited
to 3 or 4 edges, and if so, why? Secondly, does every edge of every
polygon in a mesh have to be shared by one (and only one) neighboring
polygon? For example,
-----------
| | |
| 1 | 2 |
|_____| |
| | |
| 3 | |
|_____|_____|
would be wrong, but,
-----------
| | |
| 1 | 2 |
|_____|_____|
| | |
| 4 | 3 |
|_____|_____|
would be fine. If so, why? These questions have really been nagging at me
lately, so any enlightenment you guys can provide would be very
appreciated. Thanks in advance.
Jordan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jordan wrote:
>
> I have some questions about polygons (when used in meshes in
> particular) that are probably going to seem sorta dumb. First of all,
> are they limited to 3 or 4 edges, and if so, why?
No. However, many of the cool things done with polygons in a mesh,
such as surface subidvision, work best with triangles or quadrilaterals.
For instance, the Loop surface requires triangles and generates
triangles, while the Catmull-Clark surface can take any shape polygon,
but generates four-siders.
An important caveat: The mesh object used by POV-Ray uses only
triangles (although this may change in the future). Fortunately,
other polygons are rather easily divisible into triangles.
> Secondly, does every edge of every polygon in a mesh have to be shared
> by one (and only one) neighboring polygon? For example,
>
> -----------
> | | |
> | 1 | 2 |
> |_____| |
> | | |
> | 3 | |
> |_____|_____|
>
> would be wrong, but,
>
> -----------
> | | |
> | 1 | 2 |
> |_____|_____|
> | | |
> | 4 | 3 |
> |_____|_____|
>
> would be fine. If so, why?
Not the case. In POV-Ray the mesh would be comprised of triangles,
and you could butt two triangles against the edge of a third, but
keeping the results seamless would be difficult.
If for some reason you are unwilling to divide your quadrilaterals,
pentagons, etc., into triangles, then in POV-Ray you will have to use a
union of polygons instead of a mesh. By doing so you will miss out on
a great number of advantages that the mesh object has, but sometimes
it can't be avoided.
As for the behaviors of other renderers, I can't say.
> These questions have really been nagging at me
> lately, so any enlightenment you guys can provide would be very
> appreciated. Thanks in advance.
Glad to be of service.
Regards,
John
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> An important caveat: The mesh object used by POV-Ray uses only
> triangles (although this may change in the future). Fortunately,
> other polygons are rather easily divisible into triangles.
>
It should be possible to have a version of mesh that has triangles and
other polygons. A program or a macro could convert the polygons to
triangles. Maybe it could be done during parsing or a program could
convert the mesh, send it to povray, and then optionally delete the
converted mesh to save space (so you don't accidentally delete the wrong
version of the mesh instead of the temporary one).
Brendan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrea Ryan wrote:
>
> > An important caveat: The mesh object used by POV-Ray uses only
> > triangles (although this may change in the future). Fortunately,
> > other polygons are rather easily divisible into triangles.
> >
>
> It should be possible to have a version of mesh that has triangles and
> other polygons. A program or a macro could convert the polygons to
> triangles. Maybe it could be done during parsing or a program could
> convert the mesh, send it to povray, and then optionally delete the
> converted mesh to save space (so you don't accidentally delete the wrong
> version of the mesh instead of the temporary one).
> Brendan
Sound to me like adding a "polygon" option in the mesh, which would be
pretty simple if there was not the tricky overlapping polygon case.
Then come the eternal question: should it be done by the user or
the program (user-friendly or programmer-friendly) ?
Better wait for the 3.5 anyway before considering any patching...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The problem with triangulating polygons is that uv-mapping is greatly
affected by the triangulatization process. This comes as a surprise to
most people, but what can happen is the following:
http://www.cs.tut.fi/~warp/uvproblem.gif
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This comes as a surprise to
> most people, but what can happen is the following:
>
> http://www.cs.tut.fi/~warp/uvproblem.gif
I thought this problem only arises on scanliners, but as I see your sketches
now, it's clear to me, that without any corrections it must happen to all
triangulated polygons....
Would it help, to tesselate this into four triangles by adding another vertex
in the center of the polygon ?
would this avoid the distortion or is this only a "better error" (you know
what I mean) ...
If so, what is the correct procedure, to avoid this ?
--
Jan Walzer <jan### [at] lzer net>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
: Would it help, to tesselate this into four triangles by adding another vertex
: in the center of the polygon ?
: would this avoid the distortion or is this only a "better error" (you know
: what I mean) ...
As you guessed, it doesn't get rid of the error. The "stripes" in the
texture will, when applied to a triangle, always be parallel along the
surface of the triangle, although they shouldn't, due to the shape of the
polygon. This is a flaw in the classical texture mapping algorithm.
: If so, what is the correct procedure, to avoid this ?
In a more advanced triangle texture mapping algorithm it is possible to
specify a texture stretching value which changes along the surface of the
triangle, and this effectively gets rid of this artifact. This algorithm has
a name, but I don't remember what it is.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The problem with triangulating polygons is that uv-mapping is greatly
> affected by the triangulatization process. This comes as a surprise to
> most people, but what can happen is the following:
>
> http://www.cs.tut.fi/~warp/uvproblem.gif
>
I don't know anything about this , but it seems quite interesting.
How would I reproduce your image in povray? Being completely ignorant, I
made this scene, hoping it would show your picture, but it does not:
#version unofficial megapov 0.7;
#declare P = pigment {
image_map { png "uvproblem.png"
}
}
light_source { 0 1 }
mesh {
triangle { 0 x x+y uv_vectors 0 x x+y }
triangle { 0 x+y y uv_vectors 0 x+y y }
uv_mapping pigment { P }
rotate x * 45
translate <-1/2, -1/4, 1>
}
It produces this for me: http://www.elias.f2s.com/pov/uvmap.png
--
#macro C(X,Y)cylinder{X*x<X,0,-Y/2>.1}#end#macro U(R,X,Y)intersection{torus{.9
.1}box{-1 0rotate y*R*90}translate<X,0,Y>scale 1-z*.5}#end union{U(0,0,0)U(1,0
,0)U(2,-1,-1)U(1,1,0)U(1,1.5,-3)U(1,2,0)U(3,1,0)U(2,2,0)U(0,3,0)U(3,2,.5)C(.1,
2)C(.8,1)C(.8,-1)C(1.1,1)C(1.9,-1)pigment{rgb 10}rotate x*90translate<-1,0,4>}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I don't know anything about this , but it seems quite interesting.
>
> How would I reproduce your image in povray? Being completely ignorant, I
> made this scene, hoping it would show your picture, but it does not:
Ok, I found out myself by changing the verteces. My example was of course
quite stupid. Sorry.
--
#macro C(X,Y)cylinder{X*x<X,0,-Y/2>.1}#end#macro U(R,X,Y)intersection{torus{.9
.1}box{-1 0rotate y*R*90}translate<X,0,Y>scale 1-z*.5}#end union{U(0,0,0)U(1,0
,0)U(2,-1,-1)U(1,1,0)U(1,1.5,-3)U(1,2,0)U(3,1,0)U(2,2,0)U(0,3,0)U(3,2,.5)C(.1,
2)C(.8,1)C(.8,-1)C(1.1,1)C(1.9,-1)pigment{rgb 10}rotate x*90translate<-1,0,4>}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Elias Pschernig <eli### [at] aonat> wrote:
: Ok, I found out myself by changing the verteces. My example was of course
: quite stupid. Sorry.
I think you confused my non-square polygon with perspective... The polygon
in my image is not distorted by perspective, it's just shaped like that :)
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
