[Windows 10, official 3.8.0 beta 1]

While playing with several of the mesh camera's included demo files...
     meshcam_persp_demo.pov
     meshcam_stereo_demo.pov

...I've noticed something odd about the memory usage.

At the bottom of POV-ray's Windows GUI is a running tally of the ram memory(?)
being used for a scene. Usually, once a scene is parsed and rendered, that value
drops back to the 'base' value. (Mine is about 22MB; I have a lot of scene files
open.)

But if I start one of the demo files and then *stop* the process during the
parsing stage, the 'used memory' remains at a certain high value, instead of
dropping back to the base. If I repeat this process several times, the used
memory keeps climbing. If I then run the demo to completion, *its* used memory
is successfully cleared-- but only back to the previously-set high value.

At this point, I tried switching to a completely different scene (no mesh
camera) that also happens to have a rather large mesh2 object in it (the
Stanford 'Lucy' winged statue.) This scene has no such problems, even if I stop
the parsing mid-stage. But the previously-high 'used memory' value -- which is
now the 'base'-- is still there, from the mesh camera use.

Unless the Windows GUI is reporting a false value, it would seem that the mesh
camera could conceivably run out of ram memory, in certain situations. The only
way to empty the memory is to quit POV-ray and restart.

Try running one of the demo scenes at 1280X960 (a purposely slow-to-parse
setting), then halt it while parsing.

Post a reply to this message

On 14/05/2023 18:11, Kenneth wrote:
> Try running one of the demo scenes at 1280X960 (a purposely slow-to-parse
> setting), then halt it while parsing.

I do see this behavior as you describe. However it would not be related to the mesh
camera itself as the parsing is halted during generation of the mesh itself. If the
memory is not being released then it is the mesh that's leaking. This could be
confirmed by trying other mesh-intensive renders with a normal camera, either
generating one on the fly or loading from a file (I think the mesh camera demos even
allow writing the mesh to a file, there's a variable for it).

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 14/05/2023 18:11, Kenneth wrote:
> > Try running one of the demo scenes at 1280X960 (a purposely slow-to-parse
> > setting), then halt it while parsing.
>
> I do see this behavior as you describe. However it would not be related to
> the mesh camera itself as the parsing is halted during generation of the
> mesh itself. If the memory is not being released then it is the mesh
> that's leaking. This could be confirmed by trying other mesh-intensive
> renders with a normal camera..

I'm actually having trouble finding one of my own scenes that is likewise
mesh-intensive, to compare-- even my scene using the very dense 'Lucy' mesh2
statue. My current machine is so fast that it doesn't afford a good opportunity
to 'halt' the render during the parsing. (The mesh camera demo scenes are the
exception.)

Just to be clear, the 'memory build-up' only occurs when I stop the render
prematurely during the parsing stage.

Here's a test scene using the mesh-generating feature of "shapes.inc". With a
high res setting, it takes awhile to parse... but so far, I'm not seeing the
same kind of memory build-up as with the mesh camera scenes, when I halt the
parsing (although it takes a few seconds for the memory to be released.)

------

#version 3.8;
global_settings{assumed_gamma 1.0}
#include "shapes.inc"

#declare crackle_pattern =
function{
        pattern{
                crackle
                scale 4
                warp{turbulence .4 omega .1}
                scale 1/4
                scale .325 // .325
                translate .5*z
               }
        }

#declare i = .085;
#declare h = 9/16;
#declare f = 3/2;

#declare cave_function =
function{-crackle_pattern(x,y,z)*i}

#declare cave_rez = 1300;
#declare cave_radius = .57;
#declare cave_begins_at = -.5; // in z
#declare cave_length = 2; // TOTAL length in z

#declare rez_multiplier = (1/cave_radius)*(cave_length/(2*pi));

HF_Cylinder(
cave_function,0,0,<cave_rez,cave_rez>,0,"",<0,0,cave_begins_at>,
<0,0,cave_length + cave_begins_at>,cave_radius,1
           )

Post a reply to this message

On 15/05/2023 03:10, Kenneth wrote:
> Just to be clear, the 'memory build-up' only occurs when I stop the render
> prematurely during the parsing stage.
> 
> Here's a test scene using the mesh-generating feature of "shapes.inc". With a
> high res setting, it takes awhile to parse... but so far, I'm not seeing the
> same kind of memory build-up as with the mesh camera scenes, when I halt the
> parsing (although it takes a few seconds for the memory to be released.)

Instead of trying a different scene, I suggest you just change the mesh camera scene
that you were testing to use a normal camera instead. Then do the same thing to
interrupt the parsing and see if you still have a memory build-up (you will).

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 15/05/2023 03:10, Kenneth wrote:
>
> > But if I start one of the demo files and then *stop* the process during
> > the parsing stage, the 'used memory' remains at a certain high value...

> > Just to be clear, the 'memory build-up' only occurs when I stop the render
> > prematurely during the parsing stage.

It just occurred to me that I probably used the wrong wording to describe what
I'm doing. What I meant was: aborting the render, not simply hitting the 'pause'
button. I apologize if that confused anyone.

>
> Instead of trying a different scene, I suggest you just change the mesh
> camera scene that you were testing to use a normal camera instead. Then
> do the same thing to interrupt the parsing and see if you still have a
> memory build-up (you will).
>

[Using the meshcam_persp_demo.pov file]
If you mean commenting-out only the code block that starts with...

           // create the camera with the generated or loaded mesh
           camera{
               mesh_camera{ ...
           ...
                    }
                 }

....yes, the memory build-up continues to happen. As far as I understand the
complete code and includes, the camera mesh(es) are still being created in
meshcam_macros.inc.

Sorry if I'm confused about your suggestion(?)

Post a reply to this message