 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
could someone give me the mathematics needed to calculate the vertex
normals needed for the smooth_triangle primitive? i need to convert a "
standard" triangle to a smooth one!
thank you
ric
PS: the release of a DXF to POV converter is near, the source already
quite works for my internal use win non-smoothed triangles. As soon as
my web-site server comes back I will put it online!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
WhiteGandalf <zus### [at] libero it> wrote:
> could someone give me the mathematics needed to calculate the vertex
> normals needed for the smooth_triangle primitive? i need to convert a "
> standard" triangle to a smooth one!
You speak as if the vertex normals were unambiguous and there would be
just one correct solution.
Of course there is an almost infinite amount of possible vertex normals
(not infinite, of course, as the size of the floating point numbers impose
a limit, but in theory), and one cannot say that one set of normals is
"more correct" than another. They can be whatever you want them to be.
Also it's a mistake to think that the normal vector at a vertex shared
by several triangles should be same in all the triangles. If you want a
smooth lighting, it should, but it doesn't have to be (if the normal differs
in the adjacent triangles, it will give you an "edge" even though the
lighting of the triangles is smooth; this is sometimes a desired effect).
Of course if what you want is to automatically calculate the normals
for a triangle mesh so that it gets completely smooth, you can do it
by averaging the triangle normals of all the triangles sharing the vertex.
'Triangle normal' is the vector perpendicular to a triangle, calculated
with the cross-product of two edges of the triangle.
Now, for each vertex point in the mesh take the triangle normals of all
the triangles sharing that vertex and calculate their average (ie. sum
the vectors and divide by the number of triangles).
AFAIK the best result is got if you *don't* normalize the normal vectors
after the cross-product, but use them as they are. (The length of the vector
produced by the cross-product is the area of the triangle and this gives it
a good weight in the average.)
> PS: the release of a DXF to POV converter is near, the source already
> quite works for my internal use win non-smoothed triangles. As soon as
> my web-site server comes back I will put it online!
If the DXF file doesn't have smooth triangles, then why would you want
to make them smooth? Not all meshes are smooth.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Now, for each vertex point in the mesh take the triangle normals of all
> the triangles sharing that vertex and calculate their average (ie. sum
> the vectors and divide by the number of triangles).
yes.
But the moost difficult problem is to determine the orientation of these
normals.
Some workarounds may be found, but, AFAIK, there is -no- general solution.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But the moost difficult problem is to determine the orientation of these
> normals.
There's nothing difficult in determining the normal vector of a triangle.
It can be calculated with the cross-product of two of its edges. It's very
simple.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the advice, I'm already working on it, but not everything is
solved...
> should be same in all the triangles. If you want a smooth lighting, it
> should, but it doesn't have to be (if the normal differs in the
> adjacent triangles, it will give you an "edge" even though the
> lighting of the triangles is smooth; this is sometimes a desired
> effect).
sorry but I don't understand... using non-pov programs, like polygonal
modelers which implement phong shading (amapi, formz and such) if the
angle between 2 polygons on an edge is inferior to a threshold their
gradients are matched and one just sees the surface smooth. Can you give
me an example maybe?
> vectors and divide by the number of triangles). AFAIK the best
> result is got if you *don't* normalize the normal vectors after the
> cross-product, but use them as they are. (The length of the vector
> produced by the cross-product is the area of the triangle and this
> gives it a good weight in the average.)
I did not think about this, but it seems a good idea, I will experiment
on this.
> If the DXF file doesn't have smooth triangles, then why would you
> want to make them smooth? Not all meshes are smooth.
AFAIK there is not such thing as a smooth triangle in DXF, everything is
exported as 3DFACE. Even if it exists, I checked out various modellers
and they export "faceted" and "smoothed" meshes with the same code where
no information about the normals is given. So in any case I need to
reconstruct that information.
I have not found a good DXF to POV converter (if not a really old and
buggy one for Mac) and so I decided to write my own wih the features I
need.
Regards,
Riccardo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3cd536d5@news.povray.org...
> AFAIK the best result is got if you *don't* normalize the normal vectors
> after the cross-product, but use them as they are. (The length of the
vector
> produced by the cross-product is the area of the triangle and this gives
it
> a good weight in the average.)
One thing I noticed the other day... you don't even need to average the
normals. Just add them together, and then normalize the result. Saves a
few ops.
...Chambers
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <bdc### [at] yahoocom> wrote:
> One thing I noticed the other day... you don't even need to average the
> normals. Just add them together, and then normalize the result. Saves a
> few ops.
Why do you need to normalize the result? POV-Ray eats normal vectors of
any size (the length of the vector makes no difference).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3cd7e391@news.povray.org...
> Ben Chambers <bdc### [at] yahoocom> wrote:
> > One thing I noticed the other day... you don't even need to average the
> > normals. Just add them together, and then normalize the result. Saves
a
> > few ops.
>
> Why do you need to normalize the result? POV-Ray eats normal vectors of
> any size (the length of the vector makes no difference).
<g> Usually (ie, in most graphics apps), non-unit-length normals leads to
odd lighting. But if POV normalizes the results internally, then you don't
even need to worry about that - just sum the vectors.
...Chambers
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
