 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/04/2018 à 22:31, Kenneth a écrit :
> 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!
>
When you speak of outside & inside, I think about the Florence(IT) dome,
made of bricks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> On 22-4-2018 9:49, Bill Pragnell wrote:
> > OK, I thought of something else to do with bricks :)
> >
>
> Brilliant!
>
I agree!! What a beautiful and interesting use-- and what possibilities it opens
up! REALLY nice.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2018 19:00, Kenneth wrote:
> 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.)
Oh! I thought it might be too simple a solution.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sven Littkowski <I### [at] SvenLittkowskiname> wrote:
> Is there any way, to derivate a "deck planks" version from these bricks?
> On my own, I am trying hard, since weeks, but not being successful yet.
Yes, I think it's perfectly possible, using POV-Ray's own brick pattern
(disregarding the 'mortar' part of it or scaling its thickness to zero to make
it essentially invisible.) It should be a simple(??) matter of putting a 'wood'
pattern inside the 'cells' pattern as described earlier-- the 'wood' being in
the cell's pigment_map. Like this...
cells
pigment_map{
[.5 my-wood-pigment] // with maybe some kind of black-hole
// warp to create 'knots' in the wood?
}
.... if you want only one wood pattern. (If you put more than one pigment into
the pigment_map, the cells pattern will 'blend' them in random ways, which may
not be very realistic, IMO.)
Then flip the entire overall texture-- rotate 90*x -- to make the pattern
horizontal for your wooden deck.
The only problem with using the brick pattern for such wood planking is that the
planks will all be the same length and width-- like regular bricks are. I would
imagine that a more realistic wood floor would look better with *random*-sized
planks (or at least with random lengths.) I don't *think* that's possible using
the 'brick' pattern, which has a preset way of making its bricks all the same
size.
Maybe my 'made from scratch' brick pattern could be altered to do this; I
haven't tried it.
HOWEVER, using POV-Ray's own brick pattern, and with the mortar scaled to zero
so as not to show, there may be a way to make random-sized wood planks-- or what
*look* like that-- by some odd scalings of the cells pattern AND different
'offsets' in the warp{repeat y offset <...>}. While I was originally
experimenting with all this brick stuff, and choosing *wrong* warp offsets, I
did come up with *mistakes* that may be useful for such wood planking. I would
suggest taking my latest brick code and 'wrongly' altering the scales and warp
repeat values, to see what occurs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gorgeous!!!
---
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just don't know, how to prevent the continuation of the grain into the
surrounding planks. At the moment, I have a nice deck planks texture.
Just the grain continues. That shouldn't be. i sense, WARP has to be
used in some way, but that is exactly what IO don't know how to use
correctly.
---
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sven Littkowski <I### [at] SvenLittkowskiname> wrote:
> This is the code i have right now. Looks alright, just the grain
> continues into each other "brick"...
Here's a simple example which will 'randomise' a pigment into bricks in the X-Z
plane (I assume if you're after a floor texture, you're not worried about it
looking good in any other planes).
#declare BX = 0.75;
#declare BZ = 0.25;
#declare YOffset = 2;
#declare MaxSceneSize = 100;
#declare Example = pigment {
bozo color_map { [0 rgb 0] [1 rgb 1] }
scale 0.1
warp { repeat x*BX offset y*YOffset }
warp { repeat z*BZ offset x*(MaxSceneSize + 0.5)*BX }
}
BX and BZ are the x and z brick dimensions. YOffset is an out-of plane offset
that gives the randomness - it only needs to be big enough to produce a
noticeable change in the pattern. MaxSceneSize is the row-on-row offset to make
sure the repetition is out of sight (or just not noticeable).
Obviously you'll need to synchronise the pattern and the warps between pigments
and normals so they match up. Your example code was two layered textures so
it'll be best to #declare stuff so you can change it easily. You were using wood
textures, so I don't know if you were relying on the core of the pattern - my
YOffset tactic might not work well with that. Good luck!
Nice wood texture btw ;-)
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> HOWEVER, using POV-Ray's own brick pattern, and with the mortar scaled to zero
> so as not to show, there may be a way to make random-sized wood planks-- or what
> *look* like that-- by some odd scalings of the cells pattern AND different
> 'offsets' in the warp{repeat y offset <...>}.
Here's an example of that idea, using two different 'wood' color_maps from the
"woodmaps.inc" include file, and some necessary warp{turbulence..} for each one.
No normals here, though. (Making matching normals for this kind of thing turned
out to be more difficult than I thought. Not impossible, of course... just more
work.)
Post a reply to this message
Attachments:
Download 'bricks_as_wood_1.jpg' (678 KB)
Preview of image 'bricks_as_wood_1.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|
