Hi,

  I've seen posts from folks that claim to use large amounts of memory.

How could I get ahold of either scenes or scenes + options that result in large
memory usage from POVRAY (ideally > 8GB)?

I'm doing some memory performance testing.

Thanks!

Max

Post a reply to this message

"Max" <max### [at] intelcom> wrote:
> Hi,
>
>   I've seen posts from folks that claim to use large amounts of memory.
>
> How could I get ahold of either scenes or scenes + options that result in large
> memory usage from POVRAY (ideally > 8GB)?
>
> I'm doing some memory performance testing.


I always just plot a LOT of spheres.
Take a 1024 x 768 scene and just plot a different sphere for each pixel.
Then you can add z-layers if you need more spheres.

Then you can add textures, finishes, etc.


I'm sure filling up arrays will eat up lots of memory as well.
New macros < 256 kb are cached in memory as well - so you could just define a
bunch of macros.

Post a reply to this message

Perhaps run a #while loop or #for loop with a HI-rez image_map in it. (I don't
think such a scene actually needs a full *render*-- the memory requirement will
vastly increase during the parsing stage, IIRC.) Something like...

#declare C=1;
#while(C < 10,000) // or whatever
pigment{image_map{... HI-res image...}}
#declare C = C+1;
#end

That should repeatedly load the image_map into memory.

(BTW: To *prevent* the unnecessary memory usage, #declare the pigment *before*
it's used in the loop.)

Post a reply to this message

Le 17-10-13 à 20:11, Max a écrit :
> Hi,
> 
>    I've seen posts from folks that claim to use large amounts of memory.
> 
> How could I get ahold of either scenes or scenes + options that result in large
> memory usage from POVRAY (ideally > 8GB)?
> 
> I'm doing some memory performance testing.
> 
> Thanks!
> 
> Max
> 
> 
> 

In a few nested loops, define some objects, each one individualy textured :
#declare R=seed(0);
#declare I=9e9;
#while (I>0)
  #declare J=9e9;
  #while (J>0)
	sphere{
	 <rand(R),rand(R),rand(R)>*10000 0.1+rand(R)
	 pigment{rgb<rand(R),rand(R),rand(R)>}
	 finish{diffuse 0.3+rand(R)/2}
	}
   #delcare J=J-1;
   #end
  #declare I=I-1;
#end

81000000000000000000 spheres, each with a different texture. Hope that 
you have enough RAM for that...

Post a reply to this message

Am 14.10.2017 um 14:02 schrieb Bald Eagle:

> I'm sure filling up arrays will eat up lots of memory as well.
> New macros < 256 kb are cached in memory as well - so you could just define a
> bunch of macros.

Hm... did I remember that number wrong?
Nope, source code agrees with my memory: It's 64 kiB.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> Le 17-10-13 à 20:11, Max a écrit :

Thank you! Very helpful. I went with allocating many spheres.

Next question: how likely is someone to do such a thing in a real rendering? Are
there real renderings that need large numbers of objects allocated?

I'm looking for the largest memory using 'real' rendering. Any ideas?

Would povray be able to do more if memory were along the lines of 32GB or larger
for the average user?

Thanks,

Max

Post a reply to this message

Am 17.10.2017 um 01:17 schrieb Max:
> Alain <kua### [at] videotronca> wrote:
>> Le 17-10-13 à 20:11, Max a écrit :
> 
> Thank you! Very helpful. I went with allocating many spheres.
> 
> Next question: how likely is someone to do such a thing in a real rendering? Are
> there real renderings that need large numbers of objects allocated?
> 
> I'm looking for the largest memory using 'real' rendering. Any ideas?
> 
> Would povray be able to do more if memory were along the lines of 32GB or larger
> for the average user?

The more main memory you have, the more POV-Ray can indeed do in terms of...

- Geometric detail in the scene (number of primitives in case of CSG, or
number of triangles in case of meshes).

- Texture detail in the scene, in case of image-based textures.

- Illumination detail (number of light sources, number of radiosity
samples, photon density).

Post a reply to this message

On 17-10-2017 2:45, clipka wrote:
> Am 17.10.2017 um 01:17 schrieb Max:
>> Alain <kua### [at] videotronca> wrote:
>>> Le 17-10-13 à 20:11, Max a écrit :
>>
>> Thank you! Very helpful. I went with allocating many spheres.
>>
>> Next question: how likely is someone to do such a thing in a real rendering? Are
>> there real renderings that need large numbers of objects allocated?
>>

Well, Vermeer's Cat by Ive (see p.b.i.) would be a good example of large 
numbers of objects (cat's hairs).

-- 
Thomas

Post a reply to this message

"Max" <max### [at] intelcom> wrote:

> Next question: how likely is someone to do such a thing in a real rendering?

Very.

"Taking advantage of POV-Ray's clever memory management for copies of meshes,
this one has more than 12000 oak trees. "
http://hof.povray.org/River.html


 Are
> there real renderings that need large numbers of objects allocated?
http://hof.povray.org/fallfury.html

This doodle alone consisted of 655,000 untextured spheres.
http://news.povray.org/povray.binaries.animations/message/%3Cweb.592d5e424e850994c437ac910%40news.povray.org%3E/#%3Cweb
.592d5e424e850994c437ac910%40news.povray.org%3E

That's just the objects.
Now consider that I might want to store the locations in an array, do
calculations with stored variable values, add textures, etc.

Other people routinely work with meshes in excess of a million vertices.


> Would povray be able to do more if memory were along the lines of 32GB or larger
> for the average user?


YES.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Max" <max### [at] intelcom> wrote:
>
> > Would povray be able to do more if memory were along the lines of 32GB
> or larger for the average user?
>
> YES.

A naive question: Does POV-Ray actually choke on a larger-than-RAM-memory scene?
I thought disc-swapping would take over (slower of course, but with no outright
crash.)

Post a reply to this message