POV-Ray : Newsgroups : povray.general : Hexagon pattern with 4 or 7 colors? Server Time
28 Mar 2024 18:38:41 EDT (-0400)
  Hexagon pattern with 4 or 7 colors? (Message 24 to 33 of 33)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 3 May 2018 13:35:01
Message: <web.5aeb474797bd1601a47873e10@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
>...I'd like to make a few suggestions for improvement so that it's usable for
> experienced and new users alike.
>
>
> 1. Declare this as a standalone texture for use in an include file.
> That way perhaps we can start a NewPatterns_v1.inc or something.

Yes, either that or maybe as a macro (?)

>
> #declare FullHexagon = texture {....}
> and obviously remove the finish {} block so that it can be applied by the
> end-user.

Yes again. Although, *what if* the user wanted different finishes for the
different hexagons? (Imagine a hexagonal wood floor!) I guess that would require
 a "NewPatterns_v2" ;-)  A more complex version, in other words.
>
> 2. Just a little nitpicky kinda thing: .8660254 is a "magic number" - it
> has no meaning to someone looking at the code itself [and it has no leading
> zero :( ].
> #declare Edge2Edge = 2 * sin (60); and then use that in your code.

Agreed. My own code was more of an explanation (and not very detailed!) of why
the sin(60) was necessary. And cos(60) was also needed ;-)

> Better still, since that still leaves out the implies "unit length of
> a side", make it
> #declare SideLength = 1;
> #declare Edge2Edge = 2 * SideLength * sin (60);
>
> and then scale <3, 1, (3 * Edge2Edge)>

Hmm, I think that might be redundant-- only because the shape of a hexagon is
'fixed'. Adding those #declares would only add more bulk to the code (or perhaps
only 'explanatory' code.) And, if someone wanted to 'stretch' the hexagons, that
would be done more easily by a final scaling of the whole pattern, as with the
current implementation.


> 3. I, and likely anyone else who'd like to use this (OP), would probably
> enjoy a simple mechanism by which to specify between 1 and N colors for
> the hexagons.  I haven't dabbled with the code yet, but having a few
> easily understood #declares that parameterize the pattern would make it
> a lot easier.

Agreed.

And I'm currently mulling over thought-experiments of how to get the random
colors to include not only the hue, but the saturation and brightness as well.
Maybe that should be "NewPatterns_v3", ha-- if I can get it to work.

>
> 4.  Having just the outlines of the hexagons - a hexagonal grid (perhaps with
> boxed{} or another pattern with a gradient or something? would be an obvious
> extension of this.  Obviously some pattern would give hexagons with "holes"
> rather than clean lines, but it's grid-like nonetheless.
>

An interesting idea.

My own (different) attempts at using the 'boxed' pattern with the cells pattern
failed, though-- the boxed pattern appears to be a *single* entity that doesn't
repeat within the cells: The 'outer' pigment of boxed{} wipes out all the other
instances of that pattern. In other words, only ONE complete boxed pattern is
seen, in one cell; the rest of the cells pattern shows just the boxed outer
color. I haven't investigated this further; perhaps there's a way around it-- or
maybe it was due to my own early and uninformed use of the warp{repeat..}
offsets. (?) I should probably go back and try again.

But back to your idea of hexagon outlines: I think it would require a more
sophisticated version of something like the 'brick' pattern, with its mortar
lines. A hexagon-shaped version!


Post a reply to this message

From: Bald Eagle
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 3 May 2018 15:15:06
Message: <web.5aeb5f7d97bd1601c437ac910@news.povray.org>
> > 1. Declare this as a standalone texture for use in an include file.
> > That way perhaps we can start a NewPatterns_v1.inc or something.
>
> Yes, either that or maybe as a macro (?)

Well, elaborating on my initial brief post, the whole idea was that it could
probably be implemented as a macro, so that the user could pass parameters to
it.
But also that the include file would/could be a growing repository of new
patterns and variations on themes.  Once 10, 20, 30 patterns got added, it might
make into the next version distribution.


> Yes again. Although, *what if* the user wanted different finishes for the
> different hexagons? (Imagine a hexagonal wood floor!) I guess that would require
>  a "NewPatterns_v2" ;-)  A more complex version, in other words.

Implement it so that you can use a texture_map rather than just a pigment_map.
That way you can pass a full texture or just a pigment.  Or even go so far as to
make it a material_map.
Or have 3 macros, each a little different.
Author's choice as always.  ;)


