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.

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

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?

Incidentally, the same problem exists if you average the normals as 
textures (in a texture map), although the resulting normal looks 
somewhat different.

-Xplo

Post a reply to this message

(Btw, it would be nice if you would make a complete rendable scene
showing the phenomenon so that people can simply copy-paste it to povray,
render it and quickly see what you are talking about instead of having to
set up a scene.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
>   (Btw, it would be nice if you would make a complete rendable scene
> showing the phenomenon so that people can simply copy-paste it to povray,
> render it and quickly see what you are talking about instead of having to
> set up a scene.)

I was trying to keep my post relatively short, but you have a point. 
Sorry. ^^;;

-Xplo

Post a reply to this message

On Fri, 28 Feb 2003 15:31:51 -0700 Xplo Eristotle wrote:

>I was trying to keep my post relatively short, but you have a point. 
>Sorry. ^^;;

  We appreciate the effort to keep posts short, but Warp is right -
personally, I'm not likely to test an incomplete scene if I have to set
up a camera and lighting.  Additionally, with some scenes it might make
a difference when trying to reproduce what *you* are seeing.  Can you
please post (in reply) a more complete scene so we can see what you see
after rendering?

  Thanks.

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

// Test scene demonstrating apparent improper normal averaging.

#version unofficial MegaPov 1.0;
#default { texture { pigment { color rgb <1, 0, 0> } finish { diffuse 1 
ambient 0 } } }

global_settings
	{
	assumed_gamma 1.0
	}

camera
	{
	look_at <2, 1, 0>
	location <2, 10, -10>
	angle 15
	}
	
light_source
	{
	<0, 100, 0>
	rgb 1
	}
	
sphere
	{
	<2, 1, 0> 1
	normal
		{
		average
		normal_map
			{
			[ granite 1 scale 1 ]
			[ granite -1 scale 1 ]
			}
		}
	finish { specular 1 }
	}

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> #version unofficial MegaPov 1.0;

  Argh!

  And why all the unneeded whitespace bloating the code?
  How about this:

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

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


-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> 
>>#version unofficial MegaPov 1.0;
> 
> 
>   Argh!

Yes! Argh! God forbid I should use MegaPOV, which probably reuses 99% of 
the official code. Quick, get the burning splints! 9_9;

>   And why all the unneeded whitespace bloating the code?

Bite me, Warp. I wanted to know if this was a bug, and if not, why not.. 
not to get a critique on my coding style. You wanted a scene, you got a 
scene. Copy, paste, render, nod your head and tell me WTF is going on.

Sheesh.

-Xplo

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> Yes! Argh! God forbid I should use MegaPOV, which probably reuses 99% of 
> the official code. Quick, get the burning splints! 9_9;

  It's not about you using MegaPov. It's about you posting an example
code which does not work in POV-Ray without the user needing to edit it.
(And there wasn't even any reason for using that #version directive at all
in the first place.)

> Bite me, Warp. I wanted to know if this was a bug, and if not, why not.. 
> not to get a critique on my coding style. You wanted a scene, you got a 
> scene. Copy, paste, render, nod your head and tell me WTF is going on.

  The idea of a "minimal" scene is that it should be short, and not only
in the number of keywords it uses. Naturally it should be clear and easy
to read.
  A minimal scene means that you should remove everything that is not
necessary in order to show the phenomenon you are talking about. Also
things that are absolutely necessary for the scene to be rendable, but
not pertinent to the phenomenon per se should take as less space as possible
so that they don't confuse the person who is looking at your code.
  The person viewing your code should be able to concentrate on the core
code which causes the phenomenon. Making secondary definitions (such as
camera and light source) take tens of lines is only unnecessary clutter
and does not help this task. If the problem is not related to cameras or
light sources, they could be simple one-liners. The larger your code is
because of unneeded definitions, linebreaks and whitespace, the harder
it will be for the person looking at your code to find the problem.

  "I code in this way and you should accept that" is not the correct attitude.
Of course you can code in whichever way you want and keep your scenes that
way, but when you are posting a small example scene for others to view,
you should make their task as easy as possible.
  The more work you do in order to make other's work easier, the better.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
>   It's not about you using MegaPov. It's about you posting an example
> code which does not work in POV-Ray without the user needing to edit it.

I'm sorry. Leaving out the top line in a block of text when making a 
selection must require more dexterity than I would have imagined.

>   The idea of a "minimal" scene is that it should be short, and not only
> in the number of keywords it uses. Naturally it should be clear and easy
> to read.

And as we all know, whitespace exists to make code harder to read.

>   "I code in this way and you should accept that" is not the correct attitude.

The hell it isn't. My code's not unreadable.

> Of course you can code in whichever way you want and keep your scenes that
> way, but when you are posting a small example scene for others to view,
> you should make their task as easy as possible.
>   The more work you do in order to make other's work easier, the better.

I guess copy and paste is too hard for you, Warp. I can only hope that 
someone who can demonstrate that they've mastered these most basic of 
text operations is willing to help explain this seeming bug.

