 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 6 Mar 2002 18:08:12 +0100, "Hugo" <hua### [at] post3 teledk> wrote:
> I'd very much like to have the best
> smoothing algoritm in my program..
Algorithm is very simple:
1. start loop on all triangles and calculate
a) triangle has vertices V1,V2,V3
b) normal=vnormalize(vcross(V2-V1,V3-V1))
c) area=triangle_area(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,V3.x,V3.y,V3.z)
d) multiply above and store area*normal in temporary array
2. start second loop on all vertices
a) for each vertex find all its triangles: triangle1, triangle2, ... triangleN
b) calculate weighted normal with equation:
Normal=(area1*normal1+area2*normal2+...+areaN*normalN)/N
(note all multiplications was precalculated and stored in array)
c) store new weighted normal for triangle
That's all.
Of course there can be variations and optimizations according to particular
situation but it is how it looks in general
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 6 Mar 2002 11:13:31 -0600, "Shay" <sah### [at] simcopartscom> wrote:
> Writing the formula as a function MIGHT speed
> it up, but with only 2 operations per calculations I'm not sure.
Well, you can check my investigation in
http://news.povray.org/f4sa5uomgj1v158rjs159ms75midq7qm52%404ax.com
that function is fastest way of calculations
> The method described by ABX is necessary only for non-square meshes.
I can be wrong becouse I not studied your sources enough but looking at
pictures on http://news.povray.org/3c84365e%40news.povray.org your triangles
are non-square. Only projection onto xz plane (considering y is up) are
square.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
wrote:
> c) store new weighted normal for triangle
should be:
c) store new weighted normal for vertex
sorry
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:opjc8u8qk2a9s20e037adocejo9ccvii6i@4ax.com...
> On Wed, 6 Mar 2002 11:13:31 -0600, "Shay" <sah### [at] simcopartscom> wrote:
> I can be wrong becouse I not studied your sources enough but looking at
> pictures on http://news.povray.org/3c84365e%40news.povray.org your
triangles
> are non-square. Only projection onto xz plane (considering y is up) are
> square.
OH DAMN!!! I really screwed up. I was only thinking about elevating one
vertex in ... (well, not important what I was thinking).
I will implement the method you outlined ASAP. This is really going to slow
the macro down, but as long as you're writing out the results for possibly
hundreds of renders, you may as well get the best results possible.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:5mdc8ukvplcavtnekp4f0cvtebe8rtlbob@4ax.com...
> #include "functions.inc"
> #local triangle_area_engine=function{(x+y+z)*(y+z-x)*(x+y-z)*(x+z-y)/16}
> #local triangle_area=
> function(x1,y1,z1,x2,y2,z2,x3,y3,z3)
> {sqrt(triangle_area_engine(
> f_r(x2-x1,y2-y1,z2-z1),
> f_r(x3-x2,y3-y2,z3-z2),
> f_r(x3-x1,y3-y1,z3-z1)
> ))};
I've haven't used any functions yet, so I would like to know if my version
of your function will work..
I see a slight problem with your function in that the lengths of most of the
triangle sides will be calculated twice.
The demonstration file I wrote finds all of the side lengths first and
stores them in an array. A #local statement at the beginning of each "case"
macro could find the length of the diagonal. So, would this give an accurate
result?
#include "functions.inc"
#local triangle_area_engine=function{(x+y+z)*(y+z-x)*(x+y-z)*(x+z-y)/16}
#local Triangle_Area = triangle_area_engine(Side_1_Length, Side_2_Length,
Side_3_Length);
Seems right to me, but I might be missing something.
Thank you,
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, the results *look* correct. I implemented the formula you suggested,
and the parse is still pretty quick. I tested a 100x100 mesh on my P2 650 at
work with lots of memory-hogging programs running on it, and the parse was
still under a minute.
I cancelled the version from pbs-f that I posted from work and will cancel
the others when I get home, but I might run several tests, or at least get
confirmation from ABX that my function is correct, before I post this new
version.
-Shay
Shay <sah### [at] simcopartscom> wrote in message news:3c866379@news.povray.org...
> The demonstration file I wrote finds all of the side lengths first and
> stores them in an array. A #local statement at the beginning of each
"case"
> macro could find the length of the diagonal. So, would this give an
accurate
> result?
>
> #include "functions.inc"
> #local triangle_area_engine=function{(x+y+z)*(y+z-x)*(x+y-z)*(x+z-y)/16}
> #local Triangle_Area = triangle_area_engine(Side_1_Length,
Side_2_Length,
> Side_3_Length);
>
> Seems right to me, but I might be missing something.
>
> Thank you,
> -Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Very good. Let me just add that I'm going to turn the heightfield data
around lathes and let them follow the path of splines. I don't know if this
is going to break the non-square type of mesh. It's still a grid. But these
turns will, of course, happen before normal calculations.
> This is really going to slow the macro down
I can always have both methods, and let the user decide which one to use.
:o)
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> universal formula for area of triangle:
>
> S=sqrt(p*(p-a)*(p-b)*(p-c))
>
> where a,b,c are lengths of edges and p is half of perimeter = (a+b+c)/2
>
Is that faster than using half the cross product of two of the sides?
(cosidering vcross is internal...)
Something like:
area = vlength(vcross(P1-P2,P3-P2))/2;
-josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo <hua### [at] post3teledk> wrote in message news:3c867a5b@news.povray.org...
> Very good. Let me just add that I'm going to turn the heightfield data
> around lathes and let them follow the path of splines. I don't know if
this
> is going to break the non-square type of mesh. It's still a grid. But
these
> turns will, of course, happen before normal calculations.
It's not as slow as I thought it might be, and nothing will break this new
algorithm. As long as the vertices can be put into an n-by-n array, the
algorithm will work.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Don't think so. sqrt needs more cpu cycles. But maybe I'm wrong!
--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
