Now with those fancy finish features recently shown off in 
povray.binary.images.

Also does stochastic global illumination now.


Get the Windows binaries or cross-platform source code here:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.6

Post a reply to this message

On 07/24/2014 12:01 AM, clipka wrote:
> Also does stochastic global illumination now.

are there any other parameters (besides count and brightness) that work 
in this mode? changes.txt says most don't ... just curious

Post a reply to this message

On 07/24/2014 12:01 AM, clipka wrote:
> Also does stochastic global illumination now.

are there any parameters (besides count and brightness) that work in 
this mode? changes.txt says most don't ... just curious

Post a reply to this message

Am 26.07.2014 14:44, schrieb James Holsenback:
> On 07/24/2014 12:01 AM, clipka wrote:
>> Also does stochastic global illumination now.
>
> are there any other parameters (besides count and brightness) that work
> in this mode? changes.txt says most don't ... just curious

Just browsed the list of all the settings; The following should still 
have an effect:

     brightness FLOAT
     count FLOAT
     gray_threshold FLOAT
     recursion_limit INT
     adc_bailout FLOAT
     normal BOOL
     media BOOL
     subsurface BOOL
     brilliance BOOL

All others are just concerned with sample caching.

Post a reply to this message

Le 24/07/2014 06:01, clipka a écrit :
> Now with those fancy finish features recently shown off in
> povray.binary.images.
>
> Also does stochastic global illumination now.
>
>
> Get the Windows binaries or cross-platform source code here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.6

It seems that nothing appear when a scene like this is rendered. The 
image is black if version is 3.7; rather unofficial patch 3.7;

version 3.7;
//#version unofficial patch 3.7;

camera {
	location <15, 15, -15>
	look_at <0, 0, 0>
	angle 90
}

//background {color 0.5}


plane {
	y,-1
	pigment {color 0.25}
}

box {
	<-1.00, 0.00, -1.00>,< 1.00, 2.00, 1.00>
	texture {
		pigment{ color rgb<1.00, 1.00, 1.00>}
		finish { phong 1 reflection{ 0.00 metallic 0.00} }
	}
}

light_source { <20, 20, -20> color rgb 1 }

-- 
Do not judge my words, judge my actions.

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com

Post a reply to this message

Le 29/07/2014 14:43, FractRacer a écrit :
> It seems that nothing appear when a scene like this is rendered. The
> image is black if version is 3.7; rather unofficial patch 3.7;
>
> version 3.7;
> //#version unofficial patch 3.7;
>

Oops, I have missed the # before the version directive, it is why all is 
black (even with pov3.7). I have an parse message which says there is no 
objects in scene.

Lionel


---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com

Post a reply to this message

On 07/26/2014 01:57 PM, clipka wrote:
> Am 26.07.2014 14:44, schrieb James Holsenback:
>> On 07/24/2014 12:01 AM, clipka wrote:
>>> Also does stochastic global illumination now.
>>
>> are there any other parameters (besides count and brightness) that work
>> in this mode? changes.txt says most don't ... just curious
>
> Just browsed the list of all the settings; The following should still
> have an effect:
>
>      brightness FLOAT
>      count FLOAT
>      gray_threshold FLOAT
>      recursion_limit INT
>      adc_bailout FLOAT
>      normal BOOL
>      media BOOL
>      subsurface BOOL
>      brilliance BOOL
>
> All others are just concerned with sample caching.
>

what would be the best parameter to use if I'm seeing artifact in 
corners (shadow of an object hits floor and wall and it's darker where 
the wall and floor meet) ... I want to say count, but I also have an 
emission object, so I'm wondering if adc_bailout might also come into play

Post a reply to this message

Am 03.08.2014 20:59, schrieb James Holsenback:
> On 07/26/2014 01:57 PM, clipka wrote:
>> Am 26.07.2014 14:44, schrieb James Holsenback:
>>> On 07/24/2014 12:01 AM, clipka wrote:
>>>> Also does stochastic global illumination now.
>>>
>>> are there any other parameters (besides count and brightness) that work
>>> in this mode? changes.txt says most don't ... just curious
>>
>> Just browsed the list of all the settings; The following should still
>> have an effect:
>>
>>      brightness FLOAT
>>      count FLOAT
>>      gray_threshold FLOAT
>>      recursion_limit INT
>>      adc_bailout FLOAT
>>      normal BOOL
>>      media BOOL
>>      subsurface BOOL
>>      brilliance BOOL
>>
>> All others are just concerned with sample caching.
>>
>
> what would be the best parameter to use if I'm seeing artifact in
> corners (shadow of an object hits floor and wall and it's darker where
> the wall and floor meet) ... I want to say count, but I also have an
> emission object, so I'm wondering if adc_bailout might also come into play

No, with no_cache the count parameter is less about quality and more 
about render speed.

But I'd have to see the artifacts to think of a reason why they'd be 
there and how they could be avoided.

Post a reply to this message

> Now with those fancy finish features recently shown off in
> povray.binary.images.
>
> Also does stochastic global illumination now.

I found under some conditions you get a visible pattern to the noise 
when doing a low quality "preview" render with no_cache. It's almost as 
if the random number generator is seeded off the pixel coordinate or 
something? Is this possible or am I seeing patterns where none exist?

Post a reply to this message

Le 14-08-11 06:24, scott a écrit :
>> Now with those fancy finish features recently shown off in
>> povray.binary.images.
>>
>> Also does stochastic global illumination now.
>
> I found under some conditions you get a visible pattern to the noise
> when doing a low quality "preview" render with no_cache. It's almost as
> if the random number generator is seeded off the pixel coordinate or
> something? Is this possible or am I seeing patterns where none exist?
>

