In article <3a2841d2$1@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> You are out of memory.  Turning of preview will help you reduce needs 
> for memory.  If you had read the documentation, you would know that 
> the what the image buffer is and that it has nothing do do with your 
> scene directly.

I have also had this file init error when running two copies of POV-Ray 
at once.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <chrishuff-73A2A7.20563601122000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> I have also had this file init error when running two copies of POV-Ray
> at once.

This most likely is not a file init error. It says error code -108, go and
look it up ;-)


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> If you had read the documentation, you would know that the what the
> image buffer is and that it has nothing do do with your scene directly.

I beg your pardon, sir.  I have read the documentation fairly
thoroughly; I do not recall seeing a listing of cryptic error codes such
as -108 listed anywhere in it.  If you would be kind enough to point out
to me where that is, I shall refrain from bothering you in the future.

> PS: POV-Ray Mac issues best fit in the "povray.macintosh" newsgroup.  If you
> don't want to post there (I can't think of a reason), at least let other
> people know which platform you are using...

Again, I beg your pardon.  I did not realize this was a macintosh
specific question; I believed it to be generated by POV's renderer, and
thus, to be a platform independent question.  Add to that the fact that
p.macintosh is used /very/ sparsely, and perhaps you will perceive my
reluctance to post this question there.

However, I realize that you are a busy person, and I therefore excuse
you from reading any further posts from me, as no doubt, they will turn
out to be horrendous wastes of your time, just as this one was.

-- 
Dawn McKnight      | "Who cares what the hipbone's connected to? I'm in Neurology!"
McK### [at] maccom   |					-- Justine Devlin, M.D.

Post a reply to this message

In article <3A286D04.A7BD3287@mac.com> , Dawn McKnight <mck### [at] maccom> 
wrote:

> I beg your pardon, sir.  I have read the documentation fairly
> thoroughly;

Unfortunately I cannot grand your request for a full pardon.  Let me quote
the POV-Ray Mac documentation, page 26:

>>
Output Image Memory
POV-Ray tries to store the output Preview image entirely in application RAM
memory while rendering.  Because the image requires approximately Width x
Height x 4 bytes of memory, sometimes this is not possible.  For example, a
640 x 480 pixel image needs about 1.25 megabytes of RAM.  When POV-Ray
finds that it can not hold the image in RAM, it will start saving parts of
it in a temporary disk file, and swap it in to a smaller RAM buffer in
rectangular chunks.  This lets you create very large images with limited
RAM, at the cost of slower rendering time and more disk I/O.  This is
referred to in POV-Ray Mac as the "Image Buffer" or IB.  To avoid increased
wear and tear on your hard disk, and to speed up rendering times on large
images, you can allocate more application memory to POV-Ray, to reduce the
use of the Image Buffer disk swapping. If you do not have enough memory in
your Mac and the IB is used heavily, you can speed things up a lot and
reduce RAM and disk space usage a lot by turning off the Preview Window when
it renders.  You can do this by opening the Render Settings dialog, and
going to the Preview pane, and turning  off "Show Preview."
<<

As the error message you cite clearly states "Could not create image
buffer.", you obviously never read the documentation, or looked in the
Render Preferences dialog Preview pane where you find a "Image buffer cache
size" slider.

Thus, I stand to my earlier "RTFM".

> I do not recall seeing a listing of cryptic error codes such
> as -108 listed anywhere in it.  If you would be kind enough to point out
> to me where that is, I shall refrain from bothering you in the future.

You can download the whole list here:
<http://developer.apple.com/techpubs/macos8/ResultCodeTable/ResultCodes.pdf>

Further, you may have noticed that I did not refer to "(Error: -108)", which
is just a hint for me in case of a real problems to find out where exactly
the error is happening if I cannot reproduce it on my system.

In your case there are actually two errors because you are out of memory.
First the "File init error." which simply says that the internal buffer for
the output image file and thus the file itself could not be created. Second
the display image buffer, which requires a lot of memory as well, cannot be
created.

> Again, I beg your pardon.  I did not realize this was a macintosh
> specific question; I believed it to be generated by POV's renderer, and

Thus, I stand to my earlier "RTFM", or maybe even "RTFD" (D for Dialog box).

