When I removed the crackle function from my main project, all the problems
disappeared. Memory remained stable, slightly less than 2.0GB. It will be a
painful loss, since it made such beautiful rock surfaces. I guess I will end up
using something like bozo+wrinkles instead.

It is my impression that virtual memory is useful mostly to make memory
management easier, rather than to increase the working memory capacity. It can't
work with 100% physical memory allocated because of excessive disk swapping. I
think this is a fundamental constraint that is common to all OS, whether it is
Windows or Linux or whatever.

So, in this case, the issue is only that what should have only been a painfully
slow render in physical memory, which some users might have found an acceptable
price to pay for a certain effect, became instead a full-blown failure of the
OS. If there is some way in that case, to limit the expansion of memory or exit
with an error, it would probably be better.

I also realize that with beta versions, the development issues are diverse and
priority is correctly given to primary design features above error and UI
issues.

Thanks, everyone for the help! I can now continue with my project, and I have
other radiosity questions which I will move to the other newsgroup.


Thorsten Froehlich <tho### [at] trfde> wrote:
> On 14.02.10 03:30, Ken Willmott wrote:
> > Thanks for the comments... there are good suggestions there. I prepared a test
> > file so that any of you could try it out. I verified that both OS and beta are
> > running 64 bits. I discovered that there are problems even with radiosity
> > commented out. Namely, CPU usage is not 100%, and control does not come back to
> > the GUI after the render is complete.
>
> The low CPU usage is likely related to the use of crackle, which requires
> some data to be shared between threads. This in turn creates dependencies
> between render threads. The performance of multi-threaded ray tracing
> exclusively depends on the independence of render threads.
>
> Since crackle also happens to be one of the less suitable functions for
> integration performed to render it is an isosurface, it takes very long time
> to find intersections with the isosurface involving a real lot of crackle
> pattern evaluations. The POV-Ray statistics likely show this.
>
> Freeing memory in this state, for various reasons, may also take quite some
> time. Again, the statistics may provide some indication on what is going on.
>
>  Thorsten, POV-Team

Post a reply to this message