Am 25.04.2018 um 18:46 schrieb Kenneth:

>>> If that macro is in an include file, that file will get opened and read
>>> each time the macro is invoked.
>>
>> As of v3.8.0-alpha, this is no longer true: Macros up to a certain size
>> (currently hard-coded to, IIRC, 64 kiB) are now cached in memory.
> 
> Thanks for the clairification about macro caching. I know it's been mentioned
> before, but I wasn't clear about the details-- the exact memory limit. I
> assume(?) that the caching occurs for *any* entity placed in the macro... even a
> pigment{image_map...} for example (just so it's under the 64K limit).

Just to be clear: It's not the /result/ of the macro that is cached -
just the SDL code snippet.


> So POV-Ray has its own little virtual machine for such compiling tasks.
> Fascinating.
> 
> Using my image_map example again (because images are generally
> parse-time-intensive), does this VM/compile idiom still work when turning an
> image into a function? Not that it's a practical scheme in most cases, but just
> as a clarification of the idea. Like...
> 
> pigment {
>     image_map {
>       function 500,500 {
>         pigment {image_map{png "MY_IMAGE.png} }
>                        }
>               }
>         }

When you turn an image into a function (aka "image function"), the VM
actually isn't involved; rather, the image is used as a "data table" for
a hard-coded function, which just interpolates the image data and is
even faster.

At a first glance I would strongly discourage the above construct:
You're not just constructing an image function, but rather turing the
resulting function back into an image again (aka "function image"), so
what you really have is an "image function image". As there's nothing to
be "executed" about an image (it's just a (colour) data container, after
all), there's also nothing to be "compiled", and hence no performance to
be gained.

However, at second glance, the construct is still interesting, albeit
for another reason: Nobody stops you from specifying a resolution in the
function image that differs from the image function; so you can use it
to re-sample the image.

Since the function can be discarded right after the function image has
been constructed, and the underlying original image can be discarded
along with it, this may reduce the memory footprint of a scene if your
image has a very high resolution but you only need a very low resolution.

Post a reply to this message