 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> wrote:
>
> However, I'm also wondering if I can't somehow come up with a pattern
> that would allow the tricks over in the bricks pattern thread to be used.
> Or if somehow that trick can be applied to the existing hexagon pattern[s]
> to eliminate the need for writing a special function.
You've inspired me; I'm experimenting with that idea...not with the 'brick'
pattern, but just using the cells pattern for the three hexagon 'triad'
pigments. The *fundamental* idea proves true: that the random cells colors can
create random-colored hexagons. But to get the colors to be scaled and placed
correctly in each hexagon shape requires *some* kind of warp{repeat.. offset
<...>} configuration that I haven't yet figured out. (The hexagon pattern itself
obviously has its own inner repeating/offset behavior, which might be messing
with things. And the cells pattern's default grid-position doesn't match the
layout of the hexagon pattern-- another complication.)
Although hexagon require 3 colors or pigments, it's easier for me at this stage
to use just ONE. (The other two hexagons of the 'triad' turn out black, which is
OK.)
This code is the general idea (horizontal on the x/z plane) -- but where to put
the warp{...} and the scales, and what they should be, is still a 'work in
progress'... ;-) The hexagon shape has 'inner angles' of 120-degrees at it's
points, so some of this code uses sin of 60-degrees to try and get the
cells-pattern scales to properly match the hexagon scales (I had to brush-up on
my trigonometry, ha):
pigment{
hexagon
pigment{ // #1
cells
color_map{
[0 rgb <1,0,0>]
[.5 rgb <0,1,0>]
[1.0 rgb <0,0,1>]
}
scale 1
// warp{repeat x offset <0,0,2>} // ???
//translate <-.5,0,-.5> // ???
scale <2 + 1,1,2*.8660254> // .8660254 is sin of 60-degrees
translate <1.5,0,2*.8660254> // ???
}
// pigment #2...
// pigment #3...
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No time to think about this very much at the moment, but the hexagon pattern is
alternating offset rows --- _almost_ similar to brick.
https://forum.processing.org/two/discussion/6735/hexagon-grid-with-almost-random-colour-fills-same-colour-adjacencies-m
inimized
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> No time to think about this very much at the moment, but the hexagon pattern is
> alternating offset rows --- _almost_ similar to brick.
>
> https://forum.processing.org/two/discussion/6735/hexagon-grid-with-almost-
> random-colour-fills-same-colour-adjacencies-minimized
That looks interesting; I'm 'absorbing' some of the pertinent details and
letting them cook in the ol' brain.
I think you're right about the brick pattern; it seems to be tailor-made for
this problem (with a mortar thickness of zero.) I'll try that approach instead.
(I was hoping to work something out from 'first principles''-- those being the
cells pattern and warp{..}, ha-- which are not exactly 'fundamental', I admit!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This should have been bloody obvious --- but I'm slow. :|
Use the TRIANGLE pattern.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> This should have been bloody obvious --- but I'm slow. :|
>
> Use the TRIANGLE pattern.
(triangular)
But even more intriguing is the possibility to select the color based off a set
of two rectangular grids.
If rand can be used in a function, then along with mod and select, there might
be the chance this can somehow be applied to the problem.
I haven't had an uninterrupted minute to think about it clearly...
#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}
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;
#for (Z, -5, 5)
#for (X, -3, 3)
sphere {<X*3, 0, Z*A> 0.25 pigment {Red}}
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.05.2018 um 02:24 schrieb Bald Eagle:
> If rand can be used in a function,
it cannot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'll probably be posting some links here as a repository for working this out
further.
I found this, which seems to delve into some off the ideas I've been mulling
over. The adaptation of a cubic pattern is something I was trying to work out,
having noticed this while doing my rgb color mapping project.
https://www.redblobgames.com/grids/hexagons/
I think the best way to further pursue this would be to define specific
hierarchical goals and expand that into pseudocode.
Then perhaps we can see if that can be adapted into a function-only pattern with
a 0-1 result that can be properly color/pigment/texture/material mapped.
It would be especially lovely if this could be expanded into a diamond-lattice
space-filling pattern as well. And I might not be surprised if using a
backwards-approach from 3D to 2D or 4D to 3D by projection, or a geometric
inversion would somehow yield a solution. There's a lot of stuff out there,
and sometimes I only have a whiff of what might be useful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some good explanations and algorithms here as well:
http://catlikecoding.com/unity/tutorials/hex-map/part-1/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> You've inspired me; I'm experimenting with that idea...
Success! Random-colored hexagons. I didn't have to use the 'brick' pattern, just
cells.
-- For a horizontal surface, which is the default orientation of the hexagon
pattern.--
The three color-triad pigment blocks in the code are *almost* identical, but the
success lies in their translations, and in the offsets in warp{repeat...}. The
y-offsets are interesting-- they're actually arbitrary values, just to choose
some new 'color cubes' of the cells pattern. The cell colors are random from
cube to cube anyway, but the offsets kind of guarantee that the warp{repeats..}
are far separated from each other. Perhaps they're not really necessary; but
reduce the y-values to zero to see.
By default, each straight edge of POV-Ray's hexagon shape is 1-unit in length.
So the distance between opposite POINTS or vertices is 2.0 units, and the
distance between opposite EDGES is 2*sin(60), or 2*.8660254 units. The cells
patterns are scaled and translated so that they fully overlap each full hexagon
(but the overlaps aren't seen.)
The links that Bald Eagle provided were quite helpful with the hexagon math
details. (Thanks!)
Instead of fully random colors, the pigment_maps could have 4 or 7 or however
many 'segregated' colors, which was the original idea.
--------
texture{
pigment{
hexagon
pigment{ // #1
cells
color_map{
[0 rgb <1,0,0>]
[.5 rgb <.3,1,0>]
[1.0 rgb <0,0,1>]
}
scale <3,1,3*.8660254>
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*.8660254>
}
pigment{ // #2
cells
color_map{
[0 rgb .5*<1,0,0>]
[.5 rgb .5*<.3,1,0>]
[1.0 rgb .5*<0,0,1>]
}
scale <3,1,3*.8660254>
warp{repeat 3*.8660254*z offset <1.5,194.7,0>} // ditto
translate <1.5,0,0>
}
pigment{ // #3
cells
color_map{
[0 rgb .25*<1,0,0>]
[.5 rgb .25*<.3,1,0>]
[1.0 rgb .25*<0,0,1>]
}
scale <3,1,3*.8660254>
warp{repeat 3*.8660254*z offset <1.5,73.3,0>} //ditto
translate <0,0,0>
}
}
finish{ambient .05 diffuse .95}
scale .2
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Success! Random-colored hexagons. I didn't have to use the 'brick' pattern, just
> cells.
Pretty damned impressive, my friend. :)
"Whenever possible, let POV-Ray do the heavy lifting."
Very nice work applying the [warped] cells pattern.
> So the distance between opposite POINTS or vertices is 2.0 units, and the
> distance between opposite EDGES is 2*sin(60), or 2*.8660254 units. The cells
> patterns are scaled and translated so that they fully overlap each full hexagon
> (but the overlaps aren't seen.)
Excellent. I wouldn't have guessed that the squares would work well with the
hexagons, but --- lookitthat!
> The links that Bald Eagle provided were quite helpful with the hexagon math
> details. (Thanks!)
Any time. You've managed to get a good grasp on intertwining pigment patterns,
and I'd like to make a few suggestions for improvement so that it's usable for
experienced and new users alike.
> Instead of fully random colors, the pigment_maps could have 4 or 7 or however
> many 'segregated' colors, which was the original idea.
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.
#declare FullHexagon = texture {....}
and obviously remove the finish {} block so that it can be applied by the
end-user.
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.
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)>
Maybe include a way to specify dimensions based on different metrics: edge to
edge, point to point, etc.
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.
I'm trying to get my car repaired - AGAIN - and so I'm gonna be AFK for a while.
If there's a way to tie in the numeric pattern that I applied to crackle{} and
wood{}, that would help the use choose/modify the color pattern without a lot of
guessing.
.... and I see an obvious tie-in with the recently posted solution to the digital
camo! :D
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.
Once again - super work, and super FAST! :O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
