On 13 Jul 2001 04:11:32 -0400, Jim Snow wrote:
>I think that a mortar line can continue infinitely if the points are
>arranged in an "unlucky" fashion.

I'm not convinced that that is true, but proving it either way could be
an interesting project all by itself.

>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.

This seems like the best solution.  I have some not-very-well-formed thoughts
on this, which I'll elucidate below.

>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.

You might find how the crackle function works interesting.  As you probably
know, the crackle pattern is a 3d voronoi diagram.  Each "stone" has an
apparently randomly positioned centroid, and every point that is closer to
that centroid than to any other is part of that stone.  What isn't so 
obvious on casual examination is that the centroids are not really as 
random as they appear.  All of space is divided into 1x1x1 cubes, and each
cube contains exactly one centroid.  The location of each centroid is 
determined by the values of the Noise3D function at some fixed point within
its enclosing cube, allowing it to be reproducibly calculated as needed.

So, here is my thought:  Pick your seed points the same way crackle picks
its centroids (except in 2D, obviously.)  For each square, determine the 
sum of its coordinates.  If that sum is even, make the seed point draw a 
horizontal line.  If it's odd, make the seed point draw a vertical line.  
Now, when a mortar line leaves its enclosing square it's likely to meet a 
line going the other way within the next square (unless the line going the 
other way was stopped by the line that came from the opposite face of the 
square.)   It's still possible to have infinite lines, but they're very 
very unlikely.  It's unlikely that a line will make it more than 3 squares
away, I'd think, meaning you might need to search as many as 50 points
for each test.  But you should be able to cache the results of those tests
to some extent to take advantage of some of the spatial coherence in the
raytracing algorithm, as the crackle pattern does.

-- 
#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{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Jim Snow wrote:
> 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.

Macro HashXd was changed in last version of MegaPOV, see file texture.h,
there is conditional directive:
#ifdef NoiseTranslateFixPatch
In megapov news ( http://nathan.kopp.com/patched.htm ) probably this
line refers to it:
7. Fixed a bug, reported by Nicolas Calimet, in the TransformPatch
(9.2.9) 
Unfortunately I don't remember, what was the proble with this
transformation.

In order to fix this 'nicely' you have to use conditional compilation:
#ifdef NoiseTranslateFixPatch
// use this:
x = Hash2d(a&0xfff, b&0xfff);
#else
x = Hash2d(a, b);
#end
#endif

I had the same problem when merged my code with MegaPOV.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote in article
<slr### [at] fwicom>...
> So, here is my thought:  Pick your seed points the same way crackle picks
> its centroids (except in 2D, obviously.)  For each square, determine the 
> sum of its coordinates.  If that sum is even, make the seed point draw a 
> horizontal line.  If it's odd, make the seed point draw a vertical line. 

> Now, when a mortar line leaves its enclosing square it's likely to meet a

> line going the other way within the next square (unless the line going
the 
> other way was stopped by the line that came from the opposite face of the

> square.)   It's still possible to have infinite lines, but they're very 
> very unlikely.  It's unlikely that a line will make it more than 3
squares
> away, I'd think, meaning you might need to search as many as 50 points
> for each test.  But you should be able to cache the results of those
tests
> to some extent to take advantage of some of the spatial coherence in the
> raytracing algorithm, as the crackle pattern does.
> 
> -- 
> #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{rgbf 1}hollow interior{media{emission
3-T}}}#end 
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
> 

I thought about alternating verticals and horizontals, but decided it would
make the texture look a little too predictable.  However, the algorithm
could be vastly simplified - instead of testing distance from the
originating points to determine which mortar line wins when they intersect,
I could make it so that a mortar line always wins within its own square and
loses outside its own square.  The search grid would only have to be 3x3 to
garuntee that no line escapes the grid.

Maybe I should try to make a 3d version with the simpler algorithm.

-jim

Post a reply to this message

On 13 Jul 2001 15:33:26 -0400, Jim Snow wrote:
>
>I thought about alternating verticals and horizontals, but decided it would
>make the texture look a little too predictable.

I drew a dozen or so squares by hand and it didn't look as predictable as
one might expect, believe it or not.

>  However, the algorithm
>could be vastly simplified - instead of testing distance from the
>originating points to determine which mortar line wins when they intersect,
>I could make it so that a mortar line always wins within its own square and
>loses outside its own square.  The search grid would only have to be 3x3 to
>garuntee that no line escapes the grid.

And you wouldn't have to test the corner squares, either.


-- 
#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

"Jim Snow" <jsn### [at] csgeorgefoxedu> wrote in message
news:01c10b10$0b7fed40$93811c26@jmsWin95...
> 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.
> >
>
> 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.

Sorry, yes, I see now.  I thought the cells pattern could be changed somehow
but it looks like turbulence is about it, and that only deforms the
boundaries in nonlinear ways.
Thanks for replying to clear that up.

Bob H.

Post a reply to this message

Geoff Wedig <wed### [at] darwinepbicwruedu> wrote in article
<3b4ef7c6@news.povray.org>...
> 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
>

Where can I find this code?

By the way, you can make the stones tend to be more wide than high and vice
versa with my algorithm by tweaking some numbers in the c code.  I was
thinking of using my function in an isosurface, but I haven't really
figured out how isosurfaces work.

-jim

Post a reply to this message

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



> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote in article
> <3b4ef7c6@news.povray.org>...
>> 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
>>

> Where can I find this code?

It's never been publically released, due to lack of docs.  But it's pretty
well commented.  It started out as an isosurface update to the mur.inc, but
then I decided that the algorithm used in mur.inc was inadequate for my
needs.  If you want a copy, let me know and I'll send you the files.

> By the way, you can make the stones tend to be more wide than high and vice
> versa with my algorithm by tweaking some numbers in the c code.  I was
> thinking of using my function in an isosurface, but I haven't really
> figured out how isosurfaces work.

They're not as hard as they seem to be at first glance.  I've become quite
enamored with them.  But there is a learning curve, mostly due to a lot of
parameters that, without a good idea of how they work, don't make much
sense.

Geoff

Post a reply to this message