Normals appear to have an inherent directional bias independent of 
pattern.  To eliminate as a variable any bias in a built-in pattern, I 
used an explicit normal function.  The two images should be mirror 
images of each other, but they are not.  The bias shows in all versions 
from 3.5 to 3.8.

----------[BEGIN CODE]----------
// +KFF2
#version max (3.5, min (3.8, version));

global_settings { assumed_gamma 1 }

light_source { <(frame_number = 2? 1: -1), 1, -1.4> * 1000, rgb 1 }

camera
{ location -6 * z
   right x
   angle 30
}

box
{ 0, 3
   pigment { rgb <1, 0.5, 0.5> }
   normal
   { function
     { max
       ( select (x - 1, 1, select (x - 2, 0, 1)),
         select (y - 1, 1, select (y - 2, 0, 1))
       )
     }
     accuracy 0.1
   }
   translate <-1.5, -1.5, 0>
}
-----------[END CODE]-----------

Post a reply to this message

Attachments:
Download 'normal_bias1.png' (2 KB) Download 'normal_bias2.png' (2 KB)

Preview of image 'normal_bias1.png'

Preview of image 'normal_bias2.png'

On 1/5/21 12:50 PM, Cousin Ricky wrote:
> Normals appear to have an inherent directional bias independent of 
> pattern. 
...

This is something I noticed and discussed some privately with Bald Eagle 
while working on the quilted et al normal only patterns.

The method used for creating the normal from scalar function/pattern 
values uses samples (4) and the sampling has a directional bias. This 
bias does not necessarily exist with true normal perturbation. "Normal 
perturbation based upon scalar value functions and patterns have a 
directional bias."

A similar sampling method is used to create isosurface normals but there 
- usually - the code runs at the surface intersection and due the local 
"shape" values the simpler 3 delta sampling mostly works(1).

(1)- There are still possible issues. If the function/shape is set up 
with a constant or near constant value range on one side or the 
transition through the local 0 value root. Where the three axis 
gradients are significantly different or all nearly the same is another. 
If you run f_normal at a local change in value direction off the surface 
- the sphere origin being an example - you tend to get the a form of the 
sampling bias as the normal.

Aside: I have planned a new special pattern called "access" for pulling 
out both the raw and perturbed surface normals (perhaps more) so I can 
look at what is happening with scalar value calculated normal 
perturbation in more detail.

Aside: Related to above I already change povr's aoi pattern to return a 
full -1 to +1 range of values relative to the incoming rays. This lets 
me set up different colors for positive and negative map values so I can 
see by rendered color where perturbed normal inversions happen - where 
the bump value is large enough to flip the primary direction relative 
the incoming ray.

Aside: As you know, the magnitude of the perturbation values play a roll 
too with whether or not raw normals invert in part or in total when 
perturbed.

Aside: A reason povr is dropping scalar value based normal perturbation 
methods where a custom normal perturbation method exists is that, in 
addition to being more flexible, it's much easier to control / prevent 
normal perturbation inversions. This is a move away from v3.5 onward 
normal updates toward how earlier version of POV-Ray worked.

... There are many details with normal handling I still don't 
understand. Warps and those empty code hooks being one bit ...

Bill P.

Post a reply to this message

On 1/5/21 8:07 PM, William F Pokorny wrote:

> Aside: A reason povr is dropping scalar value based normal perturbation 
> methods where a custom normal perturbation method exists is that, in 
> addition to being more flexible, it's much easier to control / prevent 
> normal perturbation inversions. This is a move away from v3.5 onward 
> normal updates toward how earlier version of POV-Ray worked.
> 
> ... There are many details with normal handling I still don't 
> understand. Warps and those empty code hooks being one bit ...

It's been a while that I coded C and C++ but in general I consider 
myself a fair programmer (> 10 years professional experience) and would 
like to help, cause I need PovRay to live and improve ...but the 3D math 
is something my brain cannot handle well.

Not sure what to do here. I think I can easily get into C++ again, but 
such a large and math-heavy project like Povray sure will require some 
time to actually understand and being able to make meaningful patches.

Any suggestions what to do if I want to help?

> Bill P.

--
Hajo

Post a reply to this message