A simple way to check that: Launch a 2 or 3 frames animation with no 
changes between the frames.
If there is a repeatable pattern, the images will show the same pattern. 
If the pattern is just random noise, it will change from frame to frame.


Alain

Post a reply to this message

>> I found under some conditions you get a visible pattern to the noise
>> when doing a low quality "preview" render with no_cache. It's almost as
>> if the random number generator is seeded off the pixel coordinate or
>> something? Is this possible or am I seeing patterns where none exist?
>>
>
> A simple way to check that: Launch a 2 or 3 frames animation with no
> changes between the frames.
> If there is a repeatable pattern, the images will show the same pattern.
> If the pattern is just random noise, it will change from frame to frame.

OK it's the same every frame, I'll post an image in p.b.i.

Post a reply to this message

>>> I found under some conditions you get a visible pattern to the noise
>>> when doing a low quality "preview" render with no_cache. It's almost as
>>> if the random number generator is seeded off the pixel coordinate or
>>> something? Is this possible or am I seeing patterns where none exist?
>>>
>>
>> A simple way to check that: Launch a 2 or 3 frames animation with no
>> changes between the frames.
>> If there is a repeatable pattern, the images will show the same pattern.
>> If the pattern is just random noise, it will change from frame to frame.
>
> OK it's the same every frame, I'll post an image in p.b.i.

Actually I just realised this has an implication, that you can't render 
N times on one machine (or I assume on N machines) and then average the 
result. Should there be a way to set the RNG seed that is used for 
choosing the direction to shoot rays?

Post a reply to this message

Am 27.08.2014 08:57, schrieb scott:
>>>> I found under some conditions you get a visible pattern to the noise
>>>> when doing a low quality "preview" render with no_cache. It's almost as
>>>> if the random number generator is seeded off the pixel coordinate or
>>>> something? Is this possible or am I seeing patterns where none exist?
>>>>
>>>
>>> A simple way to check that: Launch a 2 or 3 frames animation with no
>>> changes between the frames.
>>> If there is a repeatable pattern, the images will show the same pattern.
>>> If the pattern is just random noise, it will change from frame to frame.
>>
>> OK it's the same every frame, I'll post an image in p.b.i.
>
> Actually I just realised this has an implication, that you can't render
> N times on one machine (or I assume on N machines) and then average the
> result. Should there be a way to set the RNG seed that is used for
> choosing the direction to shoot rays?

By default UberPOV will seed each thread's stochastic RNG with the 
current time plus thread number, but I guess I should change this so 
that a render started 1 second later doesn't give you the same seeds for 
threads 1..N as the previous one for threads 0..(N-1), and I should also 
look into why this doesn't seem to work for animations.

That aside, you can always specify a custom seed (or, more precisely, 
seed base, as UberPOV will still add the thread number to it) using the 
"+SSn" or "Stochastic_Seed=n" option.

Post a reply to this message

> By default UberPOV will seed each thread's stochastic RNG with the
> current time plus thread number,

Hmmm, something strange is going on, when I look at the difference 
between the exact same scene rendered a few minutes apart there are 
about 10% of blocks that are totally identical, the rest are random 
noise. See image I just posted to p.b.i.

> That aside, you can always specify a custom seed (or, more precisely,
> seed base, as UberPOV will still add the thread number to it) using the
> "+SSn" or "Stochastic_Seed=n" option.

It doesn't recognise the +SS option here (beta 7 release).

Post a reply to this message

On 28/08/2014 10:12, scott wrote:
>> By default UberPOV will seed each thread's stochastic RNG with the
>> current time plus thread number,
>
> Hmmm, something strange is going on, when I look at the difference
> between the exact same scene rendered a few minutes apart there are
> about 10% of blocks that are totally identical, the rest are random
> noise. See image I just posted to p.b.i.

If I reduce the thread count to 1 then it's only the first top-left 
block that is identical - the rest of the image is random.

Post a reply to this message

Am 28.08.2014 11:12, schrieb scott:

>> That aside, you can always specify a custom seed (or, more precisely,
>> seed base, as UberPOV will still add the thread number to it) using the
>> "+SSn" or "Stochastic_Seed=n" option.
>
> It doesn't recognise the +SS option here (beta 7 release).

Dang. Forget everything I've said; I just notice that I haven't built 
any Windows beta yet that includes those changes; in beta 7, the RNG is 
indeed seeded with a default value. Help is on the way, expect a new 
beta release later tonight.

Post a reply to this message

Am 28.08.2014 18:34, schrieb clipka:
> Am 28.08.2014 11:12, schrieb scott:
>
>>> That aside, you can always specify a custom seed (or, more precisely,
>>> seed base, as UberPOV will still add the thread number to it) using the
>>> "+SSn" or "Stochastic_Seed=n" option.
>>
>> It doesn't recognise the +SS option here (beta 7 release).
>
> Dang. Forget everything I've said; I just notice that I haven't built
> any Windows beta yet that includes those changes; in beta 7, the RNG is
> indeed seeded with a default value. Help is on the way, expect a new
> beta release later tonight.

Done.

Post a reply to this message

>>>> That aside, you can always specify a custom seed (or, more precisely,
>>>> seed base, as UberPOV will still add the thread number to it) using the
>>>> "+SSn" or "Stochastic_Seed=n" option.
>>>
>>> It doesn't recognise the +SS option here (beta 7 release).
>>
>> Dang. Forget everything I've said; I just notice that I haven't built
>> any Windows beta yet that includes those changes; in beta 7, the RNG is
>> indeed seeded with a default value. Help is on the way, expect a new
>> beta release later tonight.
>
> Done.

Excellent thanks :-)

Post a reply to this message