Op 01/10/2020 om 23:40 schreef Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>>
>> The scene so far parses 'reasonably' quickly: For 650 buildings, with AA but no
>> radiosity yet--  78 seconds total render time on my old Windows 7 machine (at
>> 1600 X 900). The 'peak memory used' is about 1.1MB.
>>
> 
> Duh. That should be 1.1 GB of memory, not MB. Sorry.
> 
> 1000 buildings uses about 1.4GB
> 
> 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.
> 
> Like,
> #declare MY_PIGMENT = pigment{image_map{png "my_image.png" interpolate 2}}
> #for(i,1,1000)
> box{0,1 pigment{MY_PIGMENT} translate ...}
> #end
> 
> instead of...
> #for(i,1,1000)
> box{0,1 pigment{image_map{png "my_image.png" interpolate 2}}
> translate ...}
> #end
> 

Yes sir. You probably learned this the hard way, like I did. ;-)

-- 
Thomas

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> > Thomas de Groot <tho### [at] degrootorg> wrote:
> > > I think there is a fairly simple way [for collision detection], close
> > > to what Bill suggested, by
> > > using (1) random placement on the roof and (2) if more objects are to be
> > > placed to test collisions using the inside(O,V) function...
> >
>
> I wrote a macro based on 'inside()' for the purpose (ie getting the smallest
> "axis-aligned" bounding box), maybe it'll be of use.
>
> <http://news.povray.org/web.5dc0bff634d8ef06feeb22ff0%40news.povray.org>
>

Thanks for that! I'll definitely take a look.

It always amazes me that folks here in the newsgroups have already figured out
ways of solving problems, and freely volunteer to help :-) These newsgroups are
a great resource.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> These newsgroups are a great resource.

hear, hear.  now, how to "beat the drum" to increase traffic to the site?


regards, jr.

Post a reply to this message

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!)

Post a reply to this message

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

Op 03/10/2020 om 11:24 schreef jr:
> hi,
> 
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> ...
>> These newsgroups are a great resource.
> 
> hear, hear.  now, how to "beat the drum" to increase traffic to the site?
> 
> 

That question has been repeatedly debated here once in a while. During 
the whole period of activity of the TC-RTC we struggled with low and 
decreasing input (which started already, iirc, at the end of the IRTC). 
At the time there were different reasons given or surmised (changing 
public; dwindling number of users with older - not necessarily age - 
generation gradually disappearing; shifting attention focus to different 
subjects; drifting of the users away from ray-tracing...).

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 04/10/2020 om 07:38 schreef Kenneth:
> >
> > Alas, the macro does not 'pre-#declare' the image_map in a similar way, or
> > save on memory usage.
> >
> 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...

Yes, that is true in most cases-- probably 99% of cases! But my scene makes use
of a repetitive (and randomly-configured) texture{image_pattern...) as a
'hold-out mask' for creating the many building windows' reflections; one texture
is used to mask another texture.  The best way-- the only way(?)-- that I could
come up with to make it work in my scene was to use a rather odd-looking macro
for substitution in the texture{image_pattern...}. Like this, one of 34 similar
examples of my macro at present...

// 1 of 34
#macro HO_7() // the window hold-out mask
jpeg "building windows 7 HO.jpg" interpolate 2 // not *quite* a complete
// pigment{image_map{...}} specification, but necessary this way. And with
// no memory savings :-(
#end

#declare TEX_MAP_FOOBAR = // a special preliminary texture
texture_map{
        // no *pattern* here as per docs, because this will be used as part of
// the texture{image_pattern{...}} below
        [.45 TEX_F_B] // the regular *visible* building image_map tile with
/ /its bricks, windows, etc.
        [.55 TEX_REFLECT] // the same image_map tile but with REFLECTION
// all over it
           }