On 1/5/21 4:13 PM, Hj. Malthaner wrote:
> On 1/5/21 8:07 PM, William F Pokorny wrote:
> 
...
> 
> It's been a while that I coded C and C++ but in general I consider 
> myself a fair programmer (> 10 years professional experience) and would 
> like to help, cause I need PovRay to live and improve ...but the 3D math 
> is something my brain cannot handle well.
> 
> Not sure what to do here. I think I can easily get into C++ again, but 
> such a large and math-heavy project like Povray sure will require some 
> time to actually understand and being able to make meaningful patches.
> 
> Any suggestions what to do if I want to help?
...
 >
> -- 
> Hajo

Hi Hajo,

10+ years professional programming certainly makes you more of a real 
programmer than me. :-)  I've used POV-Ray a long time, but have only 
been digging into the source deeply since early 2016 (<4 years). And C++ 
I'm still very much learning.

As to how to contribute, I'm unsure. :-) Some thoughts.

---
The official v3.7-stable and v3.8 master (development) branches as they 
exist on github are without active programmer support. See:

https://github.com/POV-Ray/povray

Of late the Debian and macOS folks have taken it on themselves to patch 
/ change things in their space for POV-Ray v3.7.0.8 updates. There has 
not since Feb 19, 2019 been an official "POV-Ray team" release or 
pre-release.

A good candidate for this would be familiar with Windows, 
Linux/Unix/macOS environments - and git/github. Also with various 
compilers and build systems in addition to C++. Ultimately, whether 
anyone new is given github update authority would be up to Chris Cason.

---
On the linux/Unix/macOS side of things especially, several here offer 
releases for branches of one sort or another. Each branch I see as 
particularly focused. My povr effort is one of these and it breaks 
compatibility in more of a 'POV-Ray 4.0' way than do most others. Povr 
is also Linux/Unix based only. I don't use Windows day to day and I do 
not understand code development in the Windows environment.

Creating your own branches to play with existing options or to dig into 
some particular bug a way to start learning the code base. This a way to 
  to start smaller - it's how I started out.

---
If you might be interested in a stand alone tool for POV-Ray, one area 
where the linux/Unix/macOS side of things in lacking is there is no 
native PoseRay equivalent. Further PoseRay source code is not openly 
available for fixes/updates as far as I know even if one is OK running 
under wine, say.

There is too the stalled Moray development - Chris Cason is the owner of 
that software.

Bill P.

Post a reply to this message

On 1/6/21 3:48 PM, William F Pokorny wrote:
> On 1/5/21 4:13 PM, Hj. Malthaner wrote:

> The official v3.7-stable and v3.8 master (development) branches as they 
> exist on github are without active programmer support. See:

Yes, that is something that concerns me since a while. Years ago I had 
made a decision to stick with PovRay instead of switching to Blender and 
worked to create a library of models that will use in my sci-fi scenes.

Now it seems that I have made a bad decision. Blender with the Cycles 
Renderer delivers stunning real looking images. The old Blender renderer 
didn't seem to match PovRay but Cycles does and even surpasses.

But I don't want to give up yet.

> A good candidate for this would be familiar with Windows, 
> Linux/Unix/macOS environments - and git/github. Also with various 
> compilers and build systems in addition to C++. Ultimately, whether 
> anyone new is given github update authority would be up to Chris Cason.

I don't qualify here. I tried to build povray with MinGW under Windows 
and couldn't make it. Compiling under Linux worked pretty well instead. 
And since some years Linux is what I use in my free time.

We used git at work and I have two projects on Github but I'm definitely 
not an expert there. I just use it.

> On the linux/Unix/macOS side of things especially, several here offer 
> releases for branches of one sort or another. Each branch I see as 
> particularly focused. My povr effort is one of these and it breaks 
> compatibility in more of a 'POV-Ray 4.0' way than do most others. Povr 
> is also Linux/Unix based only. I don't use Windows day to day and I do 
> not understand code development in the Windows environment.

Seems to be a common problem, at least one that we two are sharing. What 
is the goal of Povr?

> Creating your own branches to play with existing options or to dig into 
> some particular bug a way to start learning the code base. This a way to 
>   to start smaller - it's how I started out.

I've noticed a bug with media effects behind semi-transparent image maps 
on transparent objects. Not entirely sure if it's really a bug or if my 
combination of glass sheets and "holographic" displays was particularly 
stupid. I'd like to fix this problem but at the same time it seems to be 
something that is hard to fix cause it's not contained in one feature 
but appears due to interaction of different features.

