"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> If you're going to use the image map to render something, then AFAIK, it needs
> to be in memory, so the render engine can refer to the pixel values in order
> to calculate the rendered image result.  So I don't think there's any way
> around decreasing the memory except for using smaller images.

Yes, all my images are small in file size. Some are tiny! But I've come to
realize that it's the repetitive use of the 'hold-out mask' images that cause my
scene's parse time and memory use to skyrocket; those image are the ones that I
haven't (yet) been able to pre-#declare, due to the image_pattern's syntax
problem. But I've's pigment_pattern workaround will solve that.

I did a really simple memory-use experiment this week, with 10,000 image_mapped
boxes in a #while loop-- nothing fancy-- to see how BOTH parse time and memory
were affected. Using a single image_map, and *without* pre-#declaring the image,
the parsing took a LOT of time (with constantly increasing memory use as the
image had to be 're-processed' for each iteration.) By pre#declaring the image,
the entire parse/render occured in mere seconds, with a much-reduced memory
load.

> Even using something
> like jpg instead of png might not work, since the jpg has to be decompressed.
> And if that's done on the fly, and not all at once, then you're taking a hit
> on render time.

Yep, I agree. Sad to say, when I started working on this scene, I used jpg's,
and have continued that way ever since. The reason being, that my OLD version of
Photoshop has wonky problems with correct png gamma when saving an edited image.
So no png's. But otherwise I LOVE my old version of PS; it's just easier to use
(for me) than GIMP.
>
> The macro is stored in memory - the referenced contents of the macro are
> not - until the macro is invoked.
> Since it's just ASCII text, even a small book wouldn't take up a prohibitive
> amount of memory in comparison to the image data.

Ah, thanks for the clarification.
>
> Buy more RAM -

Ha! But that would defeat my purpose of trying to get me scene to run in, uh,
256K  :-P

> I ignored the people who said I couldn't put 16 GB of RAM in my
> laptop after researching the issue. Been running fine for years.

THAT'S interesting. Yeah, AFAIK, my Win 7 box has an 8MB limit(?), so I never
thought of trying to increase it. So, my computer wouldn't actually explode,
right??

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
>

> second h/d and place all '/tmp/' and working directories on it (faster i/f than
> USB).

and Bald Eagle wrote:
> You can also do that thing where you use a (cheap) USB drive to boost your
> memory - no idea how fast/slow that is, but it will save on the HDD thrashing.
>

At my 'advanced' age, these 21-century technological changes and improvements
are a bit slow to digest, ha. I'm not sure as to how all of this works. I do
have a 500GB Samsung USB external memory (a solid-state 'thumb drive'); can
POV-ray and all my files be loaded onto it and actually RUN from there? I would
imagine that a bunch of library-paths would need changing(?), at the very least.
And/or changes to the Windows registry(?) It's all a mystery to me, I admit.

Btw, I was told by a local computer-repair shop that my Win 7's HD could be
retro-fitted with a SSD, while keeping all of my files, the OS, etc intact. Hmm,
I wonder if that's true.

Post a reply to this message

hi,

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

> > second h/d and place all '/tmp/' and working directories on it (faster i/f than
> > USB).
>
> and Bald Eagle wrote:
> > You can also do that thing where you use a (cheap) USB drive to boost your
> > memory - no idea how fast/slow that is, but it will save on the HDD thrashing.
> >
>
> At my 'advanced' age, these 21-century technological changes and improvements
> are a bit slow to digest, ha. ...

get with it, granddad!  :-) :-)

> Btw, I was told by a local computer-repair shop that my Win 7's HD could be
> retro-fitted with a SSD, while keeping all of my files, the OS, etc intact. Hmm,
> I wonder if that's true.

go for it.  not only is the read/write performance so much better, you'll also
save money.  (here I moved two "always on" machines to SSD, and saw a small drop
in daily electricity consumption (amounting to ~4 pence per day); given the

than their cost over that time, ie 1825 days)


