"Kenneth" <kdw### [at] earthlinknet> wrote

> BTW, in working with this technique (and running some other experiments),
I've
> found that rand() doesn't actually HIT zero or one.

A pseudo random generator should in practice not hit *any* given number, not
just 0 and 1, unless you cover its period at least a few times. Further, in
practice again, some (or many) numbers in range will simply be "unhittable".

Post a reply to this message

"somebody" <x### [at] ycom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote
>
> > BTW, in working with this technique (and running some other experiments),
> I've found that rand() doesn't actually HIT zero or one.
>
> A pseudo random generator should in practice not hit *any* given number, not
> just 0 and 1, unless you cover its period at least a few times. Further, in
> practice again, some (or many) numbers in range will simply be "unhittable".

Not sure I understand what you mean by *period*.  Would that be *all* the
possible numbers between 0 and 1 that can conceivably be found in Pov_Ray? In
one test I did--looking for a 0 or 1 hit --I used a #while loop that iterated
10,000,000 times. No "hits"--though, admittedly, that's not 2^32 tries. I
thought of actually going "to the limit," but demurred because of the quite
lengthy parse time involved. Is it possible that I just
haven't tried hard enough? So by the same reasoning: If I chose some value
between 0 and 1 at random--say, .0005674836--and actually TRIED to hit that
with rand(), would the possibility of success be the same as trying to hit 0 or
1--i.e., practically nil? I'm beginning to see some light here--that "0" and "1"
constitute just two of a huge range of possible hits...and I can't expect to
pick JUST those two exact values out of such an ocean of numbers--without
searching the entire ocean, so to speak (and multiple times!) BUT, I still
harbor the sneaking thought that 0 and 1 may *in fact* be out-of-range. Hard to
prove or disprove, I suppose. As a practical matter, they just don't ever
seem to pop up. But I suppose you could say the same thing about .0005674836!

Thanks for your comment; it has made me think about this situation in depth.

As to some values being unhittable--can't say I understand why, unless it has
something to do with underlying computational processes that I don't understand
(and I don't understand plenty, when it comes to such things! :-)

Ken W.

Post a reply to this message

"Mike the Elder" <nomail@nomail> wrote:
> Very clever indeed. Thanks for sharing this. "Irfanview", a freeware program,
> has radial and zoom blur functions that might lead to some interesting masks.
>

I appreciate the nice comments. (I've actually been sitting on this technique
for about six months, and finally got off my arse to post it.) Thanks also for
the Irfanview link; I hadn't heard of that app before.  Will try it out.

KW

Post a reply to this message

Thank you indeed, Kenneth!!!
What a perfect and simple idea! And so many applications come to mind! Can't 
wait to experiment with this.

Thomas

Post a reply to this message

Just a very rapid example, taking a random photograph I had, without 
particular blurring I must say, but still a nice result.

Thanks again, Kenneth!!

Thomas

Post a reply to this message

Attachments:
Download 'Kenneth airbrush.jpg' (103 KB)

Preview of image 'Kenneth airbrush.jpg'

...and using  pow(rand(S2), .333)....

Thomas

Post a reply to this message

Attachments:
Download 'Kenneth airbrush2.jpg' (67 KB)

Preview of image 'Kenneth airbrush2.jpg'

...and increasing the number of objects (x10 Kenneth's example).

And now I stop!  :-)

Thomas

Post a reply to this message

Attachments:
Download 'Kenneth airbrush3.jpg' (103 KB)

Preview of image 'Kenneth airbrush3.jpg'

"Kenneth" <kdw### [at] earthlinknet> wrote in message
news:web.48293172dace545278dcad930@news.povray.org...
> "somebody" <x### [at] ycom> wrote:
> > "Kenneth" <kdw### [at] earthlinknet> wrote

> > > BTW, in working with this technique (and running some other
experiments),
> > I've found that rand() doesn't actually HIT zero or one.

> > A pseudo random generator should in practice not hit *any* given number,
not
> > just 0 and 1, unless you cover its period at least a few times. Further,
in
> > practice again, some (or many) numbers in range will simply be
"unhittable".

> Not sure I understand what you mean by *period*.  Would that be *all* the
> possible numbers between 0 and 1 that can conceivably be found in Pov_Ray?

Correction, I was mixing two things. With a pseudo-rng, you need to only
cover the period once (after that, it starts repeating). With a
physical/hardware rng, you can of course never be sure, but in practice, if
you cover the domain of possible values a few times over, you can develop
enough confidence. I don't know what POV uses for rng.

> As to some values being unhittable--can't say I understand why, unless it
has
> something to do with underlying computational processes that I don't
understand
> (and I don't understand plenty, when it comes to such things! :-)

That happens if the period of a rng is smaller than the domain of generated
numbers (ie a rng with period 2^30 returning 32 bits won't hit 75% of the
numbers in the domain).

Post a reply to this message

Cool, but you don't need the height_field, just use eval_pigment.  That way, 
you can use any pigment as a mask

something like this:

--- begin code ---
#include "functions.inc"

#local TraceObject=plane {y,0}

#local Mask=pigment {granite poly_wave 2}
#local Number=100000;
#local Seed=seed(123);
union {
    #while (Number>0)
        //trace from a random value ranging from <-2,..,-2> to <2,..,2>
        #local 
TracePosition=<rand(Seed)-rand(Seed),500,rand(Seed)-rand(Seed)>*<2,1,2>;
        #local Position=trace(TraceObject,TracePosition,-y);

        //Two ways: use the mask as a 2D mask, using only the X and Y values
        #local 
Probability=eval_pigment(Mask,<Position.x,Position.z,0>).gray;
        //or... use it as a 3D mask
        #local Probability=eval_pigment(Mask,Position).gray;

        #if (rand(Seed)<=Probability)
            sphere {
                Position,.01
            }
        #end
        #local Number=Number-1;
    #end
    pigment {red 1}
}
object {TraceObject pigment {rgb 1}}

//camera and light_source
camera {
    location <-3,5,-10>
    look_at 0
}
light_source {
    <500,500,-500>
    rgb 1
}
--- end code ---

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

You had the same idea as me :-)

I changed Kenneth's code to use eval_pigment instead of a height_field, I 
noticed that parsing was much longer, and also that POV was faster 'out of 
memory' with a large number of objects. I don't know if this is a 
significant difference due to the different methods, but there it is.

Thomas

Post a reply to this message