 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, yes and no. Remember, we are dealing with surface normals _only_ in
this case. The triangle has no inside/outside. In theory the normals could
flip from one side of the triangle to the other, POV wouldn't give a damn.
It would simply result in a strange jump in lighting.
By the way, CSG objects often have surface normals pointing both in and out
(as a result of the difference operation). This creates problems only in
very specific cases, like using the trace() funcion to do something based on
the surface normal (creating furry CSG is a bitch :)
The Julia fractal is a 4D object. Rendering 4D objects isn't all that
difficult, but it would have to be a 3D "slice" of the object, so result are
hard to predict.
I think the real problem is that of ambiguity, which I described.
Also, I notice that I'm in a talkative mood today.
Margus
Ken wrote:
/.../
> have two opposing sides of a flat surface connected to each other. Looks
> like I got lucky this time.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
[ ... ]
> I can't think of any other way to
> have two opposing sides of a flat surface connected to each other. Looks
> like I got lucky this time.
The normals are at different corners, not the same place.
The normals are, 'by definition', coming out of the same side of the
triangle. If they are going in opposite directions, that, I thought,
is just supposed to mean that the expected surface (not the actual
triangle
defined by the vertices) bends around that much.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
david sharp wrote in message <36F### [at] interport net>...
>Ken wrote:
>[ ... ]
>> I can't think of any other way to
>> have two opposing sides of a flat surface connected to each other. Looks
>> like I got lucky this time.
>
>
>The normals are at different corners, not the same place.
>The normals are, 'by definition', coming out of the same side of the
>triangle. If they are going in opposite directions, that, I thought,
>is just supposed to mean that the expected surface (not the actual
>triangle
>defined by the vertices) bends around that much.
That was also my interpretation. The image I have in mind is a short piece
of ribbon twisted so that one end is 180 degress to the other.
Gordon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gordon wrote:
[ ... ]
> The image I have in mind is a short piece
> of ribbon twisted so that one end is 180 degress to the other.
Which is what motivated the question in the first place!:
http://www.interport.net/~dsharp/
(about the middle of the page)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 21 Mar 1999 18:47:47 -0500, david sharp <dsh### [at] interportnet> wrote:
>Now, my question is why does POV-Ray do that? What is wrong with
>one normal pointing 'up' while two point 'down' (or vice versa)?
I guess I should reply to this one, since I submitted the bug
report that got these classified as degenerate triangles. :)
The problem is, those triangles cause division by zero errors
on Alpha processors. There is no way to have the normal go
from "positive" to "negative" without going through zero, so
there is always a curve on such a triangle where the normal
is undefined. Since POV always needs a valid normal to compute
shading, that's a bad thing.
If you want to see the original discussion that caused this,
you'll have to go back a few months on povray.programming.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> I can't think of any other way to
> have two opposing sides of a flat surface connected to each other.
How about a muebius strip (spelling?), the band with only one surface.
Perhaps the problem is that if you interpolate normals pointing to
different
sides of the surface there will exist a point on the triangle with the
normal <0,0,0> which of course messes things up....
/ Mathias Broxvall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
[ ... ]
> The problem is, those triangles cause division by zero errors
> on Alpha processors. There is no way to have the normal go
> from "positive" to "negative" without going through zero, so
> there is always a curve on such a triangle where the normal
> is undefined. Since POV always needs a valid normal to compute
> shading, that's a bad thing.
Hmmmm, I just assumed that POV was rotating the normals from one
triangle corner to the next, in which case I don't see any 'zero'
normal.
Your comment makes me believe that what POV does is interpolate the
vector coefficients independently.
(ie, n1.x -> n2.x, n1.y -> n2.y, n1.z -> n2.z linearly, not rotating
the normal).
(or does this question just demonstrate my complete misunderstanding)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Mar 1999 12:47:37 -0500, david sharp <dsh### [at] interportnet> wrote:
>Ron Parker wrote:
>[ ... ]
>> The problem is, those triangles cause division by zero errors
>> on Alpha processors. There is no way to have the normal go
>> from "positive" to "negative" without going through zero, so
>> there is always a curve on such a triangle where the normal
>> is undefined. Since POV always needs a valid normal to compute
>> shading, that's a bad thing.
>
>
>Hmmmm, I just assumed that POV was rotating the normals from one
>triangle corner to the next, in which case I don't see any 'zero'
>normal.
>Your comment makes me believe that what POV does is interpolate the
>vector coefficients independently.
It's good that that's what it makes you believe, for that is indeed what it
does. Below are the nice ASCII-art comments from the relevant spot in
triangle.c. The normalization step is what causes the division-by-zero error
in some cases. There may also be lighting code that is sensitive to normals
that are exactly perpendicular to the ray. The solution to the problem is to
specify your geometry more precisely by creating more triangles. The
difference between the normals at the corners of a smooth triangle shouldn't
be large, anyway, because the Phong approximation works best for smallish
angles. I will admit, though, that if the new code is based on my original
thoughts on this matter, it might be a bit more sensitive to this problem
than is strictly necessary.
If you're trying to create a twisted-ribbon type of thing, perhaps you
would find more success and realism with bicubic patches.
* Calculate the Phong-interpolated vector within the triangle
* at the given intersection point. The math for this is a bit
* bizarre:
*
* - P1
* | /|\ \
* | / |Perp\
* | / V \ \
* | / | \ \
* u | /____|_____PI___\
* | / | \ \
* - P2-----|--------|----P3
* Pbase PIntersect
* |-------------------|
* v
*
* Triangle->Perp is a unit vector from P1 to Pbase. We calculate
*
* u = (PI - P1) DOT Perp / ((P3 - P1) DOT Perp).
*
* We then calculate where the line from P1 to PI intersects the line P2 to P3:
* PIntersect = (PI - P1)/u.
*
* We really only need one coordinate of PIntersect. We then calculate v as:
*
* v = PIntersect[X] / (P3[X] - P2[X])
* or v = PIntersect[Y] / (P3[Y] - P2[Y])
* or v = PIntersect[Z] / (P3[Z] - P2[Z])
*
* depending on which calculation will give us the best answers.
*
* Once we have u and v, we can perform the normal interpolation as:
*
* NTemp1 = N1 + u(N2 - N1);
* NTemp2 = N1 + u(N3 - N1);
* Result = normalize (NTemp1 + v(NTemp2 - NTemp1))
*
* As always, any values which are constant for the triangle are cached
* in the triangle.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
[ ... ]
> The solution to the problem is to
> specify your geometry more precisely by creating more triangles. The
> difference between the normals at the corners of a smooth triangle shouldn't
> be large, anyway, because the Phong approximation works best for smallish
> angles.
It now seems to me, after a few similar problems, that the solution
always ends up being '*more* triangles!'
[ ... ]
> If you're trying to create a twisted-ribbon type of thing, perhaps you
> would find more success and realism with bicubic patches.
oh thats probably true, but then I would have to figure them out.
Aren't bicubic patches those things you specify with huge arrays of
numbers that don't make any sense?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Mar 1999 14:52:36 -0500, david sharp <dsh### [at] interportnet> wrote:
>Ron Parker wrote:
>[ ... ]
>> If you're trying to create a twisted-ribbon type of thing, perhaps you
>> would find more success and realism with bicubic patches.
>
>oh thats probably true, but then I would have to figure them out.
>Aren't bicubic patches those things you specify with huge arrays of
>numbers that don't make any sense?
No, those are those things you specify with 4x4 arrays of numbers that
make perfect sense once you understand them. :) The best understanding
I've been able to formulate for a bicubic patch is that the four corners
of a patch are always on the surface of the patch. The other eight edge
points are "control points" analogous to the "handles" on Bezier curves
in programs like Corel Draw, Freehand, or Illustrator in that they define
the beginning and ending direction of the curves that define the edges of
the patch, as well as the "tension" at the corners. These eight points
also specify the surface normals at the four corners, sorta indirectly.
The four points in the middle of the patch are the hardest to understand,
but I tend to visualize them as the same sort of "control points," except
that the "anchors" they are associated with are not actually on the
surface of the patch. In a sense, they control how the surface slopes
away from the edge curves, though their exact effect might not be
immediately or intuitively obvious.
An alternate view (less precise, more "artsy") is to just visualize the
sixteen points as a simple mesh of quadrilaterals, like a wire screen.
Bend it and stretch it however you will, and the resultant patch will do
its best to approximate that shape while remaining smooth (though it will
only actually touch any of the grid points at the corners, in most cases.)
If you want to play, grab the source to my IRTC entry for the latest
round and check out the source to the bedsheet. Some of the commented-out
code in that file allows you to visualize the control mesh that governs
the final shape of the sheet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
