Stephen <mca### [at] aolcom> wrote:
> On 21/04/2018 20:33, Kenneth wrote:
> > Actually, it would need to be <1.5,2,3.5>-- the .5 part of the x and z offsets
> > correctly shift the (1-unit) cells/cubes for the next higher 'alternating' row
> > of bricks. Without that, the alternate rows of bricks show half of one
> > color and half of another-- because the bricks themselves are naturally
> > offset by this amount.
>
> Would <1.5,2,3.5> * 2 not work?
>
No, because you would end up with  <3,4,3>, which would be the wrong 'degree' of
offset in x and z-- for every *other* row of bricks. (Y of 4 is perfectly OK,
though.)

To better explain what's going on with the warp{repeat...}, , I made an image of
various changes to POV-Ray's own brick pattern, using my embedded cells pattern.
And remember that the 'mortar' is actually  a completely different entity; its
own color or pattern is spatially 'global', not sliced up into 'brick units.'

In the image:
1) This is just the default cell size, along with a brick_size of <1,1,1>-- to
show the basic mismatch between the cells' cubic nature, vs. the brick pattern's
alternating brick layout. Also, the 'diagonal' repetitions of brick colors are
obvious. Here's the complete texture for this image (somewhat simplified, and
without normals), which will be changed later...

texture{
       brick
       texture{ ...} // the MORTAR
       texture{ // the BRICKS
           pigment{
                cells // 1 X 1
                color_map{
                      blend_mode 2 // optional
                      blend_gamma 1.6 // optional
                     [0 rgb 0]
                     [1 rgb 1]
                                     }
          //  warp{repeat y offset <....>} // no warp yet
         //   translate ...*z // no translation yet
         //   scale <...> // no scale yet-- default of <1,1,1>
                  } // end of this pigment
           finish{...}
              } // end of this texture

        // still part of the overall 'brick' TEXTURE
       brick_size <1,1,1> //  matches the default-size cells pattern
       mortar .08
        scale ... // FINAL scale
      } // end of overall texture

2) Same as 1), but with   warp{repeat y offset <1,0,0>}  (and nothing else
changed or added.) This shows the same basic alternate-row mismatch, even though
the cell 'cubes' and the brick_size are the same. So the amount of offset is
wrong. And the diagonal pattern is still there.

3) This has ...

warp{repeat y offset <.5,0,.5>}
translate .5*z

but no other changes. The cell cubes now align with the brick pattern-- but the
diagonal repeating brick colors are still there, because the repeats of .5 are
still choosing the color *midway* through a particular 1X1-unit cell 'cube',
instead of from a new cube.

4)  Same as 3, but with some different scalings, to get a more realistic brick
size... although the unwanted diagonal pattern still appears, naturally.

5) Same as 4), but with a different warp...
warp{repeat y offset <.5,1,.5>

This looks MUCH more random-- and the offsets probably don't need any further
changes or LARGE offsets, like I originally thought. The key to the randomness
is that, for every higher row of bricks, the offsets are now choosing
*completely* different cell colors-- mainly because the cells pattern itself
already has random-color cubes. The combination of offsets effectively chooses a
new cube color for each and every brick. Or so it seems ;-) Adding more integers
to the offsets will not harm anything, but it's probably unnecessary-- unless
you want to animate ever-changing brick colors!

Post a reply to this message

Attachments:
Download 'brick_warp_repeat_examples.jpg' (1727 KB)

Preview of image 'brick_warp_repeat_examples.jpg'