And maybe the - 20 or so? - clear explanations in the documentation how lack
of memory assigned to POV-Ray will cause complex scenes to fail to render
were not enough?  RTFM!!!

> thus, to be a platform independent question.  Add to that the fact that
> p.macintosh is used /very/ sparsely, and perhaps you will perceive my
> reluctance to post this question there.

Yes, because it is for Mac issues, not general discussion!  If you do not
post Mac issues there (through people have always received helpful responses
there, haven't they?), how are there going to be any responses there?

I assumed you have been to these groups long enough to have read
povray.announce.frequently-asked-questions "Welcome To the POV-Ray News
Groups".  In case you have not (which seems to be the case), I strongly
suggest to read all the messages in that group - it also explains why it
helps if you let people know the platform you are running POV-Ray on...

> However, I realize that you are a busy person, and I therefore excuse
> you from reading any further posts from me, as no doubt, they will turn
> out to be horrendous wastes of your time, just as this one was.

Thank you for being so generous!  After all, all the team did was develop,
compile, debug and distribute it to you for free, in our spare time - so we
really appreciate user feedback like yours, it motivates us every day to
spend our free time and continue our development.


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 

Gee, what a friendly forum this has become!
;)

The way I read the message I would have assumed that the problem was in the
scenefile but then again, I did read the documentation (for 3.0 that is) but I
didn't memorize it.
I've had similar problems with scenes on my Windows-system but I admit I don't
recall the exact error-message. Most of the time I tried closing some other
applications (mostly POV-Ray too) and rerendering the scene, which seemed to
help.

Kind regards,

Remco

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > However, I realize that you are a busy person, and I therefore excuse
> > you from reading any further posts from me, as no doubt, they will turn
> > out to be horrendous wastes of your time, just as this one was.
> 
> Thank you for being so generous!  After all, all the team did was develop,
> compile, debug and distribute it to you for free, in our spare time - so we
> really appreciate user feedback like yours, it motivates us every day to
> spend our free time and continue our development.

You appear to be speaking for the team. Is that correct?

-Xplo

Post a reply to this message

In article <3A294D87.F5DE990C@unforgettable.com> , Xplo Eristotle 
<inq### [at] unforgettablecom>  wrote:

> Thorsten Froehlich wrote:
>>
>> > However, I realize that you are a busy person, and I therefore excuse
>> > you from reading any further posts from me, as no doubt, they will turn
>> > out to be horrendous wastes of your time, just as this one was.
>>
>> Thank you for being so generous!  After all, all the team did was develop,
>> compile, debug and distribute it to you for free, in our spare time - so we
>> really appreciate user feedback like yours, it motivates us every day to
>> spend our free time and continue our development.
>
> You appear to be speaking for the team. Is that correct?

I am pointing out that we as a team developed it, and that user "feedback"
like this is very de-motivating, which is a thought shared by the team.

Nevertheless, this is only a summary of general thoughts and I speak for
myself, so this is of course as usual no official POV-Team statement.

Oh, and as you have already noticed, only the last paragraph refers to the
team, everything preceding it is only my personal statement.


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <3A294D87.F5DE990C@unforgettable.com> , Xplo Eristotle
> <inq### [at] unforgettablecom>  wrote:
> 
> > Thorsten Froehlich wrote:
> >>
> >> > However, I realize that you are a busy person, and I therefore excuse
> >> > you from reading any further posts from me, as no doubt, they will turn
> >> > out to be horrendous wastes of your time, just as this one was.
> >>
> >> Thank you for being so generous!  After all, all the team did was develop,
> >> compile, debug and distribute it to you for free, in our spare time - so we
> >> really appreciate user feedback like yours, it motivates us every day to
> >> spend our free time and continue our development.
> >
> > You appear to be speaking for the team. Is that correct?
> 
> I am pointing out that we as a team developed it, and that user "feedback"
> like this is very de-motivating, which is a thought shared by the team.

Ah, yes. I can see how being asked about a cryptic error which isn't
explicitly defined in the documentation would make you resent your
hobby. Perhaps you would find a stream of questions like "how do i make
a ball?????" more gratifying.