regards, jr.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Using a single image_map, and *without* pre-#declaring the image,
> the parsing took a LOT of time (with constantly increasing memory use as the
> image had to be 're-processed' for each iteration.) By pre#declaring the image,
> the entire parse/render occured in mere seconds, with a much-reduced memory
> load.

Right, because the POV-Ray parser can't know that it's already red that image
file in, and so it re-reads it from disk, reloads it into a new memory slot,
etc...


> Yep, I agree. Sad to say, when I started working on this scene, I used jpg's,
> and have continued that way ever since. The reason being, that my OLD version of
> Photoshop has wonky problems with correct png gamma when saving an edited image.
> So no png's. But otherwise I LOVE my old version of PS; it's just easier to use
> (for me) than GIMP.

I have not found GIMP to be user-friendly.
In windoze I used wingif, winjpg, Irfanview, and paint.net


> > Buy more RAM -
>
> Ha! But that would defeat my purpose of trying to get me scene to run in, uh,
> 256K  :-P

I look forward to the Inigo Quilez Demoscene version in 8k.   :P

> > I ignored the people who said I couldn't put 16 GB of RAM in my
> > laptop after researching the issue. Been running fine for years.
>
> THAT'S interesting. Yeah, AFAIK, my Win 7 box has an 8MB limit(?), so I never
> thought of trying to increase it. So, my computer wouldn't actually explode,
> right??