Good lord, man. I just wanted an answer, not a fucking editorial about 
how incredibly petty and lazy you can be. Next time I find some 
anomalous behavior in POV-Ray I'll just keep it to myself.

-Xplo

Post a reply to this message

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.


_____________
Kari Kivisalo

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.

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

Post a reply to this message

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

> Yes! Argh! God forbid I should use MegaPOV, which probably reuses 99% of 
> the official code. Quick, get the burning splints! 9_9;

That doesn't mean the normal code is exactly the same. It would only 
take a very minor change to introduce a bug in MegaPOV. Besides, your 
scene does not require MegaPOV as far as I can see...you should have 
tested it in the official version and left that line out.

You included lots of other irrelevant stuff...#default, global_settings, 
etc. The idea of a minimal scene is that it includes only what is 
necessary. By breaking it down to the bare minimum, you not only keep 
the message short, but ensure that the problem is at least in the area 
you thought it was.

About the indentation issue, it is easier to copy and paste if the code 
is "compacted", and your indentation style is just the opposite, it 
can't get much longer or more spread out. It wasn't the real problem, 
though.

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

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> I'm sorry. Leaving out the top line in a block of text when making a 
> selection must require more dexterity than I would have imagined.

  Well, that's exactly what I'm talking about. You are cluttering your
scene with obsolete, unneeded definitions and assuming that the people
who want to look at your code will see the trouble to remove them because
you didn't want to do it yourself.

> And as we all know, whitespace exists to make code harder to read.

  When they clutter the scene, making secondary features of it to stand
out more than necessary, then yes, they make it harder to read.
  Did you even read what I said? The idea is that you should make the scene
minimal and help people concentrating on the *relevant* part of the code.
Making secondary, non-relevant parts of the code to exceedingly stand out
by making them to take lots of space does not help this task.

> The hell it isn't. My code's not unreadable.

  Where did I say that your code is unreadable?
  I said that you should *edit* your code before posting it. You should edit
it in such way that people don't need to edit it themselves if they want to
look at it. You should edit it in such way that the relevant part of the
code stands out and irrelevant secondary definitions don't.

> I guess copy and paste is too hard for you, Warp. I can only hope that 
> someone who can demonstrate that they've mastered these most basic of 
> text operations is willing to help explain this seeming bug.

> Good lord, man. I just wanted an answer, not a fucking editorial about 
> how incredibly petty and lazy you can be. Next time I find some 
> anomalous behavior in POV-Ray I'll just keep it to myself.

  Why do you keep talking about copying and pasting?

  And you are still showing the wrong attitude: You are expecting others
to edit your code and to interpret which parts are relevant and which aren't.
  That was exactly my point: You should see the trouble yourself, not
expect others to do it for you. It's not as bad as it could be (like those
who post a code thoushands of lines long and expect people to find one
buggy line in it), but IMHO you still showed an attitude which is not the
best possible.
  If you want answers, the correct attitude is not "here's some code I
quickly put together with a patched version and if you don't understand it
or can't edit it to work, then just fuck off".

  I did not criticize your coding style. I did not criticize your indentation
scheme. I did not criticize your choise of patched POV-Ray. I did not claim
that your example is not readable. So please stop claiming I did.
  I simply said that it's polite to see the trouble *yourself* in making
the scene as easy to use as possible, not expecting other people to do it
for you.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
 >
>   And you are still showing the wrong attitude: You are expecting others
> to edit your code and to interpret which parts are relevant and which aren't.

No, I'm not.

I gave you the relevant piece of code in the first place, as well as a 
description of exactly what I was doing, and what the problem was. I 
don't think I could have been more clear. You and others complained 
about having to set up a test scene which might be different from mine, 
and realizing that this was a valid objection, I cut down the scene that 
had the problem to a viable test scene, and posted that.

It requires no editing, unless you wish to take out the version line 
(which is easily done, and obvious), or the global settings, which I 
seriously doubt are causing the "bug", and would not prevent the scene 
from rendering anyway. You wanted something that could be rendered with 
no thought or effort on your part, and I delivered.

>   I simply said that it's polite to see the trouble *yourself* in making
> the scene as easy to use as possible, not expecting other people to do it
> for you.

The only thing I "expect" anyone to do is to tell me whether it's a bug 
when two opposite normals are averaged together and produce a third, 
clearly visible normal instead of cancelling each other out, and if not, 
why not. The only reason I provided the code in the first place was so 
you could see exactly what I'm doing, and thereby confirm that the 
problem really exists and it's not just some incredibly stupid oversight 
on my part.

If you can't be bothered to try to help, then DON'T REPLY. Waste your 
free time on something else and let someone else take care of it. But 
don't sit here and lecture me over such trivial shit.

Of the four people who have replied to this thread (not counting me), 
only one has even TRIED to offer some useful explanation for my finding. 
So, again, thank you Kari for trying to help. The rest of you ought to 
be ashamed of yourselves.

