This scene file looks different depending on whether you use official 
POV-Ray or UberPOV:

----------------------[BEGIN CODE]----------------------
// +w496 +h248
#version 3.6;

global_settings { assumed_gamma 1 }

#default { finish { diffuse 0.6 ambient rgb 0.16041 } }

light_source
{ <-3.3125, 7.6250, -5.7374>,
   rgb 4045.5
   fade_power 2 fade_distance 0.10417
   spotlight point_at <0, 1, 0> radius 45 falloff 90
}

camera
{ location <0, 1, -5.6713>
   look_at <0, 1, 0>
   right 2 * x
   up y
   angle 55.7560
}

box
{ -<7, 9, 7>, <7, 9, 7>
   pigment { rgb 1 }
}

plane
{ y, 0
   pigment { checker rgb 0.05 rgb 1 }
}

#declare fn_Hills = function
{ pigment
   { bumps warp { turbulence 0.5 }
     scale 0.3
   }
}

height_field
{ function 100, 100 { fn_Hills (x, y, z).red }
   translate <-0.5, 0, -0.5>
   scale <4, 1, 4>
   pigment { green 0.5 }
}
-----------------------[END CODE]-----------------------

Image uberhills-v36.jpg was rendered with POV-Ray 3.6.1.

Image uberhills-v37.jpg was rendered with POV-Ray 3.7.0.0.

Image uberhills-uber.jpg was rendered with UberPOV 1.37.1.0-beta.10.

When I tried using a regular (non-pigment) function, there was no 
difference between UberPOV and official POV-Ray.  I am running openSUSE 
13.2 (GNU/Linux) on an Intel Core i7 (quad core).

Post a reply to this message

Attachments:
Download 'uberhills-v36.jpg' (18 KB) Download 'uberhills-v37.jpg' (20 KB) Download 'uberhills-uber.jpg' (21 KB)

Preview of image 'uberhills-v36.jpg'

Preview of image 'uberhills-v37.jpg'

Preview of image 'uberhills-uber.jpg'

Am 28.06.2015 um 21:11 schrieb Cousin Ricky:

> Image uberhills-v36.jpg was rendered with POV-Ray 3.6.1.
>
> Image uberhills-v37.jpg was rendered with POV-Ray 3.7.0.0.
>
> Image uberhills-uber.jpg was rendered with UberPOV 1.37.1.0-beta.10.
>
> When I tried using a regular (non-pigment) function, there was no
> difference between UberPOV and official POV-Ray.  I am running openSUSE
> 13.2 (GNU/Linux) on an Intel Core i7 (quad core).

I'll have to investigate what's happening there; might be an error in 
the default colour map for the bumps pattern, might be something else.

In the meantime, could you do me a favor and test it with a POV-Ray 
3.7.1 development build, to see if the error is in the POV-Ray proper 
codebase or the UberPOV modifications?

Thanks a lot.

Post a reply to this message

On 2015-06-29 09:04 AM (-4), clipka wrote:
> In the meantime, could you do me a favor and test it with a POV-Ray
> 3.7.1 development build, to see if the error is in the POV-Ray proper
> codebase or the UberPOV modifications?

Well, now you've given me an excuse to do some beta testing of the alpha.

It's in 3.7.1.

Post a reply to this message

Attachments:
Download 'uberhills-v371.jpg' (21 KB)

Preview of image 'uberhills-v371.jpg'

Am 28.06.2015 um 21:11 schrieb Cousin Ricky:

> Image uberhills-v36.jpg was rendered with POV-Ray 3.6.1.
>
> Image uberhills-v37.jpg was rendered with POV-Ray 3.7.0.0.
>
> Image uberhills-uber.jpg was rendered with UberPOV 1.37.1.0-beta.10.
>
> When I tried using a regular (non-pigment) function, there was no
> difference between UberPOV and official POV-Ray.  I am running openSUSE
> 13.2 (GNU/Linux) on an Intel Core i7 (quad core).

I can confirm that this is a bug.

In a nutshell, POV-Ray defalts to the wrong noise generator during parsing.

The behaviour was broken by commit 35a20c2 (2014-06-13).

As a workaround, use "noise_generator 2" in the global settings.

Post a reply to this message

Am 30.06.2015 um 19:39 schrieb clipka:
> Am 28.06.2015 um 21:11 schrieb Cousin Ricky:
>
>> Image uberhills-v36.jpg was rendered with POV-Ray 3.6.1.
>>
>> Image uberhills-v37.jpg was rendered with POV-Ray 3.7.0.0.
>>
>> Image uberhills-uber.jpg was rendered with UberPOV 1.37.1.0-beta.10.
>>
>> When I tried using a regular (non-pigment) function, there was no
>> difference between UberPOV and official POV-Ray.  I am running openSUSE
>> 13.2 (GNU/Linux) on an Intel Core i7 (quad core).
>
> I can confirm that this is a bug.
>
> In a nutshell, POV-Ray defalts to the wrong noise generator during parsing.
>
> The behaviour was broken by commit 35a20c2 (2014-06-13).
>
> As a workaround, use "noise_generator 2" in the global settings.

A source file fix for POV-Ray proper is available now in the master 
branch at GitHub.

Post a reply to this message

