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

Yes, the following piece of code, using eval_pigment, gets me a fatal parse 
error: out of memory, while the same code by Kenneth, does not. tested with 
version 3.7 beta 25.

union {
  #while (counter <= 1500000)
    #declare trace_position =
      <rand(S1), 0, rand(S1)>;
    #declare intersexion =
      eval_pigment(mask2,trace_position);

    #if(pow(rand(S2), .333) <= intersexion.red)
     cone { <0, 0, 0>, 0.001, <0, 0.001, 0>, 0.0 translate 
<trace_position.x,0,trace_position.z>}
    #end

    #declare counter = counter + 1;
  #end
  pigment{Black}
  translate <-0.5,0,-0.5>
}


Thomas

Post a reply to this message

Just to stimulate your imagination!  :-)
Something you can only see from the air, like the Nasca plateau.

Thomas

Post a reply to this message

Attachments:
Download 'Kenneth airbrush4.jpg' (174 KB)

Preview of image 'Kenneth airbrush4.jpg'

scott wrote:

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

I played with this a bit under on the assumption that the result
is random anyway and a trade-off between quality and speed might
be reasonable. I came up with some sort of tile-based object load
balancing, which basically places a grid over the mask, assigns
object counts to each tile based on relative probabilities, and
then places objects for each tile separately.

The main advantage is that the local tile probabilites can be
normalized, as the lower probabilities are already accounted
for in the lower object count assigned to the tile, reducing
the number of misses (of course, this changes the output due
to clipping of the highest probabilities). I tested this with
a crackle pattern and it saved about 50% of object tests.

The main problem is to estimate the average probabilities within
each tile. In particular, if a tile is estimated at probability 0,
no objects will be placed into it, even if it does contain a small
region of high probability. The best results could be obtained with
an interpolated zoomed down copy of the input mask, but below,
I just use some random samples. However, the sample count should
not be set too high, as reducing the tile size also helps to
fix problems but improves load balancing as well.

As a border case, the number of tiles could be made equal to
the number of pixels in an input image map. In this case, each
pixel will be sampled once, and all objects may be placed without
further tests. In order to be useful, however, the desired object
count would need to be higher than the pixel count ;)

The snippet below expects the existence of two macros
PROBABILITY(pos) and PLACE_OBJECT(pos), so it should be
easy to hook your own mask and output to it. It probably
works best for smooth masks.


#local R = seed(0);
#local NUM_OBJECTS = 10000;
#local METHOD = 2;


// Global debug counters
#declare placed_objects = 0;
#declare position_tests = 0;


// Method 1: Naive placement

#if (METHOD = 1)

#local i = 0;
#while (i < NUM_OBJECTS)
   #local pos = <rand(R), 0, rand(R)>;
   #if (rand(R) < PROBABILITY(pos))
     PLACE_OBJECT(pos)
     #declare placed_objects = placed_objects + 1;
     #local i = i + 1;
   #end
   #declare position_tests = position_tests + 1;
#end

#end // METHOD 1


// Method 2: Tile-based object load balancing

#if (METHOD = 2)

// Method parameter
#local TILING      =  40;
#local NUM_SAMPLES =   3; // Better way would be interpolated,
                           // zoomed down copy of input pigment!

// Derived values
#local TILE_NUM       = TILING * TILING;
#local TILE_SIZE      = 1/TILING;
#local TILE_SIZE_HALF = 0.5*TILE_SIZE;


// Step 1: Sample probabilities

#local TILE_X       = array[TILE_NUM]; // Just for convenience
#local TILE_Z       = array[TILE_NUM]; // Just for convenience
#local TILE_PROB    = array[TILE_NUM];
#local TILE_OBJECTS = array[TILE_NUM];
#local TILE_PROBS   = 0;
#local TILE_INDEX   = 0;

#local i = 0;
#while (i < TILING)
   #local j = 0;
   #while (j < TILING)
     #local pos = <TILE_SIZE_HALF+i*TILE_SIZE, 0, TILE_SIZE_HALF+j*TILE_SIZE>;
     #local TILE_X[TILE_INDEX]       = pos.x;
     #local TILE_Z[TILE_INDEX]       = pos.z;
     #local k = 0;
     #local SAMPLE_PROBS = 0;
     #while (k < NUM_SAMPLES)
       #local pos2 = <TILE_X[TILE_INDEX]-TILE_SIZE_HALF+TILE_SIZE*rand(R), 0,
                      TILE_Z[TILE_INDEX]-TILE_SIZE_HALF+TILE_SIZE*rand(R)>; 

       #local SAMPLE_PROBS = SAMPLE_PROBS + PROBABILITY(pos2);
       #declare position_tests = position_tests + 1; // global debug counter
       #local k = k + 1;
     #end
     #local TILE_PROB[TILE_INDEX] = SAMPLE_PROBS / NUM_SAMPLES;
     #local TILE_PROBS = TILE_PROBS + TILE_PROB[TILE_INDEX];
     #local TILE_INDEX = TILE_INDEX + 1;
     #local j = j + 1;
   #end
   #local i = i + 1;
#end


// Step 2: Balance object load based on relative tile probabilities

#local i = 0;
#while (i < TILE_NUM)
   #local TILE_OBJECTS[i] = (TILE_PROB[i]/TILE_PROBS) * NUM_OBJECTS;
   #local i = i + 1;
#end


// Step 3: Execute normalized probability passes for each tile

#local i = 0;
#while (i < TILE_NUM)
   #if (TILE_PROB[i] > 0)
     #local boost = 1/TILE_PROB[i];
     #local j = 0;
     #while (j < TILE_OBJECTS[i])
       #local pos = <TILE_X[i] - TILE_SIZE_HALF + TILE_SIZE * rand(R), 0,
                     TILE_Z[i] - TILE_SIZE_HALF + TILE_SIZE * rand(R)>; 

       #if (rand(R) < boost*PROBABILITY(pos))
         PLACE_OBJECT(pos)
         #declare placed_objects = placed_objects + 1;
         #local j = j + 1;
       #end
       #declare position_tests = position_tests + 1; // global debug counter
     #end
   #end
   #local i = i + 1;
#end

#end // METHOD 2

#debug concat("Pigment evaluations: ", str(position_tests,0,0),"\n")
#debug concat("Object placements: ", str(placed_objects,0,0),"\n")

Post a reply to this message