 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How does one do that?
ln -fs /dev/null Memory.log
The major drawback with this simple workaround is that you have to
create such a symlink in each and every directory where you run povray.
> But does it also solve the
> resource use issue (render speed)
Shot answer: no.
Long answer: the Debian build includes in particular some code
that checks memory access (and also makes memory usage larger). This
and other things will slow down rendering. I never did any serious
testing though, and the slowdown could be in the order of a few percent
only. OTOH, especially with fast renders, without writing the Memory.log
file to disk (as proposed above) could also somewhat reduce the slowdown.
But in the end you'd better live with a binary that contains no debug code
at all.
or am I better off getting an official
> version?
Yes. Or even better: build your own. Especially if your machine
is built around a SSE2-compatible CPU.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