Oh, wait, I'm being sarcastic. Silly me.

As to the section of the documentation you quoted, someone who isn't
intimately familiar with the source code might not find it obvious that
a lack of memory would be causing an error in a piece of code which was
designed to *prevent* an out-of-memory error.

I guess being a developer gives you the right to be as big an asshole as
you want.

-Xplo

Post a reply to this message

In article <3A29A00D.CB8AFD1F@unforgettable.com> , Xplo Eristotle 
<inq### [at] unforgettablecom>  wrote:

> Ah, yes. I can see how being asked about a cryptic error which isn't
> explicitly defined in the documentation would make you resent your
> hobby. Perhaps you would find a stream of questions like "how do i make
> a ball?????" more gratifying.
>
> Oh, wait, I'm being sarcastic. Silly me.

Hmm, I think you are missing my point.  I didn't want to spend much time on
this, so I kept it short originally, just gave him the solution and pointed
out that he could have found the answer in the documentation, a classical
RTFM if you want.  He has also been in these groups for a month, and is
aware of the Mac group, so a straight forward suggestion to post Mac issues
there is reasonable, I think.

Maybe the RTFM was not warranted if he did not understand the documentation
section, fine!  But did I refer in any way to the "cryptic error codes such
as -108"?  No, but in turn he does not complain about the hard to understand
documentation, but sends me and posts the reply.

And I was referring to his response, not his original question.

> As to the section of the documentation you quoted, someone who isn't
> intimately familiar with the source code might not find it obvious that
> a lack of memory would be causing an error in a piece of code which was
> designed to *prevent* an out-of-memory error.

No, the section tries to avoid having to go into technical details.
Unfortunately the concept used is rather complex.  However, a certain piece
of image needs to be in memory at a particular time, even if it is small, it
takes up considerable space.  The technical details are in the direction of
the standard C memory model not being very "Mac-like" and causing plenty of
problems that are Mac specific and common to a lot of applications (and
admittably the single most tech-support problem on Macs).  For this reason
there is another section in the documentation, on page three, explicitly
marked:

>>
Warning -- Low Memory problems!
This has always been the case, but it bears repeating... POV-Ray gets
unpredictable under low-memory conditions.  If you render a scene and
POV-Ray complains that it is out of memory (and dims the Render menu item),
you should quit POV-Ray, possibly increase its Application Memory size in
the Finder, and re-run POV-Ray.
<<

Or, just prior to the section quoted in my first reply:

>>
Memory
Ray tracing generally uses a LOT of RAM memory to store all the elements of
a scene and the final image.  POV-Ray Mac initially comes with an
application memory size set at 9,000 Kilobytes (3,500 Kilobytes for 68K
applications.)  This size is sufficient to render the standard example files
at 320x240 with room to spare. For less complex images, POV-Ray can render
small scenes effectively in a memory partition as small as 3,000K.  The
majority of the example scene files will render in 6,000K.  But when you
render more complex scenes, or render to large output image files, you will
need to increase POV-Ray's application memory size.
To change POV-Ray's memory size, first make sure POV-Ray is not running.
Click once on the POV-Ray program icon from the Finder, then choose "Get
Info" from the File menu.  The (preferred) application memory size is in a
box in the lower right corner of the window, and can be edited, as long as
POV-Ray is not running.  The value is in Kilobytes, so for example, to
change it to 8 megabytes (approximately 8,000 Kilobytes,) you would enter
8000.
The bad news is that trying to determine how much  memory a particular scene
will require is not easy.  The best thing to do is to quit most or all other
applications, set POV-Ray as big as you can, then try to render the scene.
As it renders, switch back to the Finder, and choose "About this Computer"
from the Apple menu.  Note the memory status bar beside the POV-Ray
application, and how full it is.  This will give you a good indication of
what you can safely set the Application size down to for this rendering job.
Also note that changing the output image size changes the memory
requirements.  Now in POV-Ray 3, at the end of the rendering session the
Status window has a section on memory usage, which can also help track down
how much you need.  This memory usage is only for the scene objects, it does
not reflect the size of any screen display output image buffers.
Another thing that can happen is that after doing many renders in a row,
POV-Ray can slowly use up its memory space.  This is known in technical
circles as memory fragmentation.  If you get an error message saying that
POV-Ray has run out of memory, and you find that the Open and Render menus
are permanently dimmed, POV-Ray has exhausted its memory.  You should save
your source file, quit POV-Ray, and restart it.  We had to decide which was
better, (1) Apple's memory scheme which cleaned up properly after itself but
was slow, or (2) C's memory scheme which didn't clean up after itself well,
but was much faster.  Since this is a ray tracer, we felt speed was more
important.
<<

