> "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!
> 
> 
> 
> 
> 
This may help:
Start with a reflective box for the buildings.
Place your tiles so that the windows parts lies just under the 
reflective box.
The box will hide the "bottom" of the hight_field, and the raised parts 
of the hight_field will hide the mirror outside of the windows.
Place a roof box on the top that will hide the mirror box.

The inside, mirror, box should have an ior and use fresnel reflection. 
You also can give it some normals perturbation.

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> [snip]
> > 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!
>
> Declare a texture block array. Put the filename strings into another array using
> an initialiser list, then fill the texture block array by iterating over the
> filename array and using Parse_String() (in Strings.inc) to substitute the
> filenames in the image pattern statement. Parse_String() is nasty because it
> writes an include file then includes it on the spot, but as long as you're not
> doing it thousands of times it should be fine.


Yeh I just re-read that, forget Parse_String(), duh, it looks like you just need
to substitute your name string (from the array) to pre-declare all your matte
textures. You could even generate the filename strings instead of using a list
if they're just a numbered sequence.

Or try what Alain suggested - if I understood, it does away with the need for
the matte textures entirely.

Bill

Post a reply to this message

Kenneth wrote on 26/02/2018 22:05:
> I'm continuing to work on my 'city buildings' scene from a couple of months ago.
> I want to turn all the different buildings into height_fields-- not the usual
> 'from the ground up' HF's, but as the building faces, to add some dimensionality
> to them. They probably aren't going to be seen in close-up, but I think they
> will look more realistic than just flat-surface box shapes, if only for the
> extra shadows they provide.
> 
> These are some that I've already made-- they are tiled HFs that I can chop up or
> assemble into bigger buildings.  These renders are just basic tests to make sure
> that my code is aligning the faces correctly, and to check that the features and
> reflections are where they are supposed to be. The thin red line vertical line
> at the corners shows that the faces align.  I haven't yet 'scaled' my HF code to
> make sure that all the floor-levels of each building are the same height, or
> made any '1st floor' artistic modifications (for lobbies, possible store-fronts,
> etc... which I haven't figured out yet!)
> 
> The shape of the image_maps shows the actual 'tiles' I made, with their various
> window repetitions. But my code can chop them up into individual window 'units'
> if I want. Some image_maps have more windows, some less.
> 
> It's all very tedious Photoshop work, with back-and-forth testing.
> The interesting thing about the HFs is, I chose 50% gray as the 'flat face' of
> the building, rather then black. This way, I can make indents AND protrusions.
> The air conditioning units are one such protrusion; and the last image has been
> the most detailed yet.
> 
> I haven't yet integrated this HF idea into my main scene code;  some re-working
> will be needed there.
> 
> The actual building appearance is from internet images I downloaded, then made
> into tiles for repetition (same as in my original scene.) Some of those
> originals were quite small in pixel-size and had to be blown up to work with (to
> create a higher-rez HF).
> 

I'm curious to see the final work, the results are very nice.
Paolo

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> >
> This may help:
> Start with a reflective box for the buildings.

That is a brilliant and simple solution to my problem, for this height_field
version of the scene; as Bill says, it eliminates the need to use an
image_pattern/holdout matte altogether, with LOTS of image_map memory saved.
THANKS. I probably wouldn't have thought of it.

Strangely, it gave me another different (or maybe additional!) kind of idea: For
each of the 50 types of building faces, make ONE very large tiled height_field
slightly larger than any conceivable building I might make (made from the single
much-smaller original HF tile, that one being pre-#declared as usual.)
PRE-#declare this larger one too, *with* all of the images/reflections already
on it (or no reflections at all, like your idea.) That should require only a
relatively smallamount of memory, I think. Then use clipping planes in the later
#while loop to simply slice away parts of the 'iterated' HF, to get the building
dimensions I want for each different-height/different width building face. And
then add your reflective box underneath.

Of course, I'll end up using thousands and thousands of clipping planes for the
entire 'city'. I don't really know how that by itself might affect the
scene's memory use. Those planes are just simple(?) mathematical entities, so
maybe not much at all.

I have one small but important question about clipped_by planes: Regarding later
MEDIA use (if I decide to add it to the scene), do those planes have an
inside/outside nature like a regular 'plane' object? In other words, do they
affect the appearance/non appearance of media? I've never had to think about
this before!

Post a reply to this message

Paolo Gibellini <p.g### [at] gmailcom> wrote:

>
> I'm curious to see the final work, the results are very nice.
> Paolo

Thanks. It may take awhile, though, with the proposed changes ;-)

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
>...it looks like you just need
> to substitute your name string (from the array) to pre-declare all your matte
> textures. You could even generate the filename strings instead of using a list
> if they're just a numbered sequence.
>

Years ago, I actually did use the idea in the latter part of your comment, for a
very elaborate scene-- but I lost the scene, so I'll have to 'reinvent the
wheel' to understand what I did! (I haven't used that construct since then.)

