 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Mar 1999 12:47:37 -0500, david sharp <dsh### [at] interport net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
While we are on the(off the) topic of tirangles, patches and so on..
I'm working on a small landscape generator macro, and I'm not very satisfied
with the extreme high triangle count I'll need to make it visualised.
I have the points in a 2D array, each storing a height value(sorta like a
heightfield) I know all points are declared, so there are no such problems.
Yes, I guess I could use smooth_triangle, but i don't know where the normals
would be, since I only have height data.
I guess I could try and point all the normals UP, but that wouldn't be really
useful, would it?
I came to think of using patches, but then... I'd have to use a loop to split
the big grid into smaller pieces, and then use four as corners, and the rest as
control points, I know it'd be looking nice, but there would be a mess to set it
up for me.
Any tips/ideas ??
My current render has a triangle count of :
38416+355216 triangles....
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider,
Have a look at the code for my Simple Surface Macros in
binaries.scene-files. If you look through the code, you will see that it
calculates the normals. The key is that you need to average the normals of
the 6 (or whatever) triangles that meet at a particular corner. If you then
use this normal for that corner on each of the triangles, they will all be
smooth. In order to ensure you always get normals on the same side of the
surface, make sure that you do the cross products in the same order for
every corner.
For example, if you have a triangle with corners A, B, C defined in a
clockwise direction. Normal at A is vnormalize(vcross(B-A,C-A)), normal at B
is vnormalize(vcross(C-B,A-B)), and at C it is vnormalize(vcross(A-C,B-C)).
Note that the order of the corners is clockwise in each call, the normals
may be on the "top" or "bottom" but all will be on the same side.. Draw it
and see!
If this is not clear, let me know and I will try to explain in more detail,
with an example.
Regards
Gordon
<gtb### [at] birdcameroncomau>
Spider wrote in message <36F83193.8091B4A5@bahnhof.se>...
>While we are on the(off the) topic of tirangles, patches and so on..
>I'm working on a small landscape generator macro, and I'm not very
satisfied
>with the extreme high triangle count I'll need to make it visualised.
>
>I have the points in a 2D array, each storing a height value(sorta like a
>heightfield) I know all points are declared, so there are no such problems.
>
>Yes, I guess I could use smooth_triangle, but i don't know where the
normals
>would be, since I only have height data.
>I guess I could try and point all the normals UP, but that wouldn't be
really
>useful, would it?
>
>I came to think of using patches, but then... I'd have to use a loop to
split
>the big grid into smaller pieces, and then use four as corners, and the
rest as
>control points, I know it'd be looking nice, but there would be a mess to
set it
>up for me.
>
>Any tips/ideas ??
>My current render has a triangle count of :
>38416+355216 triangles....
>
>
>
>--
>//Spider
> [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
>What I can do and what I could do, I just don't know anymore
> "Marian"
> By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The calculation of the normals is also explained in detail in my
triangle mesh smoother, http://iki.fi/warp/PovUtils/smooth.html
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'll look at it. Thanks.
<snipping the help>
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, thanks, I'll look at this as well.
Nieminen Mika wrote:
>
> The calculation of the normals is also explained in detail in my
> triangle mesh smoother, http://iki.fi/warp/PovUtils/smooth.html
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 24 Mar 1999 01:28:03 +0100, Spider <spi### [at] bahnhofse> wrote:
>I have the points in a 2D array, each storing a height value(sorta like a
>heightfield) I know all points are declared, so there are no such problems.
>
>Yes, I guess I could use smooth_triangle, but i don't know where the normals
>would be, since I only have height data.
>I guess I could try and point all the normals UP, but that wouldn't be really
>useful, would it?
A reasonable normal is the cross product of a vector pointing uphill at the
steepest possible angle[1] and a vector pointing along a contour line.[2]
If your height data is dense enough, you should be able to approximate those
well enough.
One problem you'll have with patches is that if you don't have enough data to
generate the normals for a smooth triangle, you don't have enough to make the
control points for a patch, either.
[1] Its projection in 2d would be the gradient, so if you add the the (x,y)
gradient vector to the derivative of the height over that vector, times z,
then normalize, you'll have the "uphill" vector.
[2] Its projection in 2d is perpendicular to the gradient, and its z component
is zero by definition. So it is just the gradient vector rotated by 90 degrees
about the z axis.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> 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.
Thanks. This makes bicubics less intimidating.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
