Consider

union{
    sphere{<0,0,0>,1}
    sphere{<1,0,0>,1}
    sphere{<2,0,0>,1}
.... 10,000th sphere
texture{}
}

Is the rendering faster if we write it as

#declare S=sphere{<0,0,0>,1}

union{
    object{S translate<0,0,0>}
    object{S translate<1,0,0>}
    object{S translate<2,0,0>}
.... 10,000th object
texture{}
}

Note that the question is not about applying texture and normals, as they are
applied after the union.

I understand that the latter case consumes less memory, but the key problem is
the rendering time.

To my understanding, the time-consuming process is when POVRAY applies the
light. Otherwise, placing the object is the rapid step.

Post a reply to this message

Le 2020-05-03 à 11:35, Kima a écrit :
> Consider
> 
> union{
>      sphere{<0,0,0>,1}
>      sphere{<1,0,0>,1}
>      sphere{<2,0,0>,1}
> .... 10,000th sphere
> texture{}
> }
> 
> Is the rendering faster if we write it as
> 
> #declare S=sphere{<0,0,0>,1}
> 
> union{
>      object{S translate<0,0,0>}
>      object{S translate<1,0,0>}
>      object{S translate<2,0,0>}
> .... 10,000th object
> texture{}
> }
> 
> Note that the question is not about applying texture and normals, as they are
> applied after the union.
> 
> I understand that the latter case consumes less memory,

Not in your example.

  but the key problem is
> the rendering time.
> 
> To my understanding, the time-consuming process is when POVRAY applies the
> light. Otherwise, placing the object is the rapid step.
> 
> 

Both cases will use about the same amount of memory and render in 
exactly the same time. The second case will use a little bit more memory 
to store the definition of the object used. That's the case for almost 
every procedural primitives.
The only advantage here is the ability to change the object used by 
changing a single line of code.

If, instead of spheres, you used some meshes, then, there would have 
been a huge reduction on memory use.
In this case, the first form would need to store each individual meshes 
while the second would instantiate a single mesh.

When using meshes, the reduction in memory use can prevent paging that 
can dramatically bog down the rendering. It may even mean the difference 
between been able to render at all and crashing.

Post a reply to this message

Check out this thread where we measure the elapsed time.

http://news.povray.org/povray.general/message/%3Cweb.59da2fc231ae2f125cafe28e0%40news.povray.org%3E/#%3Cweb.59da2fc231a
e2f125cafe28e0%40news.povray.org%3E

That's parsing time in the scene file.

You'll get the render time in the render statistics after the render completes.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
>
> If, instead of spheres, you used some meshes, then, there would have
> been a huge reduction on memory use.
> In this case, the first form would need to store each individual meshes
> while the second would instantiate a single mesh.
>
> When using meshes, the reduction in memory use can prevent paging that
> can dramatically bog down the rendering. It may even mean the difference
> between been able to render at all and crashing.

I'm very much interested in meshes. Does declaring the mesh affect the rendering
time?

I have 32/64 cores and 128GB memory. My CPU usage always reaches 100% but I
hardly see any memory consumption. This is the reason that my only concern is
the CPU usage.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Check out this thread where we measure the elapsed time.
>
>
http://news.povray.org/povray.general/message/%3Cweb.59da2fc231ae2f125cafe28e0%40news.povray.org%3E/#%3Cweb.59da2fc23
1a
> e2f125cafe28e0%40news.povray.org%3E
>
> That's parsing time in the scene file.
>
> You'll get the render time in the render statistics after the render completes.

The code is quite handy. In fact, I tried to run some benchmarks, but for the
sphere example, the difference is trivial to make any conclusion. And I was
afraid other factors may come to consideration if blindly test complex systems.

Thus, I asked my question from the theoretical perspective to understand the
fundamental concept.

Post a reply to this message

"Kima" <nomail@nomail> wrote:
> Consider
>
> union{
>     sphere{<0,0,0>,1}
>     sphere{<1,0,0>,1}
>     sphere{<2,0,0>,1}
> .... 10,000th sphere
> texture{}
> }
>
> Is the rendering faster if we write it as
>
> #declare S=sphere{<0,0,0>,1}
>
> union{
>     object{S translate<0,0,0>}
>     object{S translate<1,0,0>}
>     object{S translate<2,0,0>}
> .... 10,000th object
> texture{}
> }
>
> Note that the question is not about applying texture and normals, as they are
> applied after the union.
>
> I understand that the latter case consumes less memory, but the key problem is
> the rendering time.
>
> To my understanding, the time-consuming process is when POVRAY applies the
> light. Otherwise, placing the object is the rapid step.

I'm glad an initial declaration is indeed what we chose for Blender exporter, so
that Blender user object instances are kept as POV instances with only a matrix
transform. It made a huge difference when we did that change, though I'm sure
it's the place where subtle changes are to be optimized to hunt for even more
potential improvement.

Post a reply to this message

Le 2020-05-03 à 13:24, Kima a écrit :
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> If, instead of spheres, you used some meshes, then, there would have
>> been a huge reduction on memory use.
>> In this case, the first form would need to store each individual meshes
>> while the second would instantiate a single mesh.
>>
>> When using meshes, the reduction in memory use can prevent paging that
>> can dramatically bog down the rendering. It may even mean the difference
>> between been able to render at all and crashing.
> 
> I'm very much interested in meshes. Does declaring the mesh affect the rendering
> time?
> 
> I have 32/64 cores and 128GB memory. My CPU usage always reaches 100% but I
> hardly see any memory consumption. This is the reason that my only concern is
> the CPU usage.
> 
> 
> 

POV-Ray is pretty efficient in it's memory use because it use procedural 
primitives.
What use the most memory per object are single use mesh, image_map, the 
images used as data source for height_field.
Next, using thousands, or even millions of objects.
Obviously, radiosity and photons scene need some extra memory.
You also need more memory if you want to render a larger image.

Using many instances of declared meshes will save memory as the mesh 
reside in memory only once, but have no effect on the CPU usage and 
render speed. If you are short on memory, not your case, that can have a 
huge impact by preventing the use of virtual memory. If that happens, 
you'll notice a marked decrease in CPU use.



Do a small test :
Have an include file defining a mesh WITHOUT using #declare.

In a loop, #include "Meshfile.inc" about 1000 times with some translation.
Take note of the memory use, parse time and render time.

Next, use
#declare MeshName = #include"Meshfile.inc"
then use it as many times.
Take note of the memory use, parse time and render time and compare.

Both should have the same, or almost same, render time.
Parse time should differ quite a bit.
Memory use should be very different.

Post a reply to this message