|
|
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
|
|