POV-Ray : Newsgroups : povray.binaries.images : city buildings-- WIP 9_29_2020 : Re: city buildings-- WIP 9_29_2020 Server Time
10 May 2024 09:56:14 EDT (-0400)
  Re: city buildings-- WIP 9_29_2020  
From: Thomas de Groot
Date: 4 Oct 2020 02:20:46
Message: <5f7969be$1@news.povray.org>
Op 04/10/2020 om 07:38 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 01/10/2020 om 23:40 schreef Kenneth:
> 
>>> One trick that I learned long ago was to pre-#declare image_map pigments, when
>>> they are going to be used repeatedly in a scene. That saves a whopping
>>> amount of memory usage later.
>>>
>>
>> Yes sir. You probably learned this the hard way, like I did. ;-)
>>
> 
> Indeed! I probably stumbled onto the idea purely by mistake, ha.
> 
> I've also experimented with trying to use a #macro to do the same thing.
> Like...
> #macro _MY_IMG_MACRO() // to create it
> pigment{image_map{png "my_image.png" interpolate 2}}
> #end
> 
> then...
> #for(i,1,1000)
> box{0,1
> MY_IMG_MACRO() // the pigment-- but no pigment identifier needed here
> translate ...
> }
> #end
> 
> Alas, the macro does not 'pre-#declare' the image_map in a similar way, or save
> on memory usage. I remember, from several years ago, that Clipka added some
> 'caching' abilities to macro use, in one of the v3.8xx development releases; I
> guess an image_map was not part of that scheme... or that the macro just caches
> the text of the pigment specification, not the image itself? (I make no claim of
> understanding the behind-the-scenes workings of a macro!)
> 
> 
Hmmm... yes, that would not work as expected I guess. However, It seems 
there would be little gain in such a construct, would there? A simple 
declaration of the pigment image_map is enough. But I could probably 
imagine cases where a macro would be just the thing to use.

-- 
Thomas


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.