"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