About the arrays: I'm not clear about exactly what should go into them, or what
should be plugged into the image_pattern (although it sounds interesting, and
I'd like to know):

"building windows 1 holdout.jpg" ?
jpeg "building windows 1 holdout.jpg" ?

or some other thing?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> About the arrays: I'm not clear about exactly what should go into them, or what
> should be plugged into the image_pattern (although it sounds interesting, and
> I'd like to know):
>
> "building windows 1 holdout.jpg" ?
> jpeg "building windows 1 holdout.jpg" ?
>
> or some other thing?

Well it sounds like Alain's suggestion is the way to go, but just for interest's
sake - you can put anything into an array, I was thinking of just the filename
strings (i.e. without the 'jpeg' specifier).  Then you can do

image_pattern { jpeg FileNameArray[i] }

(or at least I assume this is correct - I haven't actually tried it!)
The other array would be for the texture/pigment blocks, one for each filename,
unless I've misunderstood what you were doing.

I use arrays a lot in SDL for predeclaring mesh-based stuff, then picking
randomly to instance them. Good for building blocks, rocks, textures, whatever.

Bill

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> I was thinking of just the filename
> strings (i.e. without the 'jpeg' specifier).  Then you can do
>
> image_pattern { jpeg FileNameArray[i] }
>
> (or at least I assume this is correct - I haven't actually tried it!)

That looks like it would work OK code-wise... very similar/identical to

#macro HO_1()
"building windows 1C.jpg"
#end

then
image_pattern{jpeg HO_1}

or...
#macro HO_1()
jpeg "building windows 1C.jpg"
#end

then
image_pattern{HO_1}

Both of those work, too.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> That looks like it would work OK code-wise... very similar/identical to
>
> #macro HO_1()
> "building windows 1C.jpg"
> #end
>
> then
> image_pattern{jpeg HO_1}
>
> or...
> #macro HO_1()
> jpeg "building windows 1C.jpg"
> #end
>
> then
> image_pattern{HO_1}
>
> Both of those work, too.

Yep, except that predeclaring the texture block into an array element avoids
reading the image file every time it's used, which was what you wanted to avoid.

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:

> >
> > Both of those work, too.
>
> Yep, except that predeclaring the texture block into an array element avoids
> reading the image file every time it's used, which was what you wanted to avoid.

Oh! I'm on the verge of understanding something important here, that I didn't
know :-)  (and which the docs DO mention, but I didn't read them as clearly as I
should have until now; AND you mentioned something earlier-- your rocks and
pebbles example-- but I didn't pick up on it.)

Let's say I have 50 different pigments:

pigment{image_map{jpeg "building windows *number*.jpg}}

So sticking them into an array actually #declares them-- once into memory-- then
I can call those pigments as many times as I want without increasing memory
usage. Just like pre-#declaring all of them individually.

Sorry to say, I thought arrays were just 'containers'  :-O  I've never put any
memory-hogging things into one.

NOW I see what you're getting at. Thanks! That's a rather big clarification for
me.

But in the case of my image_pattern-- which uses just
       jpeg "building windows *number*.jpg"

....I'm still not *totally* convinced that the image itself has actually been
#declared by the array...mainly because there's no pigment or image_map
'wrapper' around it. It looks like an 'unfinished entity.' Your thoughts?

Post a reply to this message