I wrote a pattern simulating the appearance of a stone wall made of
rectangular blocks of random size that interlock perfectly.  For an
example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
figured out how to integrate it into Pov-RAY so that I can call the pattern
by name and pass in parameters, so the only way to play with it right now
is to copy and paste my code into patterns.c and rename my "ashlar"
function to match the name of another pattern, and comment out that
pattern.

My code has been tested with Megapov .5, gcc, and Linux.

If someone wants to integrate it correctly into Pov-RAY, Megapov, or
whatever, be my guest.  You can get my code at
"http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?

-jim

Post a reply to this message

On 12 Jul 2001 21:35:58 -0400, Jim Snow wrote:
>If someone wants to integrate it correctly into Pov-RAY, Megapov, or
>whatever, be my guest.  You can get my code at
>"http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?

It's very interesting.  Have you done any calculations to determine what
the maximum search will have to be before you're guaranteed not to be on
a mortar line?  Have you considered using the Noise function instead of
a random array to determine the positions of the seed points?  That would
allow your "array" to be essentially infinite, if you could make it fit
into your algorithm, and it would constrain the positions of the seed 
points to an extent that you might be able to better predict what the 
maximum required search is.  

With those two changes, I think it would be a very useful pattern to 
have.  Also, I think you could get away with having just a single ratio
to determine the number of points horizontally vs. the number vertically,
since you can then scale the bricks to fit your space.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Isn't the cells pattern much like this?  I'm not exactly sure myself.

Bob H.

"Jim Snow" <jsn### [at] csgeorgefoxedu> wrote in message
news:01c10ad7$8462d300$4b821c26@jmsWin95...
>
> I wrote a pattern simulating the appearance of a stone wall made of
> rectangular blocks of random size that interlock perfectly.  For an
> example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
> figured out how to integrate it into Pov-RAY so that I can call the
pattern
> by name and pass in parameters, so the only way to play with it right now
> is to copy and paste my code into patterns.c and rename my "ashlar"
> function to match the name of another pattern, and comment out that
> pattern.
>
> My code has been tested with Megapov .5, gcc, and Linux.
>
> If someone wants to integrate it correctly into Pov-RAY, Megapov, or
> whatever, be my guest.  You can get my code at
> "http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?
>
> -jim

Post a reply to this message

cool except for one thing.  from your picture, it looks like it is a 2d
pattern, not a 3d one.  bummer.

Jim Snow wrote:
> 
> I wrote a pattern simulating the appearance of a stone wall made of
> rectangular blocks of random size that interlock perfectly.  For an
> example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
> figured out how to integrate it into Pov-RAY so that I can call the pattern
> by name and pass in parameters, so the only way to play with it right now
> is to copy and paste my code into patterns.c and rename my "ashlar"
> function to match the name of another pattern, and comment out that
> pattern.
> 
> My code has been tested with Megapov .5, gcc, and Linux.
> 
> If someone wants to integrate it correctly into Pov-RAY, Megapov, or
> whatever, be my guest.  You can get my code at
> "http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?
> 
> -jim

Post a reply to this message

On Thu, 12 Jul 2001 20:07:58 -0700, Ryan Constantine wrote:
>cool except for one thing.  from your picture, it looks like it is a 2d
>pattern, not a 3d one.  bummer.

He mentions that in the code, actually.  I think the concept could be
extended to 3d without too much work, but it'd take some thought to
do it right.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

Ryan Constantine <rco### [at] yahoocom> wrote in article
<3B4E660E.5D7C1577@yahoo.com>...
> cool except for one thing.  from your picture, it looks like it is a 2d
> pattern, not a 3d one.  bummer.

I think the algorithm can be generalized to 3d (but it might be beyond my
ability to do so), however there would be a problem with the mortar joints
parallel to the surface of the object occasionally being at the surface of
the object, resulting in an oddly textured block.  It might not be that big
of deal, but it would probably be annoying to anyone who just wants their
stone wall to look good from one side.

