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