I am using the Generalized Dual Method to construct tilings, and then I export
them to POV-Ray, as an #include file, with spheres on the vertices and
cylinders on the edges. Always, the polygons in the tiling have been sorted
into subsets, and typically, I give a different color to each subset. Actually,
I write "texture{ Tk }" where k is an integer denoting the kth subset. This
image shows a simple example.

I have a problem and could use some help. I wish to use a fixed scene file as a
point of beginning for any such tiling, yet I do not know how many subsets may
exist. Yet if I have not defined T1, T2, T3 etc. in my scene file, I cannot
call the #include file. Currently I define T1 through T4. It occurs to me that
it would be nice to have a way to define Tk up to k=100 or some large number by
using colors.inc somehow. But I do not see quite how to do that. I am not much
of an expert in the POV SDL. In particular, I have had trouble with arrays, and
have never used #ifndef.

Hmmm. Suddenly I see I could have my own other #include file which defines Tk up
to any k, possibly by using random numbers for RGB components; and then I could
edit that #include file as needed in rendering.

TIA.

Post a reply to this message

Attachments:
Download 'tiling.jpg' (207 KB)

Preview of image 'tiling.jpg'

"Russell Towle" <rto### [at] inreachcom> wrote:
> I am using the Generalized Dual Method to construct tilings, and then I export
> them to POV-Ray, as an #include file, with spheres on the vertices and
> cylinders on the edges. Always, the polygons in the tiling have been sorted
> into subsets, and typically, I give a different color to each subset. Actually,
> I write "texture{ Tk }" where k is an integer denoting the kth subset. This
> image shows a simple example.
>
> I have a problem and could use some help. I wish to use a fixed scene file as a
> point of beginning for any such tiling, yet I do not know how many subsets may
> exist. Yet if I have not defined T1, T2, T3 etc. in my scene file, I cannot
> call the #include file. Currently I define T1 through T4. It occurs to me that
> it would be nice to have a way to define Tk up to k=100 or some large number by
> using colors.inc somehow. But I do not see quite how to do that. I am not much
> of an expert in the POV SDL. In particular, I have had trouble with arrays, and
> have never used #ifndef.
>
> Hmmm. Suddenly I see I could have my own other #include file which defines Tk up
> to any k, possibly by using random numbers for RGB components; and then I could
> edit that #include file as needed in rendering.
>
> TIA.

not sure if I follow:
"Generalized Dual Method to construct tilings, and then I export
> them to POV-Ray,"

but,
to "know how many subsets may
> exist"

just do all the calcs in pov script?

would love to see the method,
aQ

Post a reply to this message

Russell Towle wrote:

> I have a problem and could use some help. I wish to use a fixed scene file as a
> point of beginning for any such tiling, yet I do not know how many subsets may
> exist. Yet if I have not defined T1, T2, T3 etc. in my scene file, I cannot
> call the #include file. Currently I define T1 through T4. It occurs to me that
> it would be nice to have a way to define Tk up to k=100 or some large number by
> using colors.inc somehow. But I do not see quite how to do that. I am not much
> of an expert in the POV SDL. In particular, I have had trouble with arrays, and
> have never used #ifndef.

Using an array of textures is not difficult:

#declare T_NUM = 100;

#declare T = array[T_NUM];

#declare T[0] = texture {...}
...

Of course getting it filled automatically with reasonable
colors is more difficult, maybe fill the first few by hand
and use some hacked rgb values for the rest as in:

#declare i = 0;
#while (i < T_NUM)
   #declare T[i] = texture
   {
     pigment {color rgb <mod(i,3)/3, mod(i,5)/5, mod(i,7)/7>}
   }
   #declare i = i + 1;
#end

Post a reply to this message

"alphaQuad" <alp### [at] earthlinknet> wrote:

> just do all the calcs in pov script?
>
> would love to see the method,

Well I've been thinking, why not implement the GDM in POV?

Right now I've got it in Mathematica's language, and I ported it from PostScript
of all things. Could it live in POV SDL? Maybe. Maybe yes!

It involves taking a set of lines which could be of the form {x,y,d} where {x,y}
is a unit vector and d is the distance of the line perpendicular to this vector
from the origin. Typically d will run through integers -k to k for any given
{x,y} and typically the various {x,y}'s will run through the vertices of a
regular polygon. An n-gon, say. So there will be something like n*((2*k)+1)
lines altogether.

Then follows a sort of complicated business of taking the signs of determinants
of 3X3 subsets of the lines. Sign vectors are formed which encode how to make
the tiling: take a step along this vector, then along that, and so on, until
you reach a certain point: then make the polygon which is rooted at that point
from some other subset of the original vectors.

Along the way various degenerate polygons arise with zero area and so there is
some parsing to discard any of these.

It seems daunting to me because it was by an agony of effort I ever ported it
from PostScript to Mathematica. Does POV even have determinants? I guess that's
the easiest part, they could be programmed in if they're not there already in
the SDL.