And just to make sure, there are plenty of other clear pointers to increase
memory allocated for POV-Ray.  This (still) has to be done by the user
(unfortunately), but it works the same for every Mac application and is easy
to do in the Finder.

And look closer at his original statement about what he is modeling - an
aircraft cockpit with several markings.  Based on this and the fact that he
ran out of memory, lots of image maps are in these texture layers, I
suspect.  Image maps = memory consumption, right?

The problem is that making a Mac-like alert box to show an error or warning
out of the POV-Ray text output is not exactly feasible because of the
console centered design of POV-Ray.  Not to mention, that displaying such a
dialog box under low memory conditions is a hell of a mess to do, if it
works at all - Mac users with lots of RAM can gain a at least 10% render
speed (most applications benefit from turning off VM) increase by turning
off Virtual Memory, and if you run out of memory then, well, there is simply
no way to get any.

> I guess being a developer gives you the right to be as big an asshole as
> you want.

No, it does not.  Nor does me being a developer give you as user the right
to insult me as you want.  And, have I insulted anybody personally so far?
Except you see the claim someone has not read the documentation as an
insult, I have not!

What I do not like is the attitude by some people that they do not even want
to try to solve the problem by themselves.  There are plenty of pointer is
the documentation to increase memory whenever you have problems (as our past
experience shows that this solves over 50% of all problems).

But no, how can one draw the conclusion from the error message "Could not
create image buffer" if "Is there a limit to the number of transparent
layers you can put on an object?".

A first idea could be to try to find the word "image buffer" in the POV-Ray
User Manual, of course it is nowhere in there.  Well, the Mac documentation
would be the next option.  In particular, the Render Settings in the Mac
version are all done through a multi-pane dialog, which actually has
something called "image buffer cache size".  Notice the first two words -
"image buffer".  At least this would have limited the problem to a Mac one.

However, all he did was at most try to render again (if at all), and then,
because it is more convinient than looking at the documentation for five
minutes or less, to simply post it here.  How little consideration he gave
this?  Well, he did not even bother go give any information about the
platform he is running on.

And notice he later says "Add to that the fact that
p.macintosh is used /very/ sparsely, and perhaps you will perceive my
reluctance to post this question there." - he didn't want to look or think
about the problem, just wanted an answer immediately.

One way he could have answered could have been along the lines:

"I read the documentation, but I don't memorise it. You documentation is
hard to understand and it is not clear what an image buffer is or if it is
Mac only."

He could have added a paragraph or two trying to reword the original
documentation and suggest it should be included to avoid future problems.

But no, his attitude of "there is a problem, I don't care if POV-Ray is
free, just fix it now, I am your customer" is the problem I have with him.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

>
> Hmm, I think you are missing my point.

Perhaps I am, and so I return to this one final time.

> I didn't want to spend much time on
> this, so I kept it short originally, just gave him the solution and pointed
> out that he could have found the answer in the documentation,

First of all, just for the record, I'm a woman.  Dawn is not typically a male
name, though I understand from your name that you probably live someplace where
you don't run into a great many Dawns, so I forgive you the error.

However, I did not feel that you 'just' gave me the solution and..., but that
you gave me the solution and a ration of attitude.  I don't apreciate being
told that if I had just thought about it a little more, I could have come up
with the solution... mainly because I think quite thoughoughly about
/everything/ before I post here.  I am a woman in a male dominated field; I am
paranoid about asking stupid questions, largely because of responses such as
yours.

> No, the section tries to avoid having to go into technical details.
> Unfortunately the concept used is rather complex.

Surprising, then, that I didn't pick up on it the first time, isn't it?

