> >> Secondly (and to my eyes this a BIG problem) why is the macro
> >> VerdeelSuperellipsoid calling itself?
> >> Enlightenment needed.
> 
> >because it's a recursive macro, that's the whole idea :)
> >but, as far as I know, there are no problems with the 
> >superellipsoidal-greebles.
> 
> Unfortunately, that's exactly where we seem to be getting problems. As 
soon 
> as I comment out the superellipsoid bits in greebletest.pov everything 
runs 
> perfectly

hmm, sounds impossible to me...
let's see

hmm, you must be commenting out something else, the only problem I get, 
is a "Singular matrix in MInvers" error, always with the polygon in 
RoundPrism(..), which has nothing to do with the superellipsoidal 
greebles (those are all triangles)

Trust me, the only kind of greebles that will get you that error, are 
polygon-greebles (or prism-greebles, which are just combinations of 
polygon-greebles :))

> I shall carry on trying to figure out exactly where your code produces 
the 
> Singular Matrix error (b4 anyone mentions it I already know that 
MInvers is 
> a function in matrices.cpp and that it's the only place in the source 
code 
> that generates a Singular Matrix error)

I really think it's just a matter of scale.

Let me try something!
there you go...

in RoundPrism(..), changing

  polygon {
   Aantal2,
   #local Tel=0;
   #while (Tel<Aantal)
    #ifdef(Points2[Tel])<Points2[Tel].x,Points2[Tel].y> #end
    #local Tel=Tel+1;
   #end
   translate -z*H
  }

into

  polygon {
   Aantal2,
   #local Tel=0;
   #while (Tel<Aantal)
    #ifdef(Points2[Tel])<Points2[Tel].x,Points2[Tel].y>*100000 #end
    #local Tel=Tel+1;
   #end
   scale 1/100000
   translate -z*H
  }

fixes the problem, in this particular case.  Enough proof for me that 
the problem is that the points in the polygon are too close together :-/

> BTW Zeger, none of the above is a criticism of you or your coding. I 
> actually think that the concept is brilliant; I'm just having problems 
with 
> the implementation.

well, if it works, and it kind of does :), then the implementation 
shouldn't matter too much :)
but, it's "opensource" for a reason, of course.  If you know how to do 
it faster, or better, then by all means, do so ! :)

what I do, is more or less this:

I recursively subdivide the surface along the U and V directions (or X 
and Z for polygons), like this:

Let's say, you have a rectangle going from U=0 to U=1 and V=0 to 
V=1.  Now take a random point between <0,0> and <1,1>, for example, a 
purely random choice :), <.5,.5>

given this point, you can now make 4 rectangles: <0,0> -> <.5,.5>, 
<0,.5> -> <.5,1>, <.5,0> -> <1,.5>, and <.5,.5> -> <1,1>

do the same thing with these 4 rectangles, and you get, if I'm not 
mistaken, 16 rectangles, and so on and so on untill you're tired of 
subdividing :)

now, draw every one of those sub-rectangles as a beveled prism with a 
bevel-width that is, of course, smaller than half the size of the 
rectangle, and a random bevel-height.  Those are the greeble-cells.

Every greeble-cell needs to have some greebles, of course, so add up to 
5 (or whatever number, I'm going to keep on saying 5 just for the ease 
of typing) beveled rectangles that fit insinde the greeble-cell, up to 5 
little rounded cylinders (superellipsoids), up to 5 cylinders going 
along the U-direction and up to 5 cylinders going along the V-direction.

that's it.  That's the idea with rectangles, but it's the analog with 
cylinders or superellipsoid.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message