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'

Preview of image 'mesh2test_smoothed.jpg'

Preview of image 'sarehelmand_smooth.jpg'

=?ISO-8859-1?Q?J=F6rg_=27Yadgar=27_Bleimann?= <yaz### [at] gmxde> 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

"Jaap" <jws### [at] yahoocom> 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 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

> 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

> 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