> And look closer at his original statement about what he is modeling - an
> aircraft cockpit with several markings.  Based on this and the fact that he
> ran out of memory, lots of image maps are in these texture layers, I
> suspect.  Image maps = memory consumption, right?
>

If you state it that way, with the clear steps of your reasoning, yes, it seems
obvious.  It was not obvious to me at the time I asked the question; I
appologize for not being familiar with how C memory functions translate, or do
not translate, into Mac OS programs.

> No, it does not.  Nor does me being a developer give you as user the right
> to insult me as you want.  And, have I insulted anybody personally so far?

I certainly felt insulted; however, I recognize that you are not responsible
for my feelings.

> What I do not like is the attitude by some people that they do not even want
> to try to solve the problem by themselves.  There are plenty of pointer is
> the documentation to increase memory whenever you have problems (as our past
> experience shows that this solves over 50% of all problems).
>

You are making an unwarrented presumption.  I did in fact try to solve the
problem myself.  I sat and read the section of the documentation on layered
textures and image maps three or four times, trying to see if there were any
hidden 'gotchas' that I had missed the first time.

I tried moving the camera (the solution to the last stupid question I posted to
this group); I tried commenting out individual portions of my layered
textures.  Again, perhaps if I were more knowlegeable, or were already thinking
about memory usage, I would have thought about how much memory the individual
decals were taking; I did not.

What I did end up wondering, and asked about, was if there was a limit to how
many layers of transparency could be modeled, because /that/ is what I was
thinking about at the time... the complexity of modeling a transparent object
with one piece which is non-transparent.

As it turned out, I was wrong.  I am often wrong.  Mea culpa.


> But no, how can one draw the conclusion from the error message "Could not
> create image buffer" if "Is there a limit to the number of transparent
> layers you can put on an object?".
>

Because I had also, in one of the renders previous to the one I quoted in my
message, gotten an error about a lack of IDAP information.  I have no idea what
IDAP information is; I presumed that there might be a problem with one of the
images I was using in my image_map.

I am not a technical person.  I don't program, I don't have a degree in math, I
don't really even have all that much to do with computers, usually.  I simply
was not thinking in the right direction, and after beating my head against it
for an hour or so, I asked a question.

Prior to this, all of the responses I have gotten on this group have been both
helpful and friendly.  Your response, while perhaps helpful, was decidedly
unfriendly.

> However, all he did was at most try to render again (if at all), and then,
> because it is more convinient than looking at the documentation for five
> minutes or less, to simply post it here.  How little consideration he gave
> this?  Well, he did not even bother go give any information about the
> platform he is running on.

Again, you are making an unwarrented assumption.  You were not there; you do
not know what steps I took, or what I looked at.  You are /assuming/ that I was
inconsiderate.  I did not feel that I was being.  However, thank you, in the
future I shall be much more leary of posting to this group.

>  he didn't want to look or think about the problem, just wanted an answer
> immediately.
>

Another unwarrented assumption.

> But no, his attitude of "there is a problem, I don't care if POV-Ray is
> free, just fix it now, I am your customer" is the problem I have with him.

Her.

And yet another unwarrented assumption.  You have a completely wrong idea of my
attitude.  My attitude when I originally posted the question was "I don't
understand this, and I have exhausted the resources I have available to me, so
I was hoping someone could offer some insight."

After your post, my attitude became, "I don't care who you are, or how useful
the information you've given is, you have belittled me, and I don't care for
that."

And you know what?  I don't.

Now, this has all gone on for /much/ longer than it really ought to have.  I
feel insulted by you; you feel insulted by me.  To such an extent as I am
responsible for having begun this, I appologize.  I never intended to belittle
anyone, never intended that my question should be taken as a slight on the
documentation, the program, or the POV-team.

In fact, I have commented a couple of times on the supurb quality of the
official documentation, and I stand by that statement -- I will even repeat
it.  In general, POV-Ray has the finest official documentation I am aware of in
any open-source program.

I am greatful to those in this group who have helped me out in the past.  I am
greatful to the POV-Team, including yourself, for having produced this program.

What I am not greatful for is the attitude with which you have greeted my
question, my lack of understanding, and my problem.

Post a reply to this message