-Xplo

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e61f64d@news.povray.org...
> Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> > #version unofficial MegaPov 1.0;
>
>   Argh!
>
>   And why all the unneeded whitespace bloating the code?
>   How about this:

      Warp, I have to agree with xplo, his reposted code was fine in
any pov laymans' terms - I cut and pasted it and got the desired
render - no problem, it was simple.

    I really don't see the problem with it, he did what was asked, and
as a user on this server, it was adequate for me, and that's sayin'
somethin'!

      ~Steve~


>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N
color_map{[0rgb x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end
M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// 
- Warp -

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> If you can't be bothered to try to help, then DON'T REPLY.

  Do you really think you will get wholehearted help with that attitude?

> The rest of you ought to be ashamed of yourselves.

  Why?
  When I ask you to post a short, minimized and clean scene which shows
the phenomenon you are talking about, and then I explain myself what I
mean by minimal, you start insulting me.
  You still refuse to understand (or admit you understand) what I'm talking
about, but instead you keep making more or less direct insinuations about
me being stupid.
  I said that if you want help from people, it's good and polite to see
some trouble in making it the easiest possible for the people to study
your code and not expect people editing and understanding your code.
I also said that if you want help from people, you shouldn't start
depreciating their intelligence and insulting them. Your response to this
is basically "if you don't want to do it, fuck off".
  And lastly, when I show you how I think the code is at its minimum and
most clear shape, you don't even bother to comment it, why it's good/bad
and whether I, in your opinion, am right or wrong about it. (Instead you
start attacking me.)

  So why is it me who should be ashamed of myself?
  It wasn't me who started insulting and name-calling.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

St. <dot### [at] dotcom> wrote:
>       Warp, I have to agree with xplo, his reposted code was fine in
> any pov laymans' terms - I cut and pasted it and got the desired
> render - no problem, it was simple.

  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.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e629e4d@news.povray.org...
> St. <dot### [at] dotcom> wrote:
> >       Warp, I have to agree with xplo, his reposted code was fine
in
> > any pov laymans' terms - I cut and pasted it and got the desired
> > render - no problem, it was simple.
>
>   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.

   No, I don't think 'stupid' was intended. It could simply have been
because more bandwidth was wasted explaining what to do with the code
than should have originally been wasted. You give valuable advice many
times Warp, which is very much appreciated by myself and doubtless
others, but it was a molehill, and then a mountain for no real reason.

   Let's all have a cup of hot chocolate...  ;)

    ~Steve~

>
> --
> #macro N(D)#if(D>99)cylinder{M()#local
D=div(D,104);M().5,2pigment{rgb M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
>
(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

Warp wrote:
> 
>   When I ask you to post a short, minimized and clean scene which shows
> the phenomenon you are talking about, and then I explain myself what I
> mean by minimal, you start insulting me.

Let me recap for you. I know it's hard to understand what's happening 
with your head up your ass.

Xplo: "I decided to see what would happen if I averaged two opposed 
normals together." (example code follows) "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?"

Warp: "Btw, it would be nice if you would make a complete rendable (sic) 
scene showing the phenomenon so that people can simply copy-paste it to 
povray, render it and quickly see what you are talking about instead of 
having to set up a scene."

This is a reasonable request, so I provide exactly what you asked for: a 
complete renderable scene showing the phenomenon so that people can 
simply copy-paste it to povray, render it and quickly see what I'm 
talking about.

The smart and reasonable thing for you to do, at this point, would be to 
answer my question, if your knowledge makes you capable of doing so. I 
have provided everything you could possibly need to understand what I'm 
talking about, including a complete test scene that shows exactly what 
I'm talking about in considerable detail.

You didn't do the smart and reasonable thing.

I didn't ask you to fix my code, I didn't need you to fix my code, I 
didn't *want* you to fix my code, and I found your condescending and 
totally useless response insulting. I had absolutely no interest in 
comparing and discussing our coding styles, which, despite your denials, 
is essentially what you were talking about. What I wanted was an answer 
to my question.. something you made no attempt to provide.

>   I said that if you want help from people, it's good and polite to see
> some trouble in making it the easiest possible for the people to study
> your code and not expect people editing and understanding your code.

Warp, there's like 30 lines there.. and that's with my generous use of 
whitespace. There are POV-Ray tutorials which are more difficult to 
understand than my code, and it renders AS WRITTEN. I gave you exactly 
what you asked for. Not only that, but my original post explained 
*exactly* what was going on.

I find it strange that you object to my insults, considering the lengths 
you've gone to to deserve them.

-Xplo

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> What I wanted was an answer 
> to my question.. something you made no attempt to provide.

  You still don't get it, do you?

  You want an answer, but with that attitude of yours it's less likely that
you are going to get one. Insulting people who are trying to help you is
not the right way of getting answers.

  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.
  Which one of these two things is more likely to help the original poster
to get a proper answer?

  Some people might find it insulting if someone corrects their grammatical
errors. However, getting pissed off and starting insulting is not the correct
way of getting what they want.

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

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