In article <3e640d5c@news.povray.org>,
 Xplo Eristotle <xpl### [at] infomagicnet> wrote:

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

But contains unnecessary text, which makes the message longer and some 
problems harder to find. It would have taken practically no effort to 
trim it to minimum. Asking for this in future messages is perfectly 
reasonable, providing an example is even better.


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

No, you should apologize for the unreasonable insults you have piled on 
him in response to a helpful hint.


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

Did you test it to make sure?


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

How many people would test it in the official version if it had this 
line:
#version unofficial MegaPov 1.0;
at the beginning?
I suspect this behavior exists in the official version as well, but that 
doesn't matter, it still needs to be verified. Your example did not 
require MegaPOV, and should not have used it for the test. This part not 
only was unnecessary, it was wrong.


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

The code he posted, proposing an alternative, with the point being to 
make it easier on others. Certainly nothing that deserved your response.


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

Ok...you have been abusive and insulting to Warp in this entire thread. 
His original message could have been better worded, but it didn't 
deserve anything like the response it got. The first reply could have 
been excused as a misunderstanding on a bad day, but this is way beyond 
that. Please end this now.


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

Being confirmed and documented does not mean the cause has been found 
and a fix written. In addition, there are many other things to be done, 
and remember that the POV Team and TAG are doing this in their spare 
time, for free. Don't expect your pet bugs to be at the top of the list.

-- 
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:
> 
> But contains unnecessary text, which makes the message longer and some 
> problems harder to find.

There ARE no problems to find in the code. It was not provided for the 
purposes of analysis. If I had inserted the text of War and Peace as a 
huge comment it wouldn't have made any difference. (Well, okay, it would 
have made the post enormous, but that's not my point.)

If you want me to take your position seriously, you're going to have to 
stop arguing from blind principle and accept that seven lines doesn't 
make much difference either way, and furthermore, didn't make the scene 
confusing. Of course, if you accept that, then it completely undermines 
your position anyway.

>>It would only matter if the bug only existed in the unofficial version. 
> 
> Did you test it to make sure?

Due to one of the aforementioned unresolved crashing bugs, I do not 
attempt to run the official version.

> Being confirmed and documented does not mean the cause has been found 
> and a fix written.

Thorsten blames Apple, as I recall. I find this curious, as he appears 
to be the only Mac developer in the world who can't make an Open dialog 
work; one would assume that if there was a problem at the OS level, it 
would affect everybody. However, since I'm unfamiliar with the source 
code and the API, I will say no more about it here.

-Xplo

Post a reply to this message

Xplo Eristotle's furious key-hammering produced this:
>> 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.

Making things difficult for others is not a good way of getting help.  Other
people have renderings of their own to do, y'know. :)

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

While I think Warp was a little out of line in his wording, you were much worse
overall.  There is absolutely *no* reason to insult people like you did to Warp
and to use the kind of language that you did a few posts back.  Don't be so
ignorant -- did it even occur to you that some people get offended by such
language?  Didn't think so.

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

No, some of your responses were way out of line.  If you would have read the
acceptable use policy you would have known that.

http://tag.povray.org/aup.html -- exerpt quoted from item 3:

"Users of this news server may not post messages that could reasonably be
expected, by today's standards, to cause another reasonable person to not want
to use or visit this server due to a feeling of harassment. Personal attacks,
that lead to insulting or abusive behavior, are not an acceptable activity on
this news server. Likewise the use of profanity is also considered
unacceptable."

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

Well, maybe if you would treat established members of this community a little
better you would get an answer, m'kay?

Also, since you seemed to completely *ignore* the fact that Chris set follow-ups
to povray.off-topic (since this discussion does not relate to POV-Ray at all
anymore) I'll set it again.  Please abide by it this time!

-- 
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"

Post a reply to this message

On Sat, 01 Mar 2003 20:41:21 -0700 Xplo Eristotle wrote:

>// Test scene demonstrating apparent improper normal averaging.

  I'm not paying much attention to the other goings-on in the thread,
mostly because I don't have enough time to read all that and do
everything else I need to do after I get home from work.

  I think your test scene was fine.  I commented out the #version line
before rendering.  The resulting image shows demonstrates the question
you were asking about normal averaging.  Unfortunately, I don't know
*why* it appears that way but I wanted you to know that I did look at it
the day after you posted the test scene.

  I hope that everyone will have their say (preferably in p.off-topic)
about the other 'issues', and then continue on with why we're here in
the first place.

-- 
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g

Post a reply to this message

Xplo Eristotle wrote:
> 
> 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.
> 
> Thank you, Kari.
> 
> I'm not sure I'd call the results of the averaging a "small residue",
> though. There are some fairly deep bumps and pockmarks; it looks a
> little like the surface of a wooden baseball bat that's been used to hit
> rocks and pieces of metal junk.. like the dents normal, but messier.
> 
> I'll post a pic in p.b.i., since the usually-reasonable Warp seems to
> think that my code is a nightmare. 9_9
> 
> -Xplo

If you change the scene and use boxes with crackle normal the effect is
a bit less obvious, but easier to trace.
Here's the code I used:
{as part of a game of Truth and Dare}

#default { texture { pigment { color rgb <1, 0, 0> } finish { diffuse 1
ambient 0 } } }

camera{
  location <0, 2, -15>
  look_at <0, 0, 0>
  angle 20
}
        
light_source{<-10, 100, -100> rgb 1}         

box{-.8,.8
  normal{crackle 1 scale 1}
  finish { specular 1 }
  translate <-1,1,0>
}
box{-.8,.8
  normal{crackle -1 scale 1}
  finish { specular 1 }
  translate <1,1,0>
}
box{-.8,.8
  normal{
    average
    normal_map{
      [ crackle 1 scale 1 ]
      [ crackle -1 scale 1]
    }
  }
  finish { specular 1 }
  translate <0,-1,0>
}

Anyway, the ridges stand out a bit as do the parts that are particularly
light or dark. 
Someone with a bit of understanding of the POV-code might be able to
explain.

Remco

Post a reply to this message

> I was playing around with layered textures today, and on a whim, I 
> decided to see what would happen if I averaged two opposed normals 
> together.
> I assumed that they would completely cancel out.. but instead, they 
> produced a weird, not exactly granite-like normal that's quite noticible.> 
 >
> Why is this?

Just a guess: The length of the normal vector is irrelevant, only the
direction counts. Numerically the normals you get are not zero but
will have a "random" direction.

Manual 6.7.11.2:
The perturbed normals are then weighted, added and _normalized_.


-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

On 2 Mar 2003 19:14:05 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  It's not the code which is specially problematic. His attitude about my
>comments is what made me lose my temper. He basically called me stupid.

Knowing you, you'd hate the most to be called stupid, but thinking
about it, he only called you an a*****e and stuff like that :) So, no
hurt feelings, hehehe :))

(sorry, couldn't resist)


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

Post a reply to this message