-jim

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote in article
<slr### [at] fwicom>...
> On 12 Jul 2001 21:35:58 -0400, Jim Snow wrote:
> >If someone wants to integrate it correctly into Pov-RAY, Megapov, or
> >whatever, be my guest.  You can get my code at
> >"http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?
> 
> It's very interesting.  Have you done any calculations to determine what
> the maximum search will have to be before you're guaranteed not to be on
> a mortar line?  Have you considered using the Noise function instead of
> a random array to determine the positions of the seed points?  That would
> allow your "array" to be essentially infinite, if you could make it fit
> into your algorithm, and it would constrain the positions of the seed 
> points to an extent that you might be able to better predict what the 
> maximum required search is.  
> 
> With those two changes, I think it would be a very useful pattern to 
> have.  Also, I think you could get away with having just a single ratio
> to determine the number of points horizontally vs. the number vertically,
> since you can then scale the bricks to fit your space.
> 
> -- 
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z
a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F
T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission
T}}finish{
> reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
> 

I think that a mortar line can continue infinitely if the points are
arranged in an "unlucky" fashion.
Therefore, it doesn't matter how big the search grid is, you could still
get lines that abruptly stop
without running into anything.  However, I have modified the way "random"
points are chosen in
such a way to make it unlikely that a line makes it much more than one unit
away.  I haven't tested
it enough to be sure, but with search=2, bad lines should be very rare. 
The test image on my web
page used search=1.

I thought of two possible solutions to this:

1.	Pick "random" points within each box such that it is impossible to
project a vertical or horizontal line through the box without it
intersecting a mortar line.

2.	Any mortar line longer than some maximum distance from its originating
point automatically splits at the max distance and sends out mortar lines
in either direction perpendicular to the original mortar line that continue
until they collide with some other mortar line.

I haven't come up with a trivial algorithm for either solution.

I'll think about using a noise function for the "random" data - my array of
random vectors isn't very elegant, even if it is fast.

extra note:  I tried out Megapov 0.7 today - My patch didn't work quite
right without adding &0xFFF to the arguments to Hash2d(int, int).  Strange.

-jim

Post a reply to this message

Bob H. <omn### [at] msncom> wrote in article <3b4e5daa@news.povray.org>...
> Isn't the cells pattern much like this?  I'm not exactly sure myself.
> 
> Bob H.
> 

No, the cells pattern picks a random value between 0 and 1 for each unit
cube, such that every point in each cube has the same value.  My pattern
creates blocks of random dimensions that interlock.

-jim

Post a reply to this message

On 13 Jul 2001 03:31:10 -0400, Jim Snow wrote:
>
>
>Ryan Constantine <rco### [at] yahoocom> wrote in article
><3B4E660E.5D7C1577@yahoo.com>...
>> cool except for one thing.  from your picture, it looks like it is a 2d
>> pattern, not a 3d one.  bummer.
>
>I think the algorithm can be generalized to 3d (but it might be beyond my
>ability to do so), however there would be a problem with the mortar joints
>parallel to the surface of the object occasionally being at the surface of
>the object, resulting in an oddly textured block.  It might not be that big
>of deal, but it would probably be annoying to anyone who just wants their
>stone wall to look good from one side.

Quite true.  That happens with bricks and with crackle occasionally as 
well.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Jim Snow <jsn### [at] csgeorgefoxedu> wrote:


> I wrote a pattern simulating the appearance of a stone wall made of
> rectangular blocks of random size that interlock perfectly.  For an
> example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
> figured out how to integrate it into Pov-RAY so that I can call the pattern
> by name and pass in parameters, so the only way to play with it right now
> is to copy and paste my code into patterns.c and rename my "ashlar"
> function to match the name of another pattern, and comment out that
> pattern.

Very interesting.  Have you seen my isosurface stone walling code?  It looks
to be doing similar sorts of things, though I think mine is a little bit
more intelligent (in that it does things as a stone mason might do, like
making sure stones are wider than tall, etc)  It's slow, since it's in pov
native code, and then uses iso surfaces, but on the other hand, allows for
lots of nifty stuff like roughing up the surface and morphing it into cones
and cylinders and such by changing the iso function.

I haven't looked at your code since I'm pretty much a novice to the POV
source.

Geoff

Post a reply to this message