It will just not be able to access the memory properly.
It's all very architecture dependent.  YMMV
Flip it over and have someone pop in different (but proper _type_) memory and
reboot it.  If it works (system stats report all the GB you installed are
recognized, then I'd buy it.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I have not found GIMP to be user-friendly.
> In windoze I used wingif, winjpg, Irfanview, and paint.net

Yes, Irfanview is handy. and fast. The others I'll have investigate.
>
>
> > > Buy more RAM -
> >
> > Ha! But that would defeat my purpose of trying to get me scene to run in, uh,
> > 256K  :-P
>
> I look forward to the Inigo Quilez Demoscene version in 8k.   :P
>
I had to look that up :-O  And Shadertoy. WOW, some *stunning* procedural CG.

Meanwhile, just for a bit o' fun, I ran my scene code again as-is, but with 5000
buildings, the most ever-- just to observe the parse/render/computer
performance. On my lowly Windows 7 box: disk-swap hell!!

Post a reply to this message

Attachments:
Download 'buildings_5000_10_5_20.jpg' (774 KB)

Preview of image 'buildings_5000_10_5_20.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > I have not found GIMP to be user-friendly.
> > In windoze I used wingif, winjpg, Irfanview, and paint.net
>
> Yes, Irfanview is handy. and fast. The others I'll have investigate.

wingif and winjpg are OLD, but because of that, they are tiny programs and FAST.
If you can't find them, I will look and see if I have them archived anywhere.

paint.net is mammoth, and you have to install all of that .net framework stuff,
but I found it very useful - probably what GIMP should be in terms of usability
paired with capability.


> I had to look that up :-O  And Shadertoy. WOW, some *stunning* procedural CG.

I'd say that IQ has such a good foundation in what he does because of the
limitations of what he had to work with.   ALL the fat had to be trimmed and
everything had to be re-used to squeeze as much out of the code as possible.
I learn a LOT from studying the Shadertoy stuff because it's all written from
scratch.  Camera, light source, shadows, geometry, patterns, shading...

> Meanwhile, just for a bit o' fun, I ran my scene code again as-is, but with 5000
> buildings, the most ever-- just to observe the parse/render/computer
> performance. On my lowly Windows 7 box: disk-swap hell!!

Find a used / surplus computer reseller - you can likely get something better
than what you have for ~$100  I haven't bought a NEW computer since .... 2008.
The way people go through technology these days to get the newest flashing crap
- you can pick up their discards for pennies on the dollar.  Yard sales, pawn
shops, Goodwill, classifieds, Ebay, Craigslist, .... I could probably find a
fully functioning laptop at the dump/transfer station up here if I went there
often enough...

It's been a while since I've seen the development of this project, but depending
on the resolution of the images, maybe you could replace some of them with
procedurally generated functions - esp if you're doing 5000 buildings - can you
really see the detail?

ATM, I've got 48,000 tiles making up a whole planet - there's no way I'm parsing
and rendering all of them if I don't have to.   That's the next phase, once I
get done with all of the Bezier editing.

Good work - I'm glad you're back, working on your projects, and having fun.

-BW

Post a reply to this message

> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> I have not found GIMP to be user-friendly.
>> In windoze I used wingif, winjpg, Irfanview, and paint.net
> 
> Yes, Irfanview is handy. and fast. The others I'll have investigate.
>>
>>
>>>> Buy more RAM -
>>>
>>> Ha! But that would defeat my purpose of trying to get me scene to run in, uh,
>>> 256K  :-P
>>
>> I look forward to the Inigo Quilez Demoscene version in 8k.   :P
>>
> I had to look that up :-O  And Shadertoy. WOW, some *stunning* procedural CG.
> 
> Meanwhile, just for a bit o' fun, I ran my scene code again as-is, but with 5000
> buildings, the most ever-- just to observe the parse/render/computer
> performance. On my lowly Windows 7 box: disk-swap hell!!
> 

Time to add some more RAM

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
>
> Time to add some more RAM

Or else to render less-complex scenes! :-P

I do like my old Windows 7 machine, but it has it's limitations, as I'm seeing
now... unless I try increasing the RAM 'over its limit' as Bald Eagle suggested.

Meanwhile, I just came up with a simple trick to make the *many* semi-repetitive
buildings look a bit different from each other: by randomly varying their
finish{diffuse...} values. I don't know why that idea didn't occur to me before.

It wasn't easy to implement, because of the way the building textures are
constructed-- but it turned out to be a simple code change in the end.

The effect may look subtle in this example image-- the buildings all use the
same window image_map and 'concrete' color-- but it looks quite nice when it's
'multiplied' by all of the various buildings and their image_maps.

BTW, I have added 3 more 'window images' to me collection-- now at 37!

Post a reply to this message

Attachments:
Download 'buildings_comp_10_6_20.jpg' (757 KB)

Preview of image 'buildings_comp_10_6_20.jpg'

Op 07/10/2020 om 05:52 schreef Kenneth:
> Meanwhile, I just came up with a simple trick to make the *many* semi-repetitive
> buildings look a bit different from each other: by randomly varying their
> finish{diffuse...} values. I don't know why that idea didn't occur to me before.
> 

Very effective indeed.

-- 
Thomas

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Meanwhile, just for a bit o' fun, I ran my scene code again as-is, but with 5000
> buildings, the most ever-- just to observe the parse/render/computer
> performance. On my lowly Windows 7 box: disk-swap hell!!

SO.. with two basic changes to my code...
1) using arrays for pre-#declaring both the window/building image_maps AND their
window hold-out image_map mattes (for the reflections)
2) switching from an image_pattern to a MUCH-better pigment_pattern syntax per
Ive's suggestion, to now make efficient use of both sets of those image_maps

....the scene parses *much* faster, and uses a fraction of the RAM that it did
previously.

With 30,000 buildings(!) plus probably 200,000+ roof-top greebles, RAM use is
down to 3.7GB. I could probably run 100,000 buildings now before disk-swapping
would occur.

With these changes, I've discovered that the greebles consume 3/4 of the memory
use! That was a surprise; I obviously need to make them more efficient.

Here's the 30,000-buildings render, just as an exercise in absurdity ;-P I'm
still adjusting the lighting.

But my ultimate plan is to make an animated fly-over of the city...so the more
buildings, the better.

Post a reply to this message

Attachments:
Download 'buildings_30000.jpg' (669 KB)

Preview of image 'buildings_30000.jpg'