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

In article <3A29C104.C8B37565@mac.com> , Dawn McKnight <McK### [at] maccom> 
wrote:

>> 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

Ups, I am sorry, I did not know!

> However, I did not feel that you 'just' gave me the solution and..., but that
> you gave me the solution

I have to admit I am usually very direct, and this might occasionally come
through as being unfriendly.  I am always that way, and it is never personal
or meant to be offensive.

> and a ration of attitude.

Well, yes...

> 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.

Unfortunately, few users do so - at least it appears that way.

If you are not sure if something is just something simple you are missing,
post it there and you don't need to be afraid to be asking the wrong
question.  If it is too advanced, don't worry there, you will still get a
good answer all the time.  There is nothing wrong with being inexperienced
with POV-Ray and a simple informal agreement in the POV-Ray newsgroups is to
never say RTFM to users in the povray.newusers groups :-)

However, I should also say that the question you had is not a typical new
users question - to create a scene that exhausts the default memory
assignment of about 8 MB requires at least some time with POV-Ray, so I also
assumed you already ran in memory problems long before based on other users'
reports during the past few years...

> I am a woman in a male dominated field; I am paranoid about asking stupid
> questions, largely because of responses such as yours.

Hmm, you could not have known that I did not know you are a woman prior to
my last post, so given how you had to interpret my initial reply I can fully
understand your reply and that you were offended.  I agree with you that a
reply like mine if made only because you are a woman would be complete
inappropriate.

