"Warp" <war### [at] tagpovrayorg> wrote:
>
>   Compare it to this: Someone asks a question with a really bad
> English grammar. Someone corrects his grammar errors and says
> that if he uses proper English it's more likely that people will
> understand him and give a proper answer. Now, two things
> may follow:
>   1. The original poster thanks this person and learns
>   something useful.
>   2. The original poster tells this person to fuck off and mind
>   his own business.

It took me ages before my US colleagues understood that when I ask to
correct me when I make spelling or pronunciation mistakes I really mean it.
They simply could not believe it, because that is generally considered an
insult.

So when "someone corrects his grammar", and that was not asked for, good
deal of people would argue that he insults the one who has asked a question.
Too bad you are not aware of that fact.

Now let's have a look at what, and how, you "corrected"... This time you,
again, ran straight into the area of personal preferences (just as you did
when we were discussing C++ type casts), and yet you use sentences like
"unneeded whitespace bloating the code", which clearly implies that your
"opponent" did something wrong. Consider these three *facts* (I stress,
facts):

1) If Xplo's code would have a bit *more* spaces (specifically, at the
beginnings of the lines w/o braces), his code would be much closer to
so-called "fully bracketed syntax" than yours.

2) The "fully bracketed syntax" is what POV-Ray sources follow, mostly.

3) There are approximately as many proponents of that syntax as opponents.
I, personally, like it very much. But I also know those who say that POV-Ray
is written by lamers (and this is based solely on the syntax rules it more
or less follow).

Did you get the idea?

By the way, I'm now ranting, I am speaking as a mentor, and I do realize
that. But I do so for a purpose... I would like to ask you, Warp et al.: how
does it feel when someone talks to you like that?

Post a reply to this message

There seems to be a misunderstanding here.

  I'm not talking about how people should *usually* code, or how they should
indent their code when posting entire scenes (eg. to povray.text.scene-files).
You are talking as if I had asked him to change his coding style.
  This is not true. I did not ask him to change anything in his coding style.

  What I did suggest is that when *asking a question* related to some
POV-Ray feature, a minimal, yet complete piece of SDL code showing the
problem should be posted along with the question, and moreover, *this
specific code* (not the poster's usual code, but this specific code
related to this question) should be edited so that the *relevant* part
of the code stands out, and irrelevant parts are kept as secondary in
shape so that they don't stand out (eg. by making them one-liners).

  I repeat once again: I did not ask him to change his usual coding style nor
expressed any opinion about it.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> 
>   This is not true. I did not ask him to change anything in his coding style.

That's true, Warp. You didn't ask. You just took it upon yourself to 
revise my code, because it was "bloated" with "unnecessary whitespace".

>   What I did suggest is that when *asking a question* related to some
> POV-Ray feature, a minimal, yet complete piece of SDL code showing the
> problem should be posted along with the question...

Which is what I did, jackass.

The original code was a mishmash of objects, declared textures, notes to 
myself, and a lot of other junk. I cut it down to one camera, one light 
source, and one object with one texture. Oh, so I left in seven lines of 
directives and global settings. BIG FUCKING DEAL.

If you'd just answered my question in the first damn place, I wouldn't 
have this attitude. You'll note I've been perfectly civil to Kari, who 
had the sense to try and help instead of proving how "smart" he is by 
insulting my code and then pretending that it's for my own good somehow. 
Maybe if you hadn't been a useless, condescending asshole, I'd have been 
civil to you too.

You're the one who doesn't get it, Warp. I gave up hope that you would 
be of any use to me several posts back. When I said that I hoped someone 
would help me, I meant someone with the wit to say something relevant in 
  response to my question, and that obviously doesn't include you.

-Xplo

Post a reply to this message

"Xplo Eristotle" ha scritto 
: // Test scene demonstrating apparent improper normal averaging.
: 
: #version unofficial MegaPov 1.0;

...

: sphere
: {
: <2, 1, 0> 1
: normal
: {
: average
: normal_map
: {
: [ granite 1 scale 1 ]
: [ granite -1 scale 1 ]
: }
: }
: finish { specular 1 }
: }
: 

What does the fine manual say about normal_map? (6.7.2.2)
I'm talking of POV-Ray's manual ...


BTW I think Warp is correct, if you want that someone opens a debugger
and starts a debug session in search of a possible uninitialized variable, 
or an overflow/underflow, a typo... whatever it is. 
I think it is very kind of you to remove *ALL* parts surely not 
responsible of the wrong behaviour and then read the manual to be sure 
that what's left is correct.

Massimo

Post a reply to this message

Massimo Valentini wrote:
> 
> What does the fine manual say about normal_map? (6.7.2.2)

Nothing that would explain this phenomenon.

> BTW I think Warp is correct, if you want that someone opens a debugger
> and starts a debug session in search of a possible uninitialized variable, 
> or an overflow/underflow, a typo... whatever it is. 

He'd be correct, *if* that was what I wanted (although my scene was so 
small and simple that he has no right to complain, anyway. It'd be like 
debugging "hello world"). I provided the code so that people could 
render it and see the averaging bug I was talking about, as well as 
being able to verify that I'm not doing anything stupid (such as 
applying the normal to a bumpy isosurface), not so it could be analyzed 
for hidden flaws. The flaw is in the software, not the scene.