then...
#declare MY_TEMP_TEX =
texture{
    image_pattern{
          #switch(true)
          ....
          #case(....) // 34 of these
          HO_7() } // inserting the macro, with an ending bracket here
          #break
          ....
          #else
          #end
     texture_map{TEX_MAP_FOOBAR} // the regular *visible* texture for each
// building, but now masked by the window hold-out image so that only the
// windows have reflection
        }  // end of MY_TEMP_TEX texture

This probably doesn't make much sense out-of-context-- and *using* it later in a
BOXED pattern is even more complex to describe. But the point is, POV-ray's
texture{image_pattern...}} construct requires a specific and rather odd syntax
for its hold-out-mask image-- which makes a random substitution of that image
difficult, with no way that I have found to pre-#declare the image so that it
isn't loaded into memory over and over again (when used in a #while loop). In
fact, macro substitution is the only way I've found to successfully do it at
all, regardless of the memory-use problem.

Post a reply to this message

hi,

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

it would have been helpful to see some (excerpted) real code, so I suspect I may
have the "wrong end of the stick", in which case ignore.  :-)  reading the above
and the follow up (0750h), I thought why aren't the basic image_map pigments in
an array?  (perhaps in a separate include file)  then the macro (and other code)
only need to deal with indices.  eg. (just typed, any errors mine):

#declare myImgMaps = array {
  pigment {image_map {jpeg "building windows 7 HO.jpg" interpolate 2}},
  ...
};

so you'd refer to 'myImgMaps[0]' etc.


regards, jr.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> ...But the point is, POV-ray's
> texture{image_pattern...}} construct requires a specific and rather odd syntax
> for its hold-out-mask image-- which makes a random substitution of that image
> difficult, with no way that I have found to pre-#declare the image so that it
> isn't loaded into memory over and over again (when used in a #while loop). In
> fact, macro substitution is the only way I've found to successfully do it at
> all, regardless of the memory-use problem.

Hmm... I just thought of what *might* be another way around this problem,
another complex way (ouch), but I haven't tried it yet. Some psuedo-code:

1) PRE-#declare the 34 hold-out-mask images *as* the rather odd macros, to
hopefully save memory use later when they are used repeatedly:
#declare H_O_IMAGE_1 =
#macro FOOBAR_1() // to create each macro
png "my_holdout_mask_1.png" interpolate 2
#end
.... 2,3,4, etc
Perhaps #declaring these macros will work as I imagine(?)

2) For the final texture{image_pattern{...}}, pre-make 34 *different* and
complete image_pattern{...} constructs(!)-- which include the pre-#declared
macros from 1):

#declare IMG_PATTERN_1 =
image_pattern{ //this *should* work as syntax, like  pigment{...} in a #declare
   H_O_IMAGE_1
   texture_map{TEX_MAP_FOOBAR} // this has been pre-#declared too
             }

3) Substitute those 34 image_patterns randomly into the final texture... which
should save a lot of memory use:
texture{
     image_pattern{ // proper syntax?
         #switch(true)
         #case(...)
         IMG_PATTERN_1
         #break
         ... etc.
         #else
         #end
       }

I should give it a try, at least to see if all of the syntax works properly.

Post a reply to this message

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

>
> 1) PRE-#declare the 34 hold-out-mask images *as* the rather odd macros...
> #declare H_O_IMAGE_1 =
> #macro FOOBAR_1() // to create each macro
> png "my_holdout_mask_1.png" interpolate 2
> #end
> .... 2,3,4, etc
> Perhaps #declaring these macros will work as I imagine(?)
>
> 2) For the final texture{image_pattern{...}} ...
>
> #declare IMG_PATTERN_1 =
> image_pattern{ //this *should* work as syntax...
>    H_O_IMAGE_1
>    texture_map{TEX_MAP_FOOBAR}
>              }
>

Oops! That H_O_IMAGE_1 insert will certainly NOT work there as-is; it's just
inserting the *creation* of the macro, not a *call* of the macro. But the
general idea might work, with some more changes. Time to experiment! ;-)

Post a reply to this message