 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