-Xplo

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
>>   What I did suggest is that when *asking a question* related to some
>> POV-Ray feature, a minimal, yet complete piece of SDL code showing the
>> problem should be posted along with the question...

> Which is what I did, jackass.

  And in your opinion it's me who should be ashamed of myself?
  Regardless of your insults and name-calling, I haven't responded back
in the same way. I have simply tried to explain myself. Have you even tried
to understand? You probably do understand, but you simply refuse to admit
it because you don't want to agree with me in anything.

> The original code was a mishmash of objects, declared textures, notes to 
> myself, and a lot of other junk. I cut it down to one camera, one light 
> source, and one object with one texture. Oh, so I left in seven lines of 
> directives and global settings. BIG FUCKING DEAL.

  Now you contradict yourself. First you claim that your code was minimal
("which is what I did"), and now you admit that it had seven lines of
irrelevant code. Which is it?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> 
>   And in your opinion it's me who should be ashamed of myself?

I like bagels, but not lox.

>   Now you contradict yourself. First you claim that your code was minimal
> ("which is what I did"), and now you admit that it had seven lines of
> irrelevant code. Which is it?

*ahem*

 >> Oh, so I left in seven lines of
 >> directives and global settings. BIG FUCKING DEAL.

It's pretty sad when you ask questions that I can best answer by quoting 
the post to which you're replying.

Tell me, Warp, did my initial post leave you with any doubt regarding 
the phenomenon I was describing? Did you really have as much trouble 
understanding my test scene as you imply? Did those seven lines of code 
(one of which was somewhat useful in the scene, one of which was blank, 
and two of which were braces) really leave you so confused that you 
couldn't paste the scene into POV-Ray and render it?

In short, are any of your objections practical?

If the answer is yes, then you're an idiot. If the answer is no, then 
you're an asshole.

I see no reason to stop "insulting" you, since that would be lying by 
omission, but feel free to let me know which term I should apply to you 
in the future.

-Xplo

Post a reply to this message

Jeez, stop this, both of you!
Xplo, you did not post a minimal scene, you left several useless bits in 
when by your own statements it would have been simple to only copy-paste 
the needed portion, and you did not mention you were using an unofficial 
version, which *does* matter. Warp made a simple suggestion, and you 
responded with "Bite me, Warp.", which was entirely unexpected and 
unjustified.

Looking back at the thread, the whole thing is a ridiculous string of 
overreactions, mainly on your part. Please drop the nasty attitude and 
insults, and let this thread die.

Followup-To set to povray.off-topic.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>
> Xplo, you did not post a minimal scene...

Fine. By the strictest technical definition, it was not a minimal scene.

So what? Why should I care? Why should *you* care? The code had one and 
only one purpose: to be pasted into POV-Ray and rendered so that the 
resulting image can be observed. It fulfills this purpose, therefore 
there's nothing wrong with it.

Should I apologize for not realizing that people here would be so anal 
as to complain about a fifth of the content of 35 lines of code?

 > you did not mention you were using an unofficial
> version, which *does* matter.

It would only matter if the bug only existed in the unofficial version. 
Had that been the case, the number of people saying "huh? I don't see 
this" would have shown it to be so, and it would still be valuable 
information, given MegaPOV's popularity and the fact that patches tend 
to find their way into official code.

For all I knew, the phenomenon had a perfectly valid explanation and 
would not be considered a bug, in the same way that limits on magnitude 
of scale have a perfectly valid explanation and are not considered a 
bug.. which is why I phrased my initial post as a question ("what's 
going on?") as opposed to a bug report ("found in version X, running 
under OS Y on hardware Z").

> Warp made a simple suggestion...

He did?

"Argh! And why all the unneeded whitespace bloating the code?"

Could you please point out which part was the suggestion? All I see is 
pointless bitching and criticism.

 > and you
> responded with "Bite me, Warp.", which was entirely unexpected and 
> unjustified.

I beg to differ with your analysis, sir. It was his criticism that was 
entirely unexpected and unjustified. My response was perfectly natural.

I'm sorry to see that you're taking his side here. I would have expected 
more from the "helpful POV community" than this.. especially given that 
the question of whether this is a bug in POV-Ray apparently remains 
unresolved.

(Then again, I can think of two other bugs in POV-Ray that have gone 
unresolved for some time now, both of which cause crashes and one of 
which is confirmed and documented. I guess I'd better learn C if I want 
any hope of seeing them fixed.)

-Xplo

Post a reply to this message

Kari Kivisalo wrote:
> The method of calculating the normal vector from the scalar
> field may not be precise. Averaging these vectors would leave
> a small residue or error. This is purely a guess based on the
> existence of accuracy keyword for normals.

Increasing the accuracy (that is, making the number smaller) actually 
makes the problem worse. Decreasing it helps to smooth out the results, 
but only inasmuch as decreased accuracy smoothes out *any* normal.

The only sensible explanation I can think of would be if negative normal 
values somehow transform the normal, thereby causing two unrelated sets 
of numbers to be averaged.. but I can't imagine why this would be the 
case. (Besides, translating one of the normals by 100 units creates an 
entirely different effect.)

-Xplo

Post a reply to this message