 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been working on a large animation project (4320 frames), where I'm
rendering a 160x120 draft every night.
One thing I've noticed is that povray is generating a memory.log file, and
it's getting up to a GB in size each time! I have seen on two different
versions of povray (for linux, from debian repositories) that my code is
generating error messages about memory leaks. I've been ignoring them
until now I see my log getting to be a GB.
Questions:
1) Could I just turn this off somehow? ("RTFM" with citation of chapter and
subsection is appreciated).
2) If I'm getting a memory leak error/ a memory log generation:
a) Is my code riddled with errors that will fundamentally slow up my
render speed, OR
b) Is this the price to pay for using all the advanced features in the book
(splines, blobs, etc.,etc.)? I have been in the habit of ignoring error
codes as my SDL's have been generating several view screens of them every
time, even in cases where I think there's no bug, per se. OR
c) A bug in the debian-repository versions of povray that has been
demonstrated not to be in the version from the povray site? (Followup Q:
if I were to get this official version one time, would I be screwed as far
as future updates? There's too many manual things to set up.)
thanks.
Greg M. Johnson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gregjohn wrote:
> 1) Could I just turn this off somehow? ("RTFM" with citation of chapter and
> subsection is appreciated).
Yes, complain to the Debian maintainers.
> c) A bug in the debian-repository versions of povray that has been
> demonstrated not to be in the version from the povray site? (Followup Q:
> if I were to get this official version one time, would I be screwed as far
> as future updates? There's too many manual things to set up.)
The official version builds easily from source. Using the unofficial and
usually (some are worse than others) badly broken Debian-supplied packages
is not recommended. Debian developers haver successfully ignored all advice
from the POV-Team for years, as can be seen in the bug report logs of Debian
for POV-Ray :-(
Thorsten, POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1) Could I just turn this off somehow? ("RTFM" with citation of chapter and
> subsection is appreciated).
No, this is a build-time choice only. It seems the Debian guys decided
to compile their binary using an option that turns debug on (which is bad as
it will slow down rendering speed). I'll have a look at it and bug them.
So for now you have 3 choices, ordered from most simple to most efficient:
1) make Memory.log a symbolic link to /dev/null
2) use the official binary
3) build your own from sources
> a) Is my code riddled with errors that will fundamentally slow up my
> render speed, OR
IIRC memory leaks in 3.6.x may result from parsing/rendering error
or with some scenes using blobs.
> c) A bug in the debian-repository versions of povray that has been
> demonstrated not to be in the version from the povray site?
Most likely what I've written above -- to be checked though.
> There's too many manual things to set up.
Which things?
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Debian developers haver successfully ignored all advice
> from the POV-Team for years
Well, not lately at least :-)
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay, thanks all.
I think I may have the option of trying out the official version on a new
box. I'm unfortunately in the middle of a project where I might be able to
afford continued slow renders, but not risk a major fuddle.
Q: How would I put the official version "on top of" the old one? Last time
I tried that make-install stuff, I think I ended up with povray executable
in a weird directory under /home/greg/ , not in the sensible place the
package management system puts it. (Hence the joy of using package
management.)
But Nicolas, could you keystroke-out the advice for doing the thing with
/dev/null.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It seems the Debian guys decided
> to compile their binary using an option that turns debug on
Indeed this is what they do in the latest 1:3.6.1-6 release
(i.e. in the testing and unstable distributions). I'll submit a bug
report soon.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Q: How would I put the official version "on top of" the old one?
As root, use the install script that comes with the official
PC-Linux distribution of POV (i.e. do not install as regular user).
> But Nicolas, could you keystroke-out the advice for doing the thing with
> /dev/null.
Why? I haven't tested it right now but I don't see what evil
could burn you doing so.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
>> Q: How would I put the official version "on top of" the old one?
>
> As root, use the install script that comes with the official
> PC-Linux distribution of POV (i.e. do not install as regular user).
>
>> But Nicolas, could you keystroke-out the advice for doing the thing with
>> /dev/null.
>
> Why? I haven't tested it right now but I don't see what evil
> could burn you doing so.
I'm guessing he means "can you tell me exactly what to type to implement
your suggestion"?
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] free fr> wrote:
>> 1) make Memory.log a symbolic link to /dev/null
How does one do that?
And I can see how that might save HDD space. But does it also solve the
resource use issue (render speed), or am I better off getting an official
version?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm guessing he means "can you tell me exactly what to type to implement
> your suggestion"?
Ah okay, I first thought this too, but then I got the (wrong) feeling
that it might be some sort of criticism :-p
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
