"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

Hmmm, interesting little technique there.  I'm trying to think of ways to
exploit it for filmmaking purposes.  Need to do some research...

--
Dan
GoofyGraffix.com

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> Cool, but you don't need the height_field, just use eval_pigment.  That way,
> you can use any pigment as a mask..

Aha, I knew *someone* out there would find a way to improve it (in this case,
both you and Thomas.) I'll have to try this--I've never used eval before.
Thanks for the code example.

Ken W.

Post a reply to this message

"Thomas de Groot" <t.d### [at] internlDOTnet> wrote:
> 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

Wow, I like that--especially when the number of objects is increased. I actually
hadn't thought of using a *photograph* as the mask; yet it's such a natural
extension. The idea floods my mind with possible uses!  Thanks.

Ken W.

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> Cool, but you don't need the height_field, just use eval_pigment.  That way,
> you can use any pigment as a mask...

....and using it as a 3-D mask, which you outline in the code example, sounds
REALLY intriguing! I'm guessing that such a technique will work because the
pigment pattern is 3-D rather than 2-D (as in my original image_map example)?
Wow. If so, then my limited little masking trick just took on a whole new
dimension--literally!! Thanks for opening my eyes.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.4829b56bdace545278dcad930@news.povray.org...
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> Cool, but you don't need the height_field, just use eval_pigment.  That 
>> way,
>> you can use any pigment as a mask..
>
> Aha, I knew *someone* out there would find a way to improve it (in this 
> case,
> both you and Thomas.) I'll have to try this--I've never used eval before.
> Thanks for the code example.
>

In Zeger's example, I would replace .gray by .red (or .green or .blue). 
Parsing will be much faster, for the same result.

Thomas

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.4829bb09dace545278dcad930@news.povray.org...
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> Cool, but you don't need the height_field, just use eval_pigment.  That 
>> way,
>> you can use any pigment as a mask...
>
> ....and using it as a 3-D mask, which you outline in the code example, 
> sounds
> REALLY intriguing! I'm guessing that such a technique will work because 
> the
> pigment pattern is 3-D rather than 2-D (as in my original image_map 
> example)?
> Wow. If so, then my limited little masking trick just took on a whole new
> dimension--literally!! Thanks for opening my eyes.
>

He he!! Yes, I suppose that might be an interesting development. I keep a 
bit worried though about the 'out of memory' that I got with the 
eval_pigment variation. Maybe it was just chance (I shall have to 
investigate further). The slower parsing can be compensated in the end by 
writing the found positions to a file and read them back later for 
rendering.
I must say, Kenneth, that your little elegant height_field technique appeals 
to me a lot and I shall use it a lot where it can easily substitute 
eval_pigment.

Thomas

Post a reply to this message

> This is traced in the usual way, but the y-values that are found are not 
> used
> to place objects anywhere; rather, they are used to statistically(?) 
> determine
> whether an object is made or not made at any particular x/z location...a 
> sort
> of 'chance' determination, with a HF height of 0 being a zero% chance that 
> an
> object is made, up to 1 being a 100% chance.

I use this method currently too, in a game to place trees and things around 
the level.  *But*, when you have large areas of low-density, and you want to 
plant thousands of items, it starts to get slow (because there are so many 
"misses").  I am wondering if there is a faster way to do it?

Post a reply to this message