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