> > Better still, since that still leaves out the implies "unit length of
> > a side", make it
> > #declare SideLength = 1;
> > #declare Edge2Edge = 2 * SideLength * sin (60);
> >
> > and then scale <3, 1, (3 * Edge2Edge)>
>
> Hmm, I think that might be redundant-- only because the shape of a hexagon is
> 'fixed'. Adding those #declares would only add more bulk to the code (or perhaps
> only 'explanatory' code.) And, if someone wanted to 'stretch' the hexagons, that
> would be done more easily by a final scaling of the whole pattern, as with the
> current implementation.

True, but I think that a lot of posted code and code that can spur people on to
develop new patterns and textures ought to have as much info so that the next
guy can hit the ground running without having to unravel the meaning of his
archaeological find.


> And I'm currently mulling over thought-experiments of how to get the random
> colors to include not only the hue, but the saturation and brightness as well.
> Maybe that should be "NewPatterns_v3", ha-- if I can get it to work.

Well, don't use rgb - use the HSV2RGB macro in colors.inc.
That takes an "rgbft" vector as input (HSVft) and returns rgbft.
#declare it as a color rgbft and THEN use it in your pigment / texture or else
you'll get a "suspicious expression after rgb" warning for every instance.

> I haven't investigated this further; perhaps there's a way around it-- or
> maybe it was due to my own early and uninformed use of the warp{repeat..}
> offsets. (?) I should probably go back and try again.
>
> But back to your idea of hexagon outlines: I think it would require a more
> sophisticated version of something like the 'brick' pattern, with its mortar
> lines. A hexagon-shaped version!

Right.  I'm thinking the key has to be in a cylindrical or spherical pattern, or
maybe triangular with a gradient running from center to edge.

That quantum dot thread had something like that going on - I'll have to go back
and look through that.  There was a LOT of development going on at a very rapid
pace.  Too rapid for me to absorb it.


Post a reply to this message

From: Bald Eagle
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 3 May 2018 20:35:00
Message: <web.5aeba9a597bd16015cafe28e0@news.povray.org>
I took a stab at it, but somehow with my numbered textures, it goes horribly
awry.

Having worked the initial pattern out, you likely stand a better chance of
seeing where it's going wrong and why.

I'll leave this here for you to fiddle with.

#version 3.7;
global_settings {assumed_gamma 1.0}

#include "colors.inc"

sky_sphere {pigment {rgb <1, 1, 1>}}

camera {
   location <0, 20, 0>    // position & direction of view
  look_at  <0, 0, 0.01>
  right x*image_width/image_height           // horizontal size of view
  up y // vertical size of view
 }

light_source {<0, 25, -1> color White}

#declare Num = array [10];
#for (N, 0, 9)
 #declare Num[N] = text {ttf "arialbd.ttf" chr(48+N) 100, 0 translate <0, 0,
-50>}
#end


#declare T = array [10];
#for (N, 0, 9)
 #declare Current = CHSV2RGB(<N*36, 1, 1>);
 #declare T[N] =
  pigment {
   pigment_pattern {
    object {Num[N]} // 1, 0}
    warp {repeat x}
    warp {repeat y}
   }
   pigment_map {
    [0.0 rgbft Current]
    //[0.9 rgbft Current]
    [1.0 rgb 0]
   }
  scale 0.25
  rotate x*90
  }

#end

/*
// This seems to work fine
box {<-1, 0.1, -1>*10, <1, 0.02, 1>*10
 texture { // #1
                  cells
                  texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T[N*10] ]
      [N+0.1 T[N*10] ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
 }
  scale <3,1,3*.8660254>

}
*/

#declare SIN60 = sin (radians(60));

box {<-1, 0, -1>*10, <1, 0.01, 1>*10
 texture {
  //pigment{
  hexagon
  texture { // #1
   cells
   texture_map {
    #for (N, 0, 0.9, 0.1)
     [N     T[N*10] ]
     [N+0.1 T[N*10] ]
     //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
" N*10 = ", str (N*10, 3, 1), "\n")
    #end
   }
   scale <3, 1, 3*SIN60>
   // warp {repeat 3*.8660254*z offset <1.5,357.4,0>}
   // the x-offset has to be 1.5, or can increase by
   // adding multiples of 3.0 -- 1.5, 4.5, 7.5 etc.

   translate <0, 0, (1.5*SIN60)>
  } // end texture #1

  texture { // #2
   cells
   texture_map {
    #for (N, 0, 0.9, 0.1)
     [N     T[N*10] ]
     [N+0.1 T[N*10] ]
     //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
" N*10 = ", str (N*10, 3, 1), "\n")
    #end
   }
   scale <3, 1, (3*SIN60)>
   // warp {repeat 3*.8660254*z offset <1.5,194.7,0>} // ditto
   translate <1.5, 0, 0>
  } // end texture #2

  texture { // #3
   cells
   texture_map {
    #for (N, 0, 0.9, 0.1)
     [N     T[N*10] ]
     [N+0.1 T[N*10] ]
     //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
" N*10 = ", str (N*10, 3, 1), "\n")
    #end
   }
   scale <3, 1, (3*SIN60)>
   // warp {repeat 3*.8660254*z offset <1.5,73.3,0>} //ditto
   translate <0, 0, 0>
  } // end texture #3

  //}
  //finish {ambient .05 diffuse .95}
  //scale .2
 } // end hexagon texture
} // end box


