POV-Ray : Newsgroups : povray.binaries.images : city buildings-- WIP 9_29_2020 : Re: city buildings-- WIP 9_29_2020 Server Time
15 May 2024 00:57:31 EDT (-0400)
  Re: city buildings-- WIP 9_29_2020  
From: Kenneth
Date: 4 Oct 2020 23:55:00
Message: <web.5f7a98a232341a55d98418910@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.