 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This should have been bloody obvious --- but I'm slow. :|
Use the TRIANGLE pattern.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Success! Random-colored hexagons....
> ....
> texture{
> pigment{
> hexagon
> pigment{ // #1
> cells
> color_map{
> [0 rgb <1,0,0>]
> [.5 rgb <.3,1,0>]
> [1.0 rgb <0,0,1>]
> }
> ...
Here's a much better-looking color_map to use (for all THREE pigments.) The
original ones showed too much overall green. At first, I thought the problem was
due somehow to the simple index list I used-- 0.0 to 0.5 to 1.0 -- but the
solution was to dampen down the primary-green *intensity*. This new map has a
much more 'neutral' color appearance. To test it, I scaled the hexagon pattern
*really* small-- almost like noise-- then rendered it with AA (very important),
then took that image into Photoshop and blurred it. The resulting 'aggregate'
color was very close to neutral gray, as measured there... which is what the
three primary colors *should* look like, when combined correctly.
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>]
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> 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.
>
Lots of good suggestions to ponder-- but I've been up all night working on this
stuff(!), and my brian is fizzing out. Will come back later...
zzzzzz
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
...
>
> Here's a much better-looking color_map to use (for all THREE pigments.)
Well, it's only a 'basic' improvement-- the color choices are still only between
the three different hues of red, green and blue-- but it doesn't take into
account ALL the qualities of a color-space: hue, saturation (or tint), and
brightness. That's a much more difficult problem to solve, within a cells
pattern.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
