|
 |
Kenneth napsal(a):
> For the fun of it, I re-coded my original method to trace the height_field in a
> step-by-step linear fashion, rather than randomly. (The statistical process
> still uses rand, though.) And for added fun, I let the found y-values of the HF
> determine (somewhat) the scale of the small spheres; the result looks a bit like
> halftone printing. (In that process, the printed dots vary in size.) The photo
> is of Sophia Loren in the film EL CID--a beautiful film to study
> for its lighting and image composition, BTW.
>
> The only value that needs changing here is foobar; it determines the "scanning
> resolution" of the traces (and automatically scales the spheres.) It can be any
> value at all; it doesn't depend on the pixel resolution of the image_map. I.e.,
> the trace rays don't *need* to hit a HF triangle vertex / image_map pixel in
> order to return a valid height value; they can hit the triangles
> anywhere.
>
> One of the reasons I decided to try this linear tracing scheme was that it might
> have some relevance to the time-saving 'tiling' idea that's been mentioned (re:
> eliminating unnecessary traces from the large dark areas of the image_map/HF.)
> I'm working up an overall tiling scheme, and will be back with it ASAP.
>
> Meanwhile, here's the linear-tracing code. I'm not totally sure what values
> counter_x and counter_z should start with--1 or 0. Either one *works* but it
> should be a logically correct value. Sorry, my brain is tired...
>
It looks like a griddler
Post a reply to this message
|
|
|
|
"Kenneth" <kdw### [at] earthlink net> wrote:
>
> A more accurate way of getting the pigment pattern's colors into grayscale
> would be to substitute a PATTERN for the PIGMENT; it's already in grayscale.
> I.e., pattern{bozo...} And--as far as I can tell from section 3.5.11.16 of the
> docs--such patterns have 16-bit resolution.
>
Hmm. I was assuming that eval_pigment could evaluate a PATTERN in place of a
PIGMENT. That may be wrong.
I.e., if I did this...
#local Mask=pattern {granite poly_wave 2}
instead of
#local Mask=pigment {granite poly_wave 2}
would eval_pigment{Mask....) still work even though Mask is no longer a
3-component pigment now, but a scalar quantity?
Ken W.
Post a reply to this message
|
|
|
|
"Blue Herring" <bhe### [at] tinfoilcatcom> schreef in bericht
news:web.482d974628652b6ace5ce3790@news.povray.org...
> Secondly, I haven't yet tried it, but I believe both parse time and
> memory
> usage could be much improved by declaring a function from the pigment once
> and
> then calling the function to get the appropriate value. This would avoid
> declaring the pigment function (which is what eval_pigment does) over and
> over
> again for the same pigment, and replace a repeated macro call with a
> function
> call, which should be much faster.
>
Ah! Clever! I shall try this. Thanks!
Thomas
Post a reply to this message
|
|
