"Kenneth" <kdw### [at] gmailcom> wrote:

> The only problem now is that the SIDE walls of the brick building are scaled
> totally wrong. (Likewise, trying to use scale <.01,0,.01> will mess up ALL the
> brick faces.)...

Sorry; for what it's worth, that should have been <.01,1,.01>

I need to do better proof-reading before I post :-O

Post a reply to this message

> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>> Throughout my (many!) experiments with this, I noticed a kind of repeating
>> diagonal pattern of the bricks, when using just <.5,0,.5> for the warp
>> 'offsets.'...
> 
> The answer just occured to me!
> 
> 1) The cells pattern is naturaly composed of cubes.
> 2) Those cubes have a thickness in all dimensions-- naturally!
> 3) The warp 'repeats' of <.5,0,.5> are apparently smaller than the cube
> dimensions. So when the next row of bricks is created-- starting at y=0 --
> there's a very good chance that the *same*-colored cube will be chosen for some
> of the bricks in th next (offset) brick row. That is, until the <.5,0,.5>
> offsets get to another differently-colored cube, spatially speaking.
> 
> To test this, I scaled the cells pattern to be much smaller in z, immediately
> before the warp{repeat...} statement...
> 
> scale <1,1,.01>
> warp{repeat y offset <.5,0,.5>
> 
> As expected, this eliminates the 'diagonal' pattern! On the FRONT face, that is.
> The only problem now is that the SIDE walls of the brick building are scaled
> totally wrong. (Likewise, trying to use scale <.01,0,.01> will mess up ALL the
> brick faces.) So there's no easy way to eliminate the 'diagonal' pattern by
> squasing the cubes-- except to keep them at their regular cubic shape and then
> to make the OFFSETS much larger, as I did. Perhaps there's another more-involved
> method which will work, but I can't think of one...
> 
> 
> 
> 
> 

The blocks in the cells pattern are 1 unit large in all directions. Try 
using integer offset. This will ensure that each bricks layers get their 
colours from different cells layers, as well as different columns and rows.

warp{repeat<1,2,3>}

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

>
> The blocks in the cells pattern are 1 unit large in all directions. Try
> using integer offset. This will ensure that each bricks layers get their
> colours from different cells layers, as well as different columns and rows.
>
> warp{repeat<1,2,3>}

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.

But I have to admit that the y-offset of just 2 makes the unwanted diagonal
brick pattern look 'more' random. It's *similar* to my use of <1000.5,0,999.5>,
which shifts the offsets to much farther along in the cells pattern. But I had
neglected changing the y-offset-- mainly because I didn't fully understand what
was going on with warp{repeat...} in my earlier tests ;-) Thanks for the hint;
it's all becoming clearer now.

Post a reply to this message

Here's an interesting geometric problem to think about:

A large solid structure made of alternating-row bricks may look correct on the
outside-- but what should the inside volume of that structure look like? In
other words, what 'layout' of alternating bricks would work best for the inside
volume, while *still retaining* the correct outside appearance? I don't think
it's possible; the inside would need some kind of 'herringbone'(?) brick
layout-- but the outside surface would invariably show some brick' ends', rather
than full-length bricks.

POV-Ray's 'brick' pattern (or even using a 'made from scratch' variety) shows
that the inner bricks are either square or in some other ratio-- but the bricks
repeat regularly, with no offsets.

The only way I can see of making such a real-life structure is to have the
outside bricks as one pattern (a 'shell' of bricks), while the inside volume
uses a different brick-layout altogether. I wonder how real bricklayers
('masons') approach this problem... if they deal with it at all!

Post a reply to this message

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?

-- 

Regards
     Stephen

Post a reply to this message

I'm not following what the problem is.
Maybe you can make a diagram or post a few example renders that demonstrate the
issue?


I was also thinking that maybe you could try rgbt 1 as the brick, and let the
mortar "float" so that it's a lattice - and you can see through it.
maybe define a pigment_map so that the center is colored and the outer edges are
transparent.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Throughout my (many!) experiments with this, I noticed a kind of repeating
> diagonal pattern of the bricks, when using just <.5,0,.5> for the warp
> 'offsets.'

You're right, I was just using larger bricks so the repetition was less
noticeable. Using 1.5, or staggering it in x and y as Alain suggested, does
lessen the effect. This feels like something I noticed, then fixed, then
immediately forgot that I fixed it and why!

Bill

Post a reply to this message

OK, I thought of something else to do with bricks :)

The code for this is a little bit hairy, but it basically entails making my own
cells pattern by sampling a declared pigment as a function. I can't use the
repeat warp trick because of the sampling, so instead I have to bake the offset
into the function call. This also offsets the sampled pigment, so I have to
pre-offset that in the other direction before using it.

// these are for the brick light/dark variation
#declare LightRand = pigment {
 bozo color_map { [0 rgb 0.5] [1 rgb 1] } scale 0.01
}
#declare DarkRand = pigment {
 bozo color_map { [0 rgb 0.1] [1 rgb 0.5] } scale 0.01
}

// bricks size can't be in a vector if it's to be used in a function call
#declare BSX = 0.5;
#declare BSY = 0.25;
#declare BSZ = 0.5;

// function version of the base pigment (using object Obj here)
#declare WallPigFn = function { pigment {
 object { Obj pigment { LightRand } pigment { DarkRand } }
} }
// pre-offset version of the base pigment
#declare WallPigFnOffset = function {
 WallPigFn(
  x - 0.5*BSX*floor(y/BSY),
  y,
  z - 0.5*BSZ*floor(y/BSY)
 ).x
}

// colour scheme
#declare LCol = <1, 0.5, 0.5>;
#declare DCol = <0.2, 0.2, 0.5>;

// cells-like sampled brick pattern
#declare SampledBrick = pigment {
 function {
  WallPigFnOffset(
   BSX*floor((x+0.5*BSX*floor(y/BSY))/BSX) + 0.5*BSX,
   BSY*floor(y/BSY) + 0.5*BSY,
   BSZ*floor((z+0.5*BSZ*floor(y/BSY))/BSZ) + 0.5*BSZ
  )
 }
 color_map {
  [0 rgb 0.1*DCol]
  [0.5 rgb DCol]
  [0.5001 rgb 0.1*LCol]
  [1 rgb LCol]
 }
 translate z*0.5*BSZ
}
// now with mortar
#declare CombinedSampled = pigment {
 brick
 pigment { rgb 0 }
 pigment { SampledBrick }
 brick_size <BSX, BSY, BSZ>
 mortar 0.035
}

Post a reply to this message

Attachments:
Download 'textbricks.jpg' (293 KB)

Preview of image 'textbricks.jpg'

On 22-4-2018 9:49, Bill Pragnell wrote:
> OK, I thought of something else to do with bricks :)
> 

Brilliant!

[I /have/ to play with this...]

-- 
Thomas

Post a reply to this message

On 04/22/2018 03:49 AM, Bill Pragnell wrote:
> OK, I thought of something else to do with bricks :)
> 
> 
Excellent!

Bill Po.

Post a reply to this message