As you now know, I did not know you are a woman and I can assure you no
offence was intended! -- I have to apologise for not noticing this earlier,
as it would have avoided the whole problem :-(


    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:
> 
> 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.

Without the benefit(?) of cross-platform testing, though, it can be
difficult at best to tell if a problem is platform-specific or not, and
given the (apparently) high portability of the code, it seems reasonable
to me to assume that any given problem of unknown cause is probably XP.

Or should we automatically be assuming that any problem we have is
platform-specific, and post our questions and complaints in the
appropriate group, only moving the discussion to .general after someone
who reads that group, but has alternate platform(s) to test for the
problem, confirms that it is, in fact, XP? Seems a little impractical,
if you ask me.

> 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.

I don't think an alert box is necessary; after all, she did *see* the
error message. I question whether the error message was clear enough for
an ordinary user to understand its meaning, though. I'd be lying if I
said that POV never stumped me with any of its error messages (though
mine tend to be syntax problems).

> > 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?

Perhaps not; nevertheless, I feel that you were unnecessarily rude in
your second reply. I don't know what you were trying to accomplish,
other than making the poster look and/or feel like a complete idiot.

> 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.

Granted. I used to get this all the time, and I know how frustrating it
is. Still, I think your way of handling it was inappropriate. If nothing
else, she obviously took the time to learn the app well enough to create
a complex scene (unless she was using a modeller, but there aren't any
good ones for the Mac IMHO), and it has been acknowledged that POV has a
pretty steep learning curve at first; I think that's enough reason to
cut some slack.

> 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.

I wasn't aware that being a POV team member required you to answer any
and all technical questions posed by users, let alone immediately;
rather, I'd assumed that, like POV itself, tech support was something
that would be done in your free time, as circumstances allow. Feel free
to correct me if I'm wrong here.

-Xplo

Post a reply to this message

Thorsten Froehlich wrote:
> 
<..>
> 
> 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.
> 

I can understand you find it annoying that a person having a problem would ask a
question here, when you know the solution is obvious from the documentation.
Personally, I think that is what this forum is for, even though the docs would
solve the problem, not everyone knows his (or her) ways around those well enough
all the time. Especially with a server flooded by the most weird messages on the
most outrageous topics (luckily mostly (re-)directed to the off topic group) I
think a message/question like this doesn't really deserve such a reaction.

Just my 2 ec.

Remco

Post a reply to this message

On Sat, 02 Dec 2000 18:26:32 -0700, Xplo Eristotle wrote:
>I guess being a developer gives you the right to be as big an asshole
>as you want.

Oh, cut it off. Thorsten's first reply was a bit gruff, but it
identified the problem ("out of memory"), gave a workaround ("shut off
preview"), and referred to relevant parts of the documentation and a
newsgroup better suited for this topic. Only when Dawn seemingly ignored
all the advice he had given and only made scathing remarks about his
lack of helpfulness, he retaliated in kind (and he was in fact still
helpful by quoting the docs - thanks, I learned again something I never
wanted to know :-).

It is not uncommon for those who answer a lot of questions to sometimes
answer them in a very short manner. And it is in fact very demotivating,
if you try to help people in your free time and instead of thanking you,
they only complain that you aren't friendly enough, don't present them
the complete solution on a silver platter, etc.

Dawn, please try to develop a thicker hide. When you get an answer to a
question, focus on the content, not on the tone. The person who wrote
this may just have written it in a hurry, he (or she) may have had a bad
day, English may not be his native language, etc. There are a lot of
reasons why a posting may seem a lot more unfriendly than it was meant,
so try to stay calm even if the other person doesn't seem to be.

	hp

-- 
   _  | Peter J. Holzer    | Es war nicht Gegenstand der Abstimmung zu

| |   | hjp### [at] wsracat      | Zahlen neu festzulegen.
__/   | http://www.hjp.at/ |	-- Johannes Schwenke <jby### [at] ginkode>

Post a reply to this message

On Sat, 02 Dec 2000 20:41:56 -0700, Dawn McKnight wrote:
>it.  In general, POV-Ray has the finest official documentation I am aware of in
>any open-source program.

For the record, POV-Ray is not Open Source.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Sun, 3 Dec 2000 17:37:24 +0100, hjp### [at] SiKituwsracat (Peter
J. Holzer) wrote:

>Dawn, please try to develop a thicker hide. When you get an answer to a
>question, focus on the content, not on the tone. The person who wrote
>this may just have written it in a hurry, he (or she) may have had a bad
>day, English may not be his native language, etc. There are a lot of
>reasons why a posting may seem a lot more unfriendly than it was meant,
>so try to stay calm even if the other person doesn't seem to be.

Also, the person responding may be a developer who is also writing the
docs for whatever he is developing. Thorsten is the POV Team's Mac guy
and I think he also wrote the Mac specific docs. There's nothing more
easily irritated that a developer who has to RTFM users about his own
docs. And it happens to everyone once in a while. I hope I won't get
dealt with in any physically uncomfortable ways by letting it slip
that Chris Cason himself recently RTFMed the TAG! Dawn, if you're
reading this, please know -- you're not alone :)

Oh, and this is not a male-only zone. We even have another Dawn :))


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On 4 Dec 2000 14:50:30 -0500, Ron Parker wrote:
>On Sat, 02 Dec 2000 20:41:56 -0700, Dawn McKnight wrote:
>>it.  In general, POV-Ray has the finest official documentation I am aware of in
>>any open-source program.
>
>For the record, POV-Ray is not Open Source.

The definition of open source lists 9 criteria for Open Source software
(see http://www.opensource.org/osd.html for details):

1. Free Redistribution

    Povray meets this point only partially. The maximum price clause in
    the POV license may be seen as a violation of OSD. (But I think it
    is in the same spirit).
    
2. Source Code

    Ok.

3. Derived Works

    Povray puts severe limitations on derived works. A partial match at
    best, although again it fits the rationale for the criterium.

4. Integrity of The Author's Source Code

    Ok.

5. No Discrimination Against Persons or Groups.

    Ok

6.  No Discrimination Against Fields of Endeavor.

    Ok

7. Distribution of License.

    Ok

8. License Must Not Be Specific to a Product.

    Ok

9. License Must Not Contaminate Other Software.

    Ok.

So Povray matches 7 of 9 criteria for open source software fully, and
two partially. 

I will continue to think of Povray as Open Source Software.

	hp

-- 
   _  | Peter J. Holzer    | Es war nicht Gegenstand der Abstimmung zu

| |   | hjp### [at] wsracat      | Zahlen neu festzulegen.
__/   | http://www.hjp.at/ |	-- Johannes Schwenke <jby### [at] ginkode>

Post a reply to this message