"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> These look really nice, good strategy. However, does this not get memory-heavy
> when you have a large number of buildings?
>

Actually, I don't yet know. My original scene-- without the height_fields-- does
suffer from a constantly climbing memory increase, the more buildings I add. I'm
still trying to determine why that is. But my idea here is to pre-#declare the
HFs (at their tile sizes, or as multiples of that)-- to consume memory only
once--then instantiate them into the scene for many building repetitions via
#while loop (and maybe using simple clipped-by planes to then slice-and-dice
some of the windows off to get *whatever* random building-face-sizes I want.)
Although, I haven't yet tried this scheme 'at scale'.

BTW, I eventually want to have as many as 50 different window styles-- thus 50
trios of images to work with.

The idea common to both my scenes is to pre-#declare all the
pigment{image_maps...} too,  before using them in various places in the
#while-loop code-- which does (or should!) save memory as well.

But there is a certain block of code *within* the #while-loop-- an image_pattern
block, common to both scenes-- that may be the problem when finally applying the
window *reflections* (via the hold-out mattes) to the buildings.
Here's a simplified demonstration, using only one style of HF tile:

--- *before* the #while-loop repetitions, to save memory---
#declare PIG_1A = pigment{image_map{...}} // the photo tile of the building face
#declare PIG_1B = pigment{image_map{...}} // the HF-artwork tile
#declare PIG_1C = pigment{image_map{...}} // the hi-contrast hold-out matte
// tile for the window reflections (which actually can't be used-- see below)
#declare HF_1 = height_field{PIG_1B... scale <...>};  // the original HF

-- *within* the #while loop, to make lots of these particular buildings---
#declare FINAL_BUILDING_FACE =
union{... another while loop to make random height-and-width repetitions
// of the original HF tile)...}
........
object{FINAL_BUILDING_FACE
texture{
    image_pattern{
    jpeg "building windows 1 holdout.jpg" //  the *actual* high-contrast
    // hold-out  matte for the window reflections, not PIG_1C. And no 'once'
    // keyword, BTW.
                 }
     scale <432,724,1>/724 // pixel dimensions of hold-out matte (actually
     // of all 3 images)
     texture_map{ // two identical pigments, but one having REFLECTION.
               [0.45 pigment{PIG_1A} finish{...}]
               [0.55 pigment{PIG_1A}finish{...reflection {REFLECT_AMT}}
                }
       }
     }

As far as I've been able to work out, there is no way to substitute PIG_1C or
something else for...
                   jpeg "building windows 26 HO.jpg"

......in order to save on *memory*.

By itself, the latter isn't an 'Rvalue' that can be pre-#declared. (Neither is
the small image_pattern block itself.) Which means that the hold-out image is
constantly reloaded into memory, maybe hundreds of times. And this is for only
ONE building style.

I've come up with only two tricks that actually work, if only code-wise: a
#macro substitution of "building windows 26 HO.jpg", but which basically just
inserts a text string, with no instantiation of the actual image. And a #macro
for
        jpeg "building windows 26 HO.jpg"
but I don't really know if that 'instantiates' the image (i.e., 'caching' of the
macro contents.) I don't think so.

This could be a big part of why the memory footprint of the scene increases, and
I don't yet know how to work around it-- that is, without a 'brute-force' method
of pre-#declaring 50 such constructs as individual texture blocks!

Post a reply to this message