If it was done right one would have a macro which accepted as input a list of
lines of the form {x,y,d}. A different macro could make this list of lines I
suppose. Just thinking about it makes me feel faint.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Russell Towle wrote:
>
>      pigment {color rgb <mod(i,3)/3, mod(i,5)/5, mod(i,7)/7>}


I have seen something like that before and it is the darker method

tex(<T[i].x,T[i].y,T[i].z,.9,.1>)


the brighter (not as dark) method would be:
#declare S1 = seed (2341);
#declare S2 = seed (5521);
#declare S3 = seed (134515);
tex(<rand(S3),rand(S2),rand(S1),.9,.1>)



in this image the random method is:

#declare T[i]=<mod(i,3)/3, mod(i,5)/5, mod(i,7)/7>;
tex(<T[i].x,T[i].y,T[i].z,.9,.1>)

as suggested; darker;

Post a reply to this message

Attachments:
Download 'spheroid_dome10.jpg' (66 KB)

Preview of image 'spheroid_dome10.jpg'

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Of course getting it filled automatically with reasonable
> colors is more difficult, maybe fill the first few by hand
> and use some hacked rgb values for the rest as in:
>
> #declare i = 0;
> #while (i < T_NUM)
>    #declare T[i] = texture
>    {
>      pigment {color rgb <mod(i,3)/3, mod(i,5)/5, mod(i,7)/7>}
>    }
>    #declare i = i + 1;
> #end

That would work well, for I mainly need to get the scene file to parse, then I
can fill in colors or textures by hand as inspiration hits me.

I managed to refine my POV export from Mathematica so that now I write a scene
file with exactly as many colors as subsets of tiles, and all but the first ten
entries in the color list are random RGB.

Thanks!

Post a reply to this message

Russell Towle napsal(a):
> "alphaQuad" <alp### [at] earthlinknet> wrote:
> 
>> just do all the calcs in pov script?
>>
>> would love to see the method,
> 
> Well I've been thinking, why not implement the GDM in POV?
> 
> Right now I've got it in Mathematica's language, and I ported it from PostScript
> of all things. Could it live in POV SDL? Maybe. Maybe yes!
> 
> It involves taking a set of lines which could be of the form {x,y,d} where {x,y}
> is a unit vector and d is the distance of the line perpendicular to this vector
> from the origin. Typically d will run through integers -k to k for any given
> {x,y} and typically the various {x,y}'s will run through the vertices of a
> regular polygon. An n-gon, say. So there will be something like n*((2*k)+1)
> lines altogether.
> 
> Then follows a sort of complicated business of taking the signs of determinants
> of 3X3 subsets of the lines. Sign vectors are formed which encode how to make
> the tiling: take a step along this vector, then along that, and so on, until
> you reach a certain point: then make the polygon which is rooted at that point
> from some other subset of the original vectors.
> 
> Along the way various degenerate polygons arise with zero area and so there is
> some parsing to discard any of these.
> 
> It seems daunting to me because it was by an agony of effort I ever ported it
> from PostScript to Mathematica. Does POV even have determinants? I guess that's
> the easiest part, they could be programmed in if they're not there already in
> the SDL.
> 
the determinant is a mixed product of its row vectors (AxB).C . POV does 
have vcross() and vdot().
> If it was done right one would have a macro which accepted as input a list of
> lines of the form {x,y,d}. A different macro could make this list of lines I
> suppose. Just thinking about it makes me feel faint.
> 
> 
> 


-- 
the ultimate time-killer:
+a0.0 +am2 +r9

Johnny D

Post a reply to this message

The difference can be seen here with pov internal random strings.
I thought I was going to have to filter dark colors, such was not the case.

Post a reply to this message

Attachments:
Download 'spheroid_dome09.jpg' (126 KB)

Preview of image 'spheroid_dome09.jpg'

"alphaQuad" <alp### [at] earthlinknet> wrote:
> The difference can be seen here with pov internal random strings.
> I thought I was going to have to filter dark colors, such was not the case.

Very nice! I like the transparency in the dome-thing, the over-arching
structure.

Unusual to see triangular bipyramids. And the thing in the middle looks like
maybe a hyperbolic octahedron or maybe triangular bipyramid?

Post a reply to this message

"Russell Towle" <rto### [at] inreachcom> wrote:

> Unusual to see triangular bipyramids. And the thing in the middle looks like
> maybe a hyperbolic octahedron or maybe triangular bipyramid?

see thread "Easter People ..." for some of this



//Astroidal Ellipse    or rhombihexacron
#declare Vmin=0;
#declare Vmax=pi*2;
#declare Umin=0;
#declare Umax=pi*2;
#declare F_AEx = function(u,v) {pow(cos(u)*cos(v),3)}
#declare F_AEy = function(u,v) {pow(sin(v),3)}
#declare F_AEz = function(u,v) {pow(sin(u)*cos(v),3)}
spheroid(1.7, 0.3, 0.0, 0.0, 20,10,F_AEx,F_AEy,F_AEz,1)

Post a reply to this message