Maybe time to make a new thread in the programming group and see what 
other people think. I'm all new here. And the version that I compiled 
from the 3.8-master branch seems to have very few real bugs.

https://en.wikipedia.org/wiki/Path_tracing

I think this feature is what makes the Cycles renderer produce better 
images than PovRay with radiosity. It's the same idea as radiosity but 
more modern and advanced. But I definitely are not the one to actually 
put such into PovRay, knowing virtually nothing about the code and also 
about the math behind this.

-- 
Some of my PovRay works:
https://www.deviantart.com/antarasol/gallery/42758766/3D

Post a reply to this message

On 1/6/21 5:33 PM, Hj. Malthaner wrote:
> On 1/6/21 3:48 PM, William F Pokorny wrote:
...
> 
>> On the linux/Unix/macOS side of things especially, several here offer 
>> releases for branches of one sort or another. Each branch I see as 
>> particularly focused. My povr effort is one of these and it breaks 
>> compatibility in more of a 'POV-Ray 4.0' way than do most others. Povr 
>> is also Linux/Unix based only. I don't use Windows day to day and I do 
>> not understand code development in the Windows environment.
> 
> Seems to be a common problem, at least one that we two are sharing. 
...

Yep. It's good to remember efforts like Blender have paid core support 
for the - less interesting/fun - day to day development stuff. It's more 
common, I believe, that vital projects of some size have a small team 
where some know windows, others macOS, others web development, etc.

> What is the goal of Povr?

:-) I had to think some about the question! The povr branch happened due 
dead ends elsewhere with respect to what I needed. I'd say:

- Selfishly and foremost, a hobby which is fun.

- Initially, a simpler version of "POV-Ray" supporting the existing 
scene language and the most common features while fixing as many 
longstanding bugs (and broken features) as I can.

- Longer term, I have a list of wild ideas. If I can get to a simpler 
source platform while learning enough programming, I hope to be able to 
try some of the more involved ones. To be able to figure out which ideas 
are good and which are junk.

> 
...
> 
> I've noticed a bug with media effects behind semi-transparent image maps 
> on transparent objects. Not entirely sure if it's really a bug or if my 
> combination of glass sheets and "holographic" displays was ...

If you believe there's a bug in the current official release, the usual 
place starting post would be povray.bugreports. Or, povray.beta-test, if 
it a problem particular to v3.8 development. Either probably works out 
and cutting the issue down to as simple a scene as possible a great 
help.

Aside: I just noticed the http://news.povray.org/groups/ web page 
description for beta-test wrongly refers to the POV-Ray v3.7 SMP 
beta-test instead of v3.8.

> 
> https://en.wikipedia.org/wiki/Path_tracing
> 

I never know what to do with pointers to the latest and greatest - 
whatever. Usually some good to a particular approach, but different 
devils in the details. At a high level all approaches are faking real 
world effects to some degree.

Yes, if you set up the modeling in more of a real world way, and you 
crush the render with samples you get a very good looking render result. 
You also hide numerical sin in a way not unlike how POV-Ray's AA methods 
or focal blur tend to cover over problems beyond the intended aim of the 
AA.

> I think this feature is what makes the Cycles renderer produce better 
> images than PovRay with radiosity. 

Somewhat agree. One place where I believe POV-Ray comes up short is in 
handling finish highlights where radiosity, area lights and ??? are in play.

While I mostly kept a distance from the finish changes Christoph was 
working on for v3.8(1), I believe the aim for many of the changes - like 
always specifying an interior ior - was to better handle surface 
finishes (highlights especially) in a real world way. Expect others here 
know better than me the extent to which my belief is true?

(1) - Being more interested in shapes and actual surface treatments than 
faked ones.

I think mostly these v3.8 finish block changes haven't been exploited to 
date. If they more often were, would the highlight differences compared 
to Cycles (et al) be as dramatic? I don't know for certain, but I 
suspect less so.

Soapbox:

At some point what's seen as best or better - what becomes common - is 
just where the crowd of users ends up / happens to be. There is value in 
following; It's easier to grab detailed work of others in terms of code, 
models, materials, maps and such and stick it into your larger scene (or 
program or whatever). Further, it's more likely the things you grab work 
- at least in the main.

Bill P.

Post a reply to this message

On 1/7/21 5:29 PM, William F Pokorny wrote:
> On 1/6/21 5:33 PM, Hj. Malthaner wrote:
>> What is the goal of Povr?