Post a reply to this message

From: Bald Eagle
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 3 May 2018 22:20:01
Message: <web.5aebc2a897bd16015cafe28e0@news.povray.org>
But I'm catching up  :D

the scale and the warp need to be immediately after cells, and before the
texture map.

This is still half-baked, but I think you can see how I worked it out.
(when warp gave me an error, I had commented it out, and forgot / read past it)
:(

I still need to properly implement the infinite-thickness text-object function
pigment pattern....   (Say that 5 times fast)

#version 3.7;
global_settings {assumed_gamma 1.0}

#include "colors.inc"

sky_sphere {pigment {rgb <1, 1, 1>}}

camera {
   location <0, 20, 0>    // position & direction of view
  look_at  <0, 0, 0.01>
  right x*image_width/image_height           // horizontal size of view
  up y // vertical size of view
 }

light_source {<0, 25, -1> color White}

#declare Num = array [10];
#for (N, 0, 9)
 #declare Num[N] = text {ttf "arialbd.ttf" chr(48+N) 1, 0 translate <0, 0, -0.5>
scale <1, 1, 1e6>}
#end


#declare T = array [10];
#declare f_Text = array [10];

#for (N, 0, 9)
 #declare f_Text[N] = function {
  pigment {
   pigment_pattern {
    object {Num[N]} // 1, 0}
    warp {repeat x}
    warp {repeat y}
   }
  }
 }
 #declare Current = CHSV2RGB(<N*36, 1, 1>);
 #declare T[N] =
  pigment {
   pigment_pattern {
    object {Num[N]} // 1, 0}
    warp {repeat x}
    warp {repeat y}
   }
   pigment_map {
    [0.0 rgbft Current]
    //[0.9 rgbft Current]
    [1.0 rgb 0]
   }
  scale 0.15
  rotate x*90
  }

#end

#declare SIN60 = sin (radians(60));

/*
// This seems to work fine
box {<-1, 0.1, -1>*10, <1, 0.02, 1>*10
 texture { // #1
            cells
            scale <3, 1, 3*SIN60>
            warp {repeat z*3*SIN60 offset <1.5, 357.4, 0>}
            texture_map {
   #for (N, 0, 0.9, 0.1)
    [N     T[N*10] ]
    [N+0.1 T[N*10] ]
    //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
" N*10 = ", str (N*10, 3, 1), "\n")
   #end
  }
 }


}
*/


#declare T_Clear = texture {pigment {rgbt 1}}
#declare Texture1 = texture { // #1
   cells
   scale <3, 1, 3*SIN60>
   warp {repeat 3*SIN60*z offset <1.5, 357.4, 0>}
   #declare ONE = on;
   #if (ONE)
    texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T[N*10] ]
      [N+0.1 T[N*10] ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
   #else
    texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T_Clear ]
      [N+0.1 T_Clear ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
   #end

   // the x-offset has to be 1.5, or can increase by
   // adding multiples of 3.0 -- 1.5, 4.5, 7.5 etc.

   translate <0, 0, (1.5*SIN60)>
  } // end texture #1

#declare Texture2 = texture { // #2
   cells
   scale <3, 1, (3*SIN60)>
   warp {repeat 3*SIN60*z offset <1.5, 194.7, 0>} // ditto
   #declare TWO = on;
   #if (TWO)
    texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T[N*10] ]
      [N+0.1 T[N*10] ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
   #else
    texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T_Clear ]
      [N+0.1 T_Clear ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
   #end

   translate <1.5, 0, 0>
  } // end texture #2

