In article <411f6ukkqp1uplrl14b1sn582vk372o0hb@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

> Yes, I know, but then speed optimization with boundary will not work.

Just use separate macros...the blur pattern functionality would be very 
useful, but having specialized macros optimized for specific patterns is 
still possible.


> > BTW, why use "(1/C)*(...)" instead of just "(...)/C"?
> Becouse C is index for loop and after loop it has value 0.

"(...)/Count" will still work. I don't think that max() call is 
necessary, but you could also just save the value of C before the loop 
in another variable.


> Afaik 1/C is optimized to one float at parse time so it not the problem for
> parser.

It just makes it less obvious that you are dividing the sum by the 
number of samples.

Hmm, something that would probably slow it down too much to be useful, 
as well as being more difficult to implement, but it would be 
interesting if it was modified to take samples in a sphere instead of a 
cube...

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message