[snip]

> - Initially, a simpler version of "POV-Ray" supporting the existing 
> scene language and the most common features while fixing as many 
> longstanding bugs (and broken features) as I can.

That's something I like. A simpler codebase is easier to understand, and 
maintain. Also should makes finding bugs easier.

>> I've noticed a bug with media effects behind semi-transparent image 
>> maps on transparent objects. Not entirely sure if it's really a bug or 
>> if my combination of glass sheets and "holographic" displays was ...
> 
> If you believe there's a bug in the current official release, the usual 
> place starting post would be povray.bugreports. Or, povray.beta-test, if 
> it a problem particular to v3.8 development. Either probably works out 
> and cutting the issue down to as simple a scene as possible a great help.

I'll do so once I have set up a scene file to reproduce the problem in a 
simple way ... or found out that I was stupid somewhere and the fault is 
mine. Right now It's too early to make an official report here.

>> https://en.wikipedia.org/wiki/Path_tracing
>>
> 
> I never know what to do with pointers to the latest and greatest - 
> whatever.

20 years is not so new, but yes ... the only reason to post was cause 
the Cycles renderer uses this and produces very good quality. I just 
wanted to make sure we both have the same state of knowledge.

>> I think this feature is what makes the Cycles renderer produce better 
>> images than PovRay with radiosity. 
> 
> Somewhat agree. One place where I believe POV-Ray comes up short is in 
> handling finish highlights where radiosity, area lights and ??? are in 
> play.
> 
> While I mostly kept a distance from the finish changes Christoph was 
> working on for v3.8(1), I believe the aim for many of the changes - like 
> always specifying an interior ior - was to better handle surface 
> finishes (highlights especially) in a real world way. Expect others here 
> know better than me the extent to which my belief is true?

I must admit I know nothing about these changes, even that I use a 3.8 
alpha version.

> I think mostly these v3.8 finish block changes haven't been exploited to 
> date. If they more often were, would the highlight differences compared 
> to Cycles (et al) be as dramatic? I don't know for certain, but I 
> suspect less so.

For sure I have not, cause I didn't even know about them. I'm still 
using what is documented for 3.6/3.7

I'll try to find some documentation about the finish related changes in 3.8

> At some point what's seen as best or better - what becomes common - is 
> just where the crowd of users ends up / happens to be. There is value in 
> following; It's easier to grab detailed work of others in terms of code, 
> models, materials, maps and such and stick it into your larger scene (or 
> program or whatever). Further, it's more likely the things you grab work 
> - at least in the main.

I agree. But while many change to Blender, this is why I asked how I can 
help. I'd hate to see PovRay die. It's been around so long and was one 
of the best free 3D programs for many years.

Since the last message I have been reading some parts of the code. The 
tracer core, texture handling, patterns, media. At the moment I think I 
could make some changes to patterns with some level of success. Some 
parts of the code, even in the patterns are very sophisticated (the 
algorithms, the code is still clean to read), and I don't think I could 
fix a problem there.

Now that you pointed me to the finish changes, I'll take a look into 
that next.

> Bill P.

-- 
Hajo

Post a reply to this message

On 1/7/21 5:12 PM, Hj. Malthaner wrote:
> For sure I have not, cause I didn't even know about them. I'm still 
> using what is documented for 3.6/3.7
> 
> I'll try to find some documentation about the finish related changes in 3.8

http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary

Post a reply to this message

On 1/8/21 1:48 AM, Ash Holsenback wrote:
> On 1/7/21 5:12 PM, Hj. Malthaner wrote:
>> For sure I have not, cause I didn't even know about them. I'm still 
>> using what is documented for 3.6/3.7
>>
>> I'll try to find some documentation about the finish related changes 
>> in 3.8
> 
>
http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary

> 

Thank you. It seems the following two were the finish related changes 
mentioned earlier in the discussion ... did I miss some others?

* A new finish parameter use_alpha has been added to suppress highlights 
and reflections depending on pigment transparency
* Fresnel angle-dependent attenuation can now also be applied to 
highlights and the diffuse component for more physical realism

The use_alpha looks useful indeed. So far I gave highly transparent 
glass very little specular highlights to avoid the problem.

I'm not sure how to make good use of the second point though?

-- 
Hajo

Post a reply to this message