POV-Ray : Newsgroups : povray.binaries.programming : new pattern simulating a wall of interlocking rectangular stones of unequal size : Re: new pattern simulating a wall of interlocking rectangular stones of unequal size Server Time
22 Dec 2024 00:41:11 EST (-0500)
  Re: new pattern simulating a wall of interlocking rectangular stones of unequal size  
From: Jim Snow
Date: 13 Jul 2001 04:11:32
Message: <01c10b0e$c7526cc0$93811c26@jmsWin95>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.