> 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!
Test it. Make a test scene where you have a sphere clipped by a plane 
and a background plane. Fill that with some media.

sphere{0,2 clipped_by{plane{x,0.1}}}
plane{-z, -10}
media{Some_Media}
camera{location -5*z}

> 
> 
> 

A plane is almost as simple as a sphere, but is unbounded : A normal 
vector and an offset float, totalling 4 floats just the same as a 
sphere. That effectively take only a small amount of memory.
If you use it to clip an other object, then, you are left with the part 
of that object that is inside the plane, or whatever primitive you used.
The draw back is that having 1000, of infinite primitives will 
significantly increase the rendering time. You'll also need to manually 
bound those cut hight_field using bounded_by{box{...}}. It would 
probably be more efficient to use a box to cut the opposing walls than 
using planes. A box is defined by 6 floats if there is no texturing and 
no transform.
So, for the two opposing walls, you need two planes per faces, total 4 
planes or 16 floats, or a single box or 6 floats.

BUT, the very large tiled hight_field will take a large amount of 
memory, and part of it will get cut out and never be used in any way. 
That mean some amount of wasted memory. It will effectively take as much 
memory as the total of every tiles used to make it.
A middle ground solution would be to make some medium tiled hight_field.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> 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.

Well I know that's true for meshes, but I'm not sure about texture images. I
would hope that if I'm talking rubbish here, clipka would step up to correct me!
My suggestion was more about avoiding excessive brute-force declarations.

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

Each array element can be thought of as an lvalue in a #declare.

> 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?

Sorry, I should have been a bit less concise! I was suggesting putting the
filenames into an array of strings to cut down on bruteforce code, then using
that array to populate another array of pigment blocks (which can be automated).
Each pigment block definition reads the image file, then you can use those
pigments wherever you want. This is the same as laboriously declaring each
image-based pigment by name, but because you can loop over an array, or pick a
random index to choose one, it makes the whole thing easier to use.

I'll knock up some example code later if you like.

hope that helps!
Bill

Post a reply to this message

Am 01.03.2018 um 10:00 schrieb Bill Pragnell:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> 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.
> 
> Well I know that's true for meshes, but I'm not sure about texture images. I
> would hope that if I'm talking rubbish here, clipka would step up to correct me!
> My suggestion was more about avoiding excessive brute-force declarations.

First for some clarification: At present, /anything/ you declare and
then instantiate multiple times /will/ increase memory usage. This is
even true for meshes. However, certain entities can share /portions/ of
their data among instances. This typically happens for bulk data, such
as the actual vertex and triangle data of a mesh.

And yes, image-based pigments do indeed share the actual image data
among instances.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> And yes, image-based pigments do indeed share the actual image data
> among instances.

Excellent. I'd have been surprised if that wasn't the case, but I never actually
knew for certain!

So then, here's an example of what I was talking about for Kenneth:

#declare Filenames = array[3] {
  "FileName1.jpg",
  "FileName2.jpg",
  "FileName3.jpg"
}
#declare Pigments = array[3];
#for (I, 0, 2)
  #declare Pigments[I] = pigment {
    image_pattern {
      jpeg Filenames[I]
    }
  }
#end

#declare S = seed(0);

// Now do the below a bajillion times and hopefully
// you'll only be using memory for the 3 images
// plus the pigment instance:

#declare RandI = floor(rand(S)*2.99);
box { -1, 1 pigment { Pigments[RandI] } finish { ambient 0 } }

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> You'll also need to manually
> bound those cut hight_field using bounded_by{box{...}}. It would
> probably be more efficient to use a box to cut the opposing walls than
> using planes. A box is defined by 6 floats if there is no texturing and
> no transform.
> So, for the two opposing walls, you need two planes per faces, total 4
> planes or 16 floats, or a single box or 6 floats.
>

Yes, I totally forgot about the use of bounding boxes (and the probable need for
them with clipped_by planes). Thanks for the detailed analysis; that's another
great idea-- AND they can use the old trick of
      bounded_by{...}
      clipped_by {bounded_by}

> BUT, the very large tiled hight_field will take a large amount of
> memory, and part of it will get cut out and never be used in any way.
> That mean some amount of wasted memory. It will effectively take as much
> memory as the total of every tiles used to make it.

Hmm, currently I don't know if that's true-- I *assumed* that the small
'original' HF tile would be the only memory-intensive one, and that the much
larger 'template' building face would be just 'instantiated copies' of it, with
very little additional memory increase. If this assumption is correct, then I
don't mind wasting some of the large template for the many
randomly-sized copies of the building. But I guess I need to test it!

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> ...I *assumed* that the small
> 'original' HF tile would be the only memory-intensive one, and that the much
> larger 'template' building face would be just 'instantiated copies' of it, with
> very little additional memory increase.

.... based on the idea that the original HF is just a triangle mesh, like any
other mesh, and can be 'instantiated' the same way.

Post a reply to this message

Am 01.03.2018 um 15:42 schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>>
>> ...I *assumed* that the small
>> 'original' HF tile would be the only memory-intensive one, and that the much
>> larger 'template' building face would be just 'instantiated copies' of it, with
>> very little additional memory increase.
> 
> .... based on the idea that the original HF is just a triangle mesh, like any
> other mesh, and can be 'instantiated' the same way.

Height fields are quite different from triangle meshes, in that a height
field's "topology" is extremely regular (wich allows or various
optimizations).

Height field instances do share the bulk data though (including bulk
precomputed data).

Post a reply to this message

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

>
> So then, here's an example of what I was talking about for Kenneth:
[snip]

Ah, I see what you mean now. Thanks for those examples.

I clearly need to do some memory-requirement tests, of the many ideas that have
been proposed.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> 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?

Just tested that; happy to report that an object with clipping planes does NOT
affect atmospheric media in the scene. So clipping planes don't behave like real
'plane' objects.

But for clipping a media_filled *object*-- not recommended anyway-- the results
are odd but expected: The object naturally appears as just a shell now, with the
'appearance' of media on only its inner and outer surfaces-- kind of like a
pigment-- BUT, that depends on if there is another actual background *object*
present, for it to show up against. This particular effect has a familiar look,
actually: In maybe v3.6.0 days, *atmospheric* media had to have an actual object
behind it, otherwise the media appeared to be missing there. That has changed,
perhaps with v3.7.0. (The documentation about this requirement needs updating,
IMO.) Although, I see a different 'kind' of atmospheric media appearance between
v3.7.0 and v3.7.1 beta 9. The latter looks MUCH better.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

Sorry, I just noticed a dumb typo I made in the following discussion, namely...
jpeg "building windows 1 holdout.jpg"
vs.
jpeg "building windows 26 HO.jpg"

Consider them to be one and the same-- the reflection hold-out matte. (I was
cutting and pasting code from different parts of a scene, and didn't notice this
blunder. I hope it didn't TOTALLY confuse what I was trying to say!)

> ........
> 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*.

Post a reply to this message