On 2015-06-30 01:48 PM (-4), clipka wrote:
> Am 30.06.2015 um 19:39 schrieb clipka:
>> I can confirm that this is a bug.
>>
>> In a nutshell, POV-Ray defalts to the wrong noise generator during
>> parsing.
>>
>> The behaviour was broken by commit 35a20c2 (2014-06-13).
>>
>> As a workaround, use "noise_generator 2" in the global settings.
>
> A source file fix for POV-Ray proper is available now in the master
> branch at GitHub.

All I was able to find was a diff readout for 3 files.  Is that all 
there is, or is there a new complete alpha release?  I guess I'm still 
learning my way around GitHub.

I applied those 3 changes to my alpha.8141620 files and recompiled.  The 
new executable confirms that alpha.8150025 is running, but the problem 
remains.  I went back to GitHub to see if I had somehow miscopied the 
changes, but I couldn't find the page again.  (Like I said, I still have 
trouble navigating GitHub.)

The good news is that sometime between 3.7.0.0 and 3.7.1-alpha, another 
bug was fixed: random white splotches in radiosity renders.  I had not 
reported it to date, because I was unable to narrow down the problem to 
create a simplified scene file.  (The attached renders may look simple, 
but they were generated by a render rig with somewhat complex 
internals.)  Thomas de Groot seemed to have a similar problem when 
testing out Scott Boham's SkySim, but I concluded that those anomalies 
were completely unrelated to my problem.

splotches-36.jpg - Rendered by POV-Ray 3.6.1.

splotches-37.jpg - Rendered by POV-Ray 3.7.0.0.  Note the ugly white 
splotches.  When the hills are deleted, there are no splotches.  There 
are circumstances in which the hills are present /without/ splotches, 
but I have been unable to determine a pattern.

splotches-37norad.jpg - Rendered by POV-Ray 3.7.0.0 without radiosity. 
There are no splotches, so they were somehow triggered by radiosity.

splotches-371.jpg - Rendered by POV-Ray 3.7.1.  The hills are different, 
but the white splotches are gone.

splotches-371ng2.jpg - Rendered by POV-Ray 3.7.1 with noise_generator 2 
in global settings.  The hills are back as desired.

Post a reply to this message

Attachments:
Download 'splotches-36.jpg' (51 KB) Download 'splotches-37.jpg' (58 KB) Download 'splotches-37norad.jpg' (53 KB) Download 'splotches-371.jpg' (54 KB) Download 'splotches-371ng2.jpg' (53 KB)

Preview of image 'splotches-36.jpg'

Preview of image 'splotches-37.jpg'

Preview of image 'splotches-37norad.jpg'

Preview of image 'splotches-371.jpg'

Preview of image 'splotches-371ng2.jpg'

Am 01.07.2015 um 02:18 schrieb Cousin Ricky:

>> A source file fix for POV-Ray proper is available now in the master
>> branch at GitHub.
>
> All I was able to find was a diff readout for 3 files.  Is that all
> there is, or is there a new complete alpha release?  I guess I'm still
> learning my way around GitHub.

I guess you're refering to this page:

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

Those are the changes that comprise the fix. Such a bunch of changes is 
called a "commit".

(A "commit" is also sometimes used in the sense of a particular version 
of the entire source code. Not surprisingly, in this sense it refers to 
the source code as it was right after the change was submitted.)

To get the most recent version of the entire source code via the GitHub 
web interface, go to https://github.com/POV-Ray/povray, and click on the 
"Download ZIP" button at the right margin. (To be precise, that'll give 
you the most recent version of the "master" branch.)

You can also retrieve the source code via the "git" Unix command line 
tool, but you have to know how (which I don't - not off the top of my 
head anyway; IIRC Jim Holsenback had posted some standard recipe a while 
ago, but from my experience it can be a bit more difficult than that at 
times).


With "complete alpha release" you're presumably refering to the releases 
at https://github.com/c-lipka/povray/releases.

Actually, if there is any such thing as an "alpha release" of POV-Ray, 
then /any/ update to the "master" branch of the repository constitutes 
such a release.

The stuff made available on https://github.com/c-lipka/povray/releases 
is just semi-official builds of snapshots from the official repository, 
provided as a courtesy to Windows users interested in test-driving the 
latest and greatest stuff, who can't just pull the source code and build 
their own binaries. The fact that these are labeled as "releases" is 
entirely technical, just like the fact that they are accompanied by 
source code packages. It just so happens that GitHub's "release" 
mechanism is the most convenient way to distribute the binaries. (Also 
note that those semi-official builds don't live in the official 
repository, but in a clone on my personal GitHub account.)

> I applied those 3 changes to my alpha.8141620 files and recompiled.  The
> new executable confirms that alpha.8150025 is running, but the problem
> remains.

I'm quite surprised to hear that. I recommend to try and build again 
from a full snapshot of alpha.8150025, and see what that does.

Did you experiment with the "noise_generator" workaround?

Post a reply to this message

On 2015-06-30 09:41 PM (-4), clipka wrote:
> Did you experiment with the "noise_generator" workaround?

Yes I did.  The (satisfactory) result is splotches-371ng2.jpg of my 
previous post.

Post a reply to this message