#declare Texture3 = texture { // #3
   cells
   scale <3, 1, (3*SIN60)>
   warp {repeat z*3*SIN60 offset <1.5, 73.5, 0>} //ditto
   #declare THREE = on;
   #if (THREE)
    texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T[N*10] ]
      [N+0.1 T[N*10] ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
   #else
    texture_map {
     #for (N, 0, 0.9, 0.1)
      [N     T_Clear ]
      [N+0.1 T_Clear ]
      //#debug concat ( " N = ", str (N, 3, 1),  " N+0.1 = ", str (N+0.1, 3, 1),
 " N*10 = ", str (N*10, 3, 1), "\n")
     #end
    }
   #end

   translate <0, 0, -0.5>
  } // end texture #3


box {<-1, 0, -1>*10, <1, 0.01, 1>*10
 texture {
  //pigment{
  hexagon

  texture {Texture1}

  texture {Texture2}

  texture {Texture3}

  //}
  //finish {ambient .05 diffuse .95}
  //scale .2
 } // end hexagon texture
} // end box

box {<-1, -0.02, -1>*10, <1, -0.01, 1>*10 texture {Texture3}}




/*
box {<-1, 0, -1>*10, <1, 0.01, 1>*10
 pigment {hexagon
  color Black,
  color Gray50,
  color White
  //rotate x*90
 }
}

#declare A = sqrt(3);
#declare B = A/2;

//mod(A,B)
//Value of A modulo B. Returns the remainder after the integer division of A/B.
Formula is  mod=((A/B)-int(A/B))*B.

#for (Z, -10, 10)
 #for (X, -10, 10)
  sphere {<X*3, 0, Z*A> 0.25 pigment {Red}}
  #debug concat ( " mod(", str (X, 1, 0), "*3, 3) = ", str (mod(X*3, 3), 3, 3),
" mod(", str (Z, 1, 0), "*A, A) = ", str (mod(Z*A, A), 3, 3),  "\n")
 #end
#end

#for (Z, -5, 5)
 #for (X, -3, 2)
  sphere {<(X*3)+1.5, 0, (Z*A)+B> 0.25 pigment {Green}}
 #end
#end
*/


Post a reply to this message

From: Kenneth
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 10 May 2018 05:40:00
Message: <web.5af412fa97bd1601a47873e10@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> Here's a much better-looking color_map to use (for all THREE pigments.)...
>
> The new one:
>     color_map{
>         [0.0 rgb <1,0,0>]
>         [0.5 rgb 0.47*<0,1,0>]
>         [1.0 rgb 0.99*<0,0,1>]
>              }
>
> OR, the srgb version...
>     color_map{
>         [0.0 srgb <1,0,0>]
>         [0.5 srgb .715*<0,1,0>]
>         [1.0 srgb .99*<0,0,1>]
>              }

Well, that's wrong :-/

The *idea* is to get a continuous spectrum of colors, from red to green to
blue-- and those index-list values certainly don't do that. The index should be
divided into THREE equal segments. The following is much better...

           blend_mode ...  // optional
           blend_gamma ... // optional
           [0.0     rgb <1,0,0>]
           [0.333   rgb <0,1,0>]
           [0.666   rgb <0,0,1>]
           [1.0     rgb <1,0,0>]

BTW, it makes no difference if you use srgb colors instead, because the three
colors are all at FULL intensity. The srgb 'gamma curve' only applies to values
*between* 0.0 and 1.0.


Post a reply to this message

From: Bald Eagle
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 10 May 2018 11:10:01
Message: <web.5af45fed97bd1601c437ac910@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> The *idea* is to get a continuous spectrum of colors, from red to green to
> blue-- and those index-list values certainly don't do that. The index should be
> divided into THREE equal segments.

Well, I'd suggest using the HSV color conversion macro in colors.inc, and
calculate the rgb values that way.  Not sure if that will give you exactly what
you want, but plugging in 0, 120, and 240 for hue angle values might just do it.

I think this ought to get you real close to what you want:
(untested - writing this in as close to the proper syntax as I can)

#declare Color1 = HSV2RGB (  0, 1, 1, 0, 0)
#declare Color2 = HSV2RGB (120, 1, 1, 0, 0)
#declare Color3 = HSV2RGB (240, 1, 1, 0, 0)

....

[(0/3) rgb Color1]
[(1/3) rgb Color2]
[(2/3) rgb Color3]
[(3/3) rgb Color1]


Post a reply to this message

From: Kenneth
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 15 May 2018 04:00:01
Message: <web.5afa92f697bd1601a47873e10@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > The *idea* is to get a continuous spectrum of colors, from red to green to
> > blue-- and those index-list values certainly don't do that. The index
> > should be divided into THREE equal segments...
> >
> >      blend_mode ...  // optional
> >      blend_gamma ... // optional
> >      [0.0     rgb <1,0,0>]
> >      [0.333   rgb <0,1,0>]
> >      [0.666   rgb <0,0,1>]
> >      [1.0     rgb <1,0,0>]
>
> Well, I'd suggest using the HSV color conversion macro in colors.inc, and
> calculate the rgb values that way.  Not sure if that will give you
> exactly what you want, but plugging in 0, 120, and 240 for hue angle
> values might just do it.
[snip]

I *finally got some free time to look into this. (The HSV and HSL color models
are new to me-- as well as CIELAB and etc etc-- so I looked those up as well.
There are certainly a lot of facts to digest when it comes to colors, and how
they can be represented!!)

I tried the CHSV2RGB macro experiment with your HSV values, and the
color-spectrum results are visually identical to using the rgb color_map above;
so, either one works well. (The macro's equations certainly do what they're
supposed to do, and very accurately!)


Post a reply to this message

From: Bald Eagle
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 15 May 2018 10:15:01
Message: <web.5afaeb1f97bd1601c437ac910@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

Excellent - I figured you were busy.  I haven't had much time to focus on any of
the various projects going on either.

Mike Horvath and clipka seem to be pretty active in modeling the various color
spaces, as evidence on Wikipedia.
Colors are indeed a lot more complicated than what people might naively assume
at first glance.  Like anything else, it's a combination of the wavelength(s)
involved, the eye receptors, the neurological interpretation of the sensed color
data, and in the case of the thing you're looking at, if it's printed - what
pigments, dues, waxes, inks are being used, and what range of colors they can
represent when mixed.

Which reminds me, I have to probably go back and fix an sRGB thing I was working
on and botched a while back.  :|


It's good to see that the simple color map gives a good [faux] HSV result - that
ought to be useful when I need to accomplish the same result yet keep the code
simple.

I looked a bit further into the method by which you accomplished the random
coloring of the hexagons, but haven't yet worked out how to specify a specific
number of colors to use.   Since you're color_mapping a 3-part pattern, I'm
assuming there may have to be a way to overlap the color maps for the various
parts, and there may be a few different ways to do that.

I haven't looked into the text / object pattering of the hexagon pattern - but
it's becoming clearer.

I'll bet it heating up down in VA - summer has arrived in NH   :O


Post a reply to this message

From: dick balaska
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 15 May 2018 12:21:55
Message: <5afb0923$1@news.povray.org>
On 05/15/2018 10:13 AM, Bald Eagle wrote:

>  Like anything else, it's a combination of the wavelength(s)
> involved, the eye receptors, the neurological interpretation of the sensed color
> data,
Like what else? ;)

-- 
dik
Rendered 328976 of 330000 (99%)


Post a reply to this message

From: Kenneth
Subject: Re: Hexagon pattern with 4 or 7 colors?
Date: 15 May 2018 17:15:00
Message: <web.5afb4c7097bd1601a47873e10@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> I looked a bit further into the method by which you accomplished the random
> coloring of the hexagons, but haven't yet worked out how to specify a specific
> number of colors to use.   Since you're color_mapping a 3-part pattern, I'm
> assuming there may have to be a way to overlap the color maps for the various
> parts, and there may be a few different ways to do that.
>

The built-in randomness of the 'cells' pattern underlies the random-colored
hexagons in my code, so for the THREE required cells patterns (all three, within
the hexagon outer pattern)), it's a simple matter of 'segregating' the distinct
colors. An example would be for five colors:

cells{
     color_map{
          [0.0 rgb <1,.3,.6>]
          [0.2 rgb <1,.3,.6>]
          [0.2 rgb <.5,.2,.7>]
          [0.4 rgb <.5,.2,.7>]
          [0.4 rgb <0,.5,.8>]
          [0.6 rgb <0,.5,.8>]
          [0.6 rgb <1,.5,.2>]
          [0.8 rgb <1,.5,.2>]
          [0.8 rgb <.3,1,.2>]
          [1.0 rgb <.3,1,.2>]
     }

BTW, blend_mode/blend_gamma have no effect on this kind of color_map-- there are
no 'continuous color blends' for blend_gamma to work on. (I suspected this, but
never tried it 'til now.)

If you really want to shake up the 'randomness', translate each color_map
(immediately after its closing curly bracket) with some integer, like
translate 37. A different integer for each of the three. The underlying cells
patterns have 1-unit cubes by default, so this moves those patterns off into
space before the hexagon pattern has a chance to 'see' them. (As I continue to
experiment with my code, I'm finding several different ways of 'improving' the
randomness.)


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.