![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jörg 'Yadgar' Bleimann
Subject: Strange results when averaging normals on a spherical mesh2
Date: 15 Jun 2005 15:49:01
Message: <42b0862d@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
High!
(see also code files on p.b.s-f!)
After some delay, I finally found out how mesh2s and smooth_triangles
work - starting with a hand-coded 5 by 5 mesh, whose smoothed version
looks convincing at least to me (both non-smoothed and smoothed version
attached here).
But then I also tried this on the curved mesh2 (following Earth
curvature) from the 1200 by 1200 SRTM data of some mountainous Afghan
wilderness west of Kabul... and got a VERY strange appearance of the
mesh (also attached).
Not only that most of the topography is lost to a strange regular normal
pattern, but also from about row 1100, normals are no longer averaged
any more (#warning output "division by zero", vector "norm" keeps its
initialization value of <0, 0, 0>), so that the foreground remains
unsmoothed!
What went wrong?
Am I, at all, right to assume that the average of vectors
<x1, y1, z1>, <x2, y2, z2>,...,<xn, yn, zn> simply is
<(x1+x2+...+xn)/n, (y1+y2+...+yn)/n, (z1+z2+...+zn)/n> - or am I barking
up a totally wrong tree?
Another question, going much further into possible methods of 3D terrain
modeling: as meshes (as well as heightfields) aren't really the golden
road to photorealistic terrains based on real elevation data, I thought
about computing an approximating function for each data column and row
respectively and then "cross-approximating" somehow these two arrays of
functions (in my case, each containing 1200 functions) in to one
incredible complex function describing the whole data matrix as an
isosurface.
Has such an algorithm ever been programmed, perhaps even in the POV
world? I don't think of the hf_mesh_isosurface functions by Chistoph
Hormann et al. (which just generate one function for each data point),
but a solution which yields really smooth isosurfaces out of data
matrizes...
See you in Khyberspace!
Yadgar
Now playing: Le Parc (Tangerine Dream)
Post a reply to this message
Attachments:
Download 'mesh2test.jpg' (9 KB)
Download 'mesh2test_smoothed.jpg' (8 KB)
Download 'sarehelmand_smooth.jpg' (49 KB)
Preview of image 'mesh2test.jpg'
![mesh2test.jpg](/povray.binaries.images/attachment/%3C42b0862d%40news.povray.org%3E/mesh2test.jpg?ttop=441697&toff=5200&preview=1)
Preview of image 'mesh2test_smoothed.jpg'
![mesh2test_smoothed.jpg](/povray.binaries.images/attachment/%3C42b0862d%40news.povray.org%3E/mesh2test_smoothed.jpg?ttop=441697&toff=5200&preview=1)
Preview of image 'sarehelmand_smooth.jpg'
![sarehelmand_smooth.jpg](/povray.binaries.images/attachment/%3C42b0862d%40news.povray.org%3E/sarehelmand_smooth.jpg?ttop=441697&toff=5200&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
=?ISO-8859-1?Q?J=F6rg_=27Yadgar=27_Bleimann?= <yaz### [at] gmx de> wrote:
> Am I, at all, right to assume that the average of vectors
> <x1, y1, z1>, <x2, y2, z2>,...,<xn, yn, zn> simply is
> <(x1+x2+...+xn)/n, (y1+y2+...+yn)/n, (z1+z2+...+zn)/n> - or am I barking
> up a totally wrong tree?
yes it's fine (i think), as long as the normals you add
are normalized! (otherwise long normals contribute more
to the average than shorter normals)
imagine stacking all normals on top of each other (in 3D),
you end up with a funy line that can end anywhere, so the
result will not be normalized by dividing it by the number
of normals you added together.
the end of the stack of normals may end op at <0,0,0>, witch
can't be normalized, because it does not have any direction.
(like when you average to normals with exactly opposite direction)
jaap.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Jaap" <jws### [at] yahoo com> wrote:
> yes it's fine (i think), as long as the normals you add
> are normalized! (otherwise long normals contribute more
> to the average than shorter normals)
> imagine stacking all normals on top of each other (in 3D),
> you end up with a funy line that can end anywhere, so the
> result will not be normalized by dividing it by the number
> of normals you added together.
> the end of the stack of normals may end op at <0,0,0>, witch
> can't be normalized, because it does not have any direction.
> (like when you average to normals with exactly opposite direction)
you can skip the the divide by n, if you are going to normalize
the resulting vector anyway.
(but your problem may be caused by something else)
jaap. (again)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
i took teh liberty to change your code a bit:
#declare a=0;
#while (a<zdem)
#declare b=0;
#while (b<xdem)
#declare ep=vertices[a][b];
#declare av=<0,0,0>;
#declare c=0;
#while (c<8)
#declare svp=ep+(sp/2)*<int(sin(c*45)*(pi/180)), 10,
int(cos(c*45)*(pi/180))>;
#declare svt=trace(relief, svp, -y, norm);
#if (norm.x!=0 | norm.y!=0 | norm.z!=0)
#warning "OK!"
#declare av=av+norm;
#end
#declare c=c+1;
#end
#if (vlength(av)!=0)
#declare normals[a][b]=vnormalize(av);
#else
#declare normals[a][b]=<0,0,0>;
#end
#declare b=b+1;
#end
#declare a=a+1;
#end
- you don't need seperate x,y and zet av, (just use av.x when needed)
- the divide by number of normals is replaced by vnormalize()
- added check for <0,0,0> sum of normals.
- you seem to check wether the trace() function missed the object,
but normals like <0,0,1> and <0,1,0> are valid, so use something like:
#if (norm.x!=0 | norm.y!=0 | norm.z!=0)
or:
#if (vlength(norm)!=0)
or:
#if ((abs(norm.x)+abs(norm.y)+abs(norm.z))!=0)
jaap.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: scott
Subject: Re: Strange results when averaging normals on a spherical mesh2
Date: 16 Jun 2005 05:59:54
Message: <42b14d9a$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> But then I also tried this on the curved mesh2 (following Earth
> curvature) from the 1200 by 1200 SRTM data of some mountainous Afghan
> wilderness west of Kabul... and got a VERY strange appearance of the
> mesh (also attached).
It looks like the normals are all wrong, you shouldn't be able to see the
individual triangles like that if you've calculated them correctly.
Your code looks very complex (because of all the transformations built-in)
and I haven't got time to analyse it all. But I posted some code to p.b.s-f
in reply to your message that does what you want I think. It just takes a
2D array of vectors, and then joins them all up with a smoothed mesh2. You
might be able to spot your problem by looking at the code. I hope it helps.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Florian Brucker
Subject: Re: Strange results when averaging normals on a spherical mesh2
Date: 17 Jun 2005 03:22:37
Message: <42b27a3d$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Another question, going much further into possible methods of 3D terrain
> modeling: as meshes (as well as heightfields) aren't really the golden
> road to photorealistic terrains based on real elevation data, I thought
> about computing an approximating function for each data column and row
> respectively and then "cross-approximating" somehow these two arrays of
> functions (in my case, each containing 1200 functions) in to one
> incredible complex function describing the whole data matrix as an
> isosurface.
Depending on your data, spline patches could be worth a try. Not
necessarily the ones provided by POV itself, but e.g. NURBS-patches. You
could then add different levels of noise afterwards to "unsmooth" the
whole thing and make it look like terrain again. Tor Olav Kristensen has
posted some animations and images containing NURBS, perhaps you could
start there...
HTH,
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |