 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm currently implementing a new UberPOV feature that allows bypassing
the caching of radiosity samples, effectively resulting in purely
stochastic unbiased Global Illumination computation. (See recent
discussion on povray.unofficial.patches.)
The first image shows the cornell.pov radiosity sample scene, with
slight modifications to the radiosity settings to eliminate artifacts.
The scene rendered at 3018 pps on my machine. Anti-aliasing was set to
+am2 +a0.3.
The second image shows virtually the same scene, but with radiosity
caching disabled, the radiosity count parameter set to a much lower
value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
with settings chosen to render in about the same time; speed was 3076
pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
The third image shows exactly the same scene as the second one, but with
+a0.01 (in mode 3, this specifies the accepted noise level). Render
quality has obviously indreased, but so has render time: With these
settings, the scene rendered at only 229 pps.
It should be noted that relatively simple scenes with plenty of even
surfaces are easy prey for the radiosity algorithm, so it is no surprise
that this new feature's performance compares quite poor with this scene.
Some benefits of this approach over radiosity:
- Much lower memory footprint especially at high-quality settings.
- Much fewer interdependent quality settings to mess around with.
- No systematic limitations to quality; the result can always be
improved simply by using more aggressive oversampling.
- Unlike radiosity, the algorithm does not require any communication
between threads, and will therefore scale effortlessly in a distributed
rendering environment.
- It is well-suited for a "keep investing render time until I like the
output" mode of operation.
Post a reply to this message
Attachments:
Download 'cornell_rad.png' (77 KB)
Download 'cornell_st.png' (313 KB)
Download 'cornell_st01.png' (226 KB)
Preview of image 'cornell_rad.png'
Preview of image 'cornell_st.png'
Preview of image 'cornell_st01.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 01:27, schrieb clipka:
> It should be noted that relatively simple scenes with plenty of even
> surfaces are easy prey for the radiosity algorithm, so it is no surprise
> that this new feature's performance compares quite poor with this scene.
The radiosity3.pov sample scene, for instance, already shows some
weaknesses of radiosity; at 800x600 pixels, it takes a good deal of
tweaking to get reasonable quality. For recursion_limit 2, I ended up
with settings that gave a rendering speed of 5517 pps.
The other image shows what the new UberPOV patch can do without any
serious tweaking at 5714 pps.
Post a reply to this message
Attachments:
Download 'radiosity3_rad.png' (158 KB)
Download 'radiosity3_st.png' (451 KB)
Preview of image 'radiosity3_rad.png'
Preview of image 'radiosity3_st.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The second image shows virtually the same scene, but with radiosity
> caching disabled, the radiosity count parameter set to a much lower
> value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
> with settings chosen to render in about the same time; speed was 3076
> pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
Looks very good. What is the keyword needed to disable radiosity caching
and what does the +ac value mean?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 09:37, schrieb scott:
>> The second image shows virtually the same scene, but with radiosity
>> caching disabled, the radiosity count parameter set to a much lower
>> value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
>> with settings chosen to render in about the same time; speed was 3076
>> pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
>
> Looks very good. What is the keyword needed to disable radiosity caching
> and what does the +ac value mean?
To disable caching, just add the keyword "no_cache" to the radiosity
block. Make sure to not set the "count" parameter too high - a value as
low as 10 is perfectly ok for this approach.
As for the mode 3 oversampling, this mode is driven by a stochastic
algorithm, similar to focal blur; the +a parameter specifies the
/variance/, and the +ac parameter specifies the /confidence/.
In layman's terms, the mode 3 is all about estimates: While it renders
pixels over and over again, it estimates (A) the colour of the pixel,
(B) the error in the estimated colour, i.e. how much it still differs
from the actual value, and (C) the reliability of the error estimate.
The +a parameter specifies the maximum estimated error you are willing
to accept, while the +ac parameter specifies the minimum reliability you
demand for that error estimate.
In even simpler terms, the +a parameter affects the amount of general
noise in the resulting image, while the +ac parameter affects the amount
of speckle artifacts.
(Last not least, the +r parameter puts a hard maximum on the number of
samples per pixel. The effective limit is 4 to the power of the
parameter value, making it approximately the same as for a worst-case
scenario in anti-aliasing mode 2.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> To disable caching, just add the keyword "no_cache" to the radiosity
> block. Make sure to not set the "count" parameter too high - a value as
> low as 10 is perfectly ok for this approach.
>
> As for the mode 3 oversampling, this mode is driven by a stochastic
> algorithm, similar to focal blur; the +a parameter specifies the
> /variance/, and the +ac parameter specifies the /confidence/.
>
> In layman's terms, the mode 3 is all about estimates: While it renders
> pixels over and over again, it estimates (A) the colour of the pixel,
> (B) the error in the estimated colour, i.e. how much it still differs
> from the actual value, and (C) the reliability of the error estimate.
> The +a parameter specifies the maximum estimated error you are willing
> to accept, while the +ac parameter specifies the minimum reliability you
> demand for that error estimate.
>
> In even simpler terms, the +a parameter affects the amount of general
> noise in the resulting image, while the +ac parameter affects the amount
> of speckle artifacts.
>
> (Last not least, the +r parameter puts a hard maximum on the number of
> samples per pixel. The effective limit is 4 to the power of the
> parameter value, making it approximately the same as for a worst-case
> scenario in anti-aliasing mode 2.)
Thanks, I look forward to having a play. I will have to dig out my
original scene of a TV stand that just refused to work with radiosity
and led me to MCpov in the first place.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 04:27 AM, clipka wrote:
> Am 24.07.2014 09:37, schrieb scott:
>>> The second image shows virtually the same scene, but with radiosity
>>> caching disabled, the radiosity count parameter set to a much lower
>>> value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
>>> with settings chosen to render in about the same time; speed was 3076
>>> pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
>>
>> Looks very good. What is the keyword needed to disable radiosity caching
>> and what does the +ac value mean?
>
> To disable caching, just add the keyword "no_cache" to the radiosity
> block. Make sure to not set the "count" parameter too high - a value as
> low as 10 is perfectly ok for this approach.
Hmmm ... I'm getting an error
File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
undeclared
identifier 'no_cache' found instead
Fatal error in parser: Cannot parse input.
Render failed
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> To disable caching, just add the keyword "no_cache" to the radiosity
>> block. Make sure to not set the "count" parameter too high - a value as
>> low as 10 is perfectly ok for this approach.
>
> Hmmm ... I'm getting an error
>
> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
> undeclared
> identifier 'no_cache' found instead
> Fatal error in parser: Cannot parse input.
> Render failed
Hmmm works OK here - are you sure you're running the latest executable?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 05:29 AM, scott wrote:
>>> To disable caching, just add the keyword "no_cache" to the radiosity
>>> block. Make sure to not set the "count" parameter too high - a value as
>>> low as 10 is perfectly ok for this approach.
>>
>> Hmmm ... I'm getting an error
>>
>> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
>> undeclared
>> identifier 'no_cache' found instead
>> Fatal error in parser: Cannot parse input.
>> Render failed
>
> Hmmm works OK here - are you sure you're running the latest executable?
>
relatively sure ... i already had git repo defined so all i had to do
was: git pull develop develop to update. make was showing the same
warnings that I reported in "Perfect Polish" thread, and version shows:
UberPOV 1.37-dev
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> relatively sure ... i already had git repo defined so all i had to do
> was: git pull develop develop to update. make was showing the same
> warnings that I reported in "Perfect Polish" thread, and version shows:
> UberPOV 1.37-dev
Oh ok, I just took the windows binary, that might explain it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 11:42, schrieb James Holsenback:
> On 07/24/2014 05:29 AM, scott wrote:
>>>> To disable caching, just add the keyword "no_cache" to the radiosity
>>>> block. Make sure to not set the "count" parameter too high - a value as
>>>> low as 10 is perfectly ok for this approach.
>>>
>>> Hmmm ... I'm getting an error
>>>
>>> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
>>> undeclared
>>> identifier 'no_cache' found instead
>>> Fatal error in parser: Cannot parse input.
>>> Render failed
>>
>> Hmmm works OK here - are you sure you're running the latest executable?
>>
>
> relatively sure ... i already had git repo defined so all i had to do
> was: git pull develop develop to update. make was showing the same
> warnings that I reported in "Perfect Polish" thread, and version shows:
> UberPOV 1.37-dev
"UberPOV 1.37-dev" can be virtually anything; I suggest fetching the
official v1.37.0.0-beta.6 sources.
(Or pull the develop branch again... it so happens that I hadn't pushed
the latest changes to that branch yet, just the master branch. Whoops.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 09:50 AM, clipka wrote:
> Am 24.07.2014 11:42, schrieb James Holsenback:
>> On 07/24/2014 05:29 AM, scott wrote:
>>>>> To disable caching, just add the keyword "no_cache" to the radiosity
>>>>> block. Make sure to not set the "count" parameter too high - a
>>>>> value as
>>>>> low as 10 is perfectly ok for this approach.
>>>>
>>>> Hmmm ... I'm getting an error
>>>>
>>>> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
>>>> undeclared
>>>> identifier 'no_cache' found instead
>>>> Fatal error in parser: Cannot parse input.
>>>> Render failed
>>>
>>> Hmmm works OK here - are you sure you're running the latest executable?
>>>
>>
>> relatively sure ... i already had git repo defined so all i had to do
>> was: git pull develop develop to update. make was showing the same
>> warnings that I reported in "Perfect Polish" thread, and version shows:
>> UberPOV 1.37-dev
>
> "UberPOV 1.37-dev" can be virtually anything; I suggest fetching the
> official v1.37.0.0-beta.6 sources.
>
> (Or pull the develop branch again... it so happens that I hadn't pushed
> the latest changes to that branch yet, just the master branch. Whoops.)
>
Hmmmm ... when I'm looking at:
https://github.com/UberPOV/UberPOV/tree/develop
I see this hash:
784444e26b841d91118af7ca26a5f1ffefe60dbc
with this description:
Merge branch 'release/v1.37.0.0-beta.6' into develop
time stamped 13hrs ago
so doing 'git pull develop develop' /should/ have done trick.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 11:47 AM, James Holsenback wrote:
> On 07/24/2014 09:50 AM, clipka wrote:
>> Am 24.07.2014 11:42, schrieb James Holsenback:
>>> On 07/24/2014 05:29 AM, scott wrote:
>>>>>> To disable caching, just add the keyword "no_cache" to the radiosity
>>>>>> block. Make sure to not set the "count" parameter too high - a
>>>>>> value as
>>>>>> low as 10 is perfectly ok for this approach.
>>>>>
>>>>> Hmmm ... I'm getting an error
>>>>>
>>>>> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
>>>>> undeclared
>>>>> identifier 'no_cache' found instead
>>>>> Fatal error in parser: Cannot parse input.
>>>>> Render failed
>>>>
>>>> Hmmm works OK here - are you sure you're running the latest executable?
>>>>
>>>
>>> relatively sure ... i already had git repo defined so all i had to do
>>> was: git pull develop develop to update. make was showing the same
>>> warnings that I reported in "Perfect Polish" thread, and version shows:
>>> UberPOV 1.37-dev
>>
>> "UberPOV 1.37-dev" can be virtually anything; I suggest fetching the
>> official v1.37.0.0-beta.6 sources.
>>
>> (Or pull the develop branch again... it so happens that I hadn't pushed
>> the latest changes to that branch yet, just the master branch. Whoops.)
>>
>
> Hmmmm ... when I'm looking at:
> https://github.com/UberPOV/UberPOV/tree/develop
>
> I see this hash:
> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>
> with this description:
> Merge branch 'release/v1.37.0.0-beta.6' into develop
>
> time stamped 13hrs ago
>
> so doing 'git pull develop develop' /should/ have done trick.
my local repo must have gotten out of sync because i nuked it then
reinitialized it and now uberpov --version returns:
UberPOV 1.37.0.0-beta.6
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 17:47, schrieb James Holsenback:
> Hmmmm ... when I'm looking at:
> https://github.com/UberPOV/UberPOV/tree/develop
>
> I see this hash:
> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>
> with this description:
> Merge branch 'release/v1.37.0.0-beta.6' into develop
>
> time stamped 13hrs ago
Yes - that's indeed when I did the merge...
.. Locally.
> so doing 'git pull develop develop' /should/ have done trick.
if you had pulled right from my local computer, then yes :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 01:10 PM, clipka wrote:
> Am 24.07.2014 17:47, schrieb James Holsenback:
>
>> Hmmmm ... when I'm looking at:
>> https://github.com/UberPOV/UberPOV/tree/develop
>>
>> I see this hash:
>> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>>
>> with this description:
>> Merge branch 'release/v1.37.0.0-beta.6' into develop
>>
>> time stamped 13hrs ago
>
> Yes - that's indeed when I did the merge...
> .. Locally.
>
>> so doing 'git pull develop develop' /should/ have done trick.
>
> if you had pulled right from my local computer, then yes :-P
>
ruh???
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 01:10 PM, clipka wrote:
> Am 24.07.2014 17:47, schrieb James Holsenback:
>
>> Hmmmm ... when I'm looking at:
>> https://github.com/UberPOV/UberPOV/tree/develop
>>
>> I see this hash:
>> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>>
>> with this description:
>> Merge branch 'release/v1.37.0.0-beta.6' into develop
>>
>> time stamped 13hrs ago
>
> Yes - that's indeed when I did the merge...
> .. Locally.
>
>> so doing 'git pull develop develop' /should/ have done trick.
>
> if you had pulled right from my local computer, then yes :-P
>
just got your meaning ... ok, so i'm slow today :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 19:15, schrieb James Holsenback:
> On 07/24/2014 01:10 PM, clipka wrote:
>> Am 24.07.2014 17:47, schrieb James Holsenback:
>>
>>> Hmmmm ... when I'm looking at:
>>> https://github.com/UberPOV/UberPOV/tree/develop
>>>
>>> I see this hash:
>>> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>>>
>>> with this description:
>>> Merge branch 'release/v1.37.0.0-beta.6' into develop
>>>
>>> time stamped 13hrs ago
>>
>> Yes - that's indeed when I did the merge...
>> .. Locally.
>>
>>> so doing 'git pull develop develop' /should/ have done trick.
>>
>> if you had pulled right from my local computer, then yes :-P
>>
>
> ruh???
Okay, I take this as an indication that you're not /too/ familiar with
the distributed nature of the Git revision control system. ;-)
In contrast to Perforce, where you only have one central repository, in
Git you have plenty of them. And none of them is any more authoritative
than the other.
When you do a "git pull", you're actually performing a (unidirectional)
sync of a local repository on your machine with whatever repository you
told git to typically sync with; that means you apply to your local repo
all the commits to the remote ("origin") repo since the previous pull.
(Note that this requires that you haven't made any changes to the
respective branch in your local repo. If that happens, you need to
reconcile the two repos by applying a merge to both.)
(Note that your local working directory is /not/ your local repo. The
local repo instead resides in the ".git" directory therein.)
Likewise, I also have a local repo on my machine (I actually can't avoid
that). When I make changes to the code, I first commit them to the local
repo. I can also merge branches in the local repo. Only when I'm happy
with it all, I will "push" the local changes to the remote repo on
GitHub, i.e. apply all the local commits to the "origin" repo. (Again
this requires that nobody else has made any changes to the respective
branch on the origin repo. If that happens, a reconciliatory merge is
required again.)
It's also possible to propagate commits between repos "sideways", i.e.
without one of the repos being the "origin" of the other, provided that
there is /some/ common history in both repos; any history in between
will automatically be propagated as well.
When changes are propagated from one repo to another, the original
information of that change is propagated as well, including the time and
date of the commit.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 19:48, schrieb James Holsenback:
> On 07/24/2014 01:10 PM, clipka wrote:
>> Am 24.07.2014 17:47, schrieb James Holsenback:
>>
>>> Hmmmm ... when I'm looking at:
>>> https://github.com/UberPOV/UberPOV/tree/develop
>>>
>>> I see this hash:
>>> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>>>
>>> with this description:
>>> Merge branch 'release/v1.37.0.0-beta.6' into develop
>>>
>>> time stamped 13hrs ago
>>
>> Yes - that's indeed when I did the merge...
>> .. Locally.
>>
>>> so doing 'git pull develop develop' /should/ have done trick.
>>
>> if you had pulled right from my local computer, then yes :-P
>>
>
> just got your meaning ... ok, so i'm slow today :-P
Well, in this case you were actually faster than I was, at least as far
as the pulling and pushing is concerned ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 01:52 PM, clipka wrote:
> Am 24.07.2014 19:15, schrieb James Holsenback:
>> On 07/24/2014 01:10 PM, clipka wrote:
>>> Am 24.07.2014 17:47, schrieb James Holsenback:
>>>
>>>> Hmmmm ... when I'm looking at:
>>>> https://github.com/UberPOV/UberPOV/tree/develop
>>>>
>>>> I see this hash:
>>>> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>>>>
>>>> with this description:
>>>> Merge branch 'release/v1.37.0.0-beta.6' into develop
>>>>
>>>> time stamped 13hrs ago
>>>
>>> Yes - that's indeed when I did the merge...
>>> .. Locally.
>>>
>>>> so doing 'git pull develop develop' /should/ have done trick.
>>>
>>> if you had pulled right from my local computer, then yes :-P
>>>
>>
>> ruh???
>
> Okay, I take this as an indication that you're not /too/ familiar with
> the distributed nature of the Git revision control system. ;-)
nope you'd be wrong ... aware of .git directory, it get's created for
the 1st time when 'git init' is issued. contains all kind of useful info
about what revision (commits) have been pulled, so that when 'git pull
develop develop' is all that's needed to get updates. as i eluded in
other responses think i simply pulled before you had a chance to update
the 'develop' branch ... i'm good to go
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24-7-2014 19:55, clipka wrote:
> Well, in this case you were actually faster than I was, at least as far
> as the pulling and pushing is concerned ;-)
>
Hey guys, cool down! Stop that pushing and pulling around now! Somebody
is going to get hurt! :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.07.2014 09:23, schrieb Thomas de Groot:
> On 24-7-2014 19:55, clipka wrote:
>> Well, in this case you were actually faster than I was, at least as far
>> as the pulling and pushing is concerned ;-)
>>
>
> Hey guys, cool down! Stop that pushing and pulling around now! Somebody
> is going to get hurt! :-)
Only the code, Thomas. Only the code...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/23/2014 07:27 PM, clipka wrote:
> I'm currently implementing a new UberPOV feature that allows bypassing
> the caching of radiosity samples, effectively resulting in purely
> stochastic unbiased Global Illumination computation. (See recent
> discussion on povray.unofficial.patches.)
here's the image that prompted my parameter question in p.u.patches ...
the alcove is made of box primitives and has cylinders to round the
insides of the corners, used merge not union.
Post a reply to this message
Attachments:
Download 'work.png' (1802 KB)
Preview of image 'work.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.08.2014 12:04, schrieb James Holsenback:
> On 07/23/2014 07:27 PM, clipka wrote:
>> I'm currently implementing a new UberPOV feature that allows bypassing
>> the caching of radiosity samples, effectively resulting in purely
>> stochastic unbiased Global Illumination computation. (See recent
>> discussion on povray.unofficial.patches.)
>
> here's the image that prompted my parameter question in p.u.patches ...
> the alcove is made of box primitives and has cylinders to round the
> insides of the corners, used merge not union.
I think what you're seeing is not an artifact at all.
A surface like the floor typically gets darker near other surfaces such
as the wall; but the strength of this effect depends on the wall's
brightness. A very bright wall - whether just due to its colour or also
due to the angle of illumination - may cause the floor nearby to even
become /brighter/ than elsewhere, while a very dark wall - whether just
due to its colour, angle of illumination or shadows - will cause the
nearby floor to become /extremely/ dark.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/04/2014 06:57 AM, clipka wrote:
> Am 04.08.2014 12:04, schrieb James Holsenback:
>> On 07/23/2014 07:27 PM, clipka wrote:
>>> I'm currently implementing a new UberPOV feature that allows bypassing
>>> the caching of radiosity samples, effectively resulting in purely
>>> stochastic unbiased Global Illumination computation. (See recent
>>> discussion on povray.unofficial.patches.)
>>
>> here's the image that prompted my parameter question in p.u.patches ...
>> the alcove is made of box primitives and has cylinders to round the
>> insides of the corners, used merge not union.
>
> I think what you're seeing is not an artifact at all.
>
> A surface like the floor typically gets darker near other surfaces such
> as the wall; but the strength of this effect depends on the wall's
> brightness. A very bright wall - whether just due to its colour or also
> due to the angle of illumination - may cause the floor nearby to even
> become /brighter/ than elsewhere, while a very dark wall - whether just
> due to its colour, angle of illumination or shadows - will cause the
> nearby floor to become /extremely/ dark.
>
Hmmm ... ok then just for sake of discussion here's how
#include "rad_def.inc"
Rad_Settings(Radiosity_Fast, off, off)
handles things
Post a reply to this message
Attachments:
Download 'work.png' (1752 KB)
Preview of image 'work.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.08.2014 13:31, schrieb James Holsenback:
> On 08/04/2014 06:57 AM, clipka wrote:
>> Am 04.08.2014 12:04, schrieb James Holsenback:
>>> On 07/23/2014 07:27 PM, clipka wrote:
>>>> I'm currently implementing a new UberPOV feature that allows bypassing
>>>> the caching of radiosity samples, effectively resulting in purely
>>>> stochastic unbiased Global Illumination computation. (See recent
>>>> discussion on povray.unofficial.patches.)
>>>
>>> here's the image that prompted my parameter question in p.u.patches ...
>>> the alcove is made of box primitives and has cylinders to round the
>>> insides of the corners, used merge not union.
>>
>> I think what you're seeing is not an artifact at all.
>>
>> A surface like the floor typically gets darker near other surfaces such
>> as the wall; but the strength of this effect depends on the wall's
>> brightness. A very bright wall - whether just due to its colour or also
>> due to the angle of illumination - may cause the floor nearby to even
>> become /brighter/ than elsewhere, while a very dark wall - whether just
>> due to its colour, angle of illumination or shadows - will cause the
>> nearby floor to become /extremely/ dark.
>>
>
> Hmmm ... ok then just for sake of discussion here's how
>
> #include "rad_def.inc"
> Rad_Settings(Radiosity_Fast, off, off)
>
> handles things
... because it happens to utterly miscompute it.
Use more pretrace steps and a lower error_bound for starters.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/04/2014 07:49 AM, clipka wrote:
> Am 04.08.2014 13:31, schrieb James Holsenback:
>> On 08/04/2014 06:57 AM, clipka wrote:
>>> Am 04.08.2014 12:04, schrieb James Holsenback:
>>>> On 07/23/2014 07:27 PM, clipka wrote:
>>>>> I'm currently implementing a new UberPOV feature that allows bypassing
>>>>> the caching of radiosity samples, effectively resulting in purely
>>>>> stochastic unbiased Global Illumination computation. (See recent
>>>>> discussion on povray.unofficial.patches.)
>>>>
>>>> here's the image that prompted my parameter question in p.u.patches ...
>>>> the alcove is made of box primitives and has cylinders to round the
>>>> insides of the corners, used merge not union.
>>>
>>> I think what you're seeing is not an artifact at all.
>>>
>>> A surface like the floor typically gets darker near other surfaces such
>>> as the wall; but the strength of this effect depends on the wall's
>>> brightness. A very bright wall - whether just due to its colour or also
>>> due to the angle of illumination - may cause the floor nearby to even
>>> become /brighter/ than elsewhere, while a very dark wall - whether just
>>> due to its colour, angle of illumination or shadows - will cause the
>>> nearby floor to become /extremely/ dark.
>>>
>>
>> Hmmm ... ok then just for sake of discussion here's how
>>
>> #include "rad_def.inc"
>> Rad_Settings(Radiosity_Fast, off, off)
>>
>> handles things
>
> ... because it happens to utterly miscompute it.
>
> Use more pretrace steps and a lower error_bound for starters.
>
well yeah ... my point was to compare no_cache with bare bones radiosity
settings. i'm thinking it (rad) get's closer with what amounts to "quick
pass" settings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.08.2014 14:01, schrieb James Holsenback:
> well yeah ... my point was to compare no_cache with bare bones radiosity
> settings. i'm thinking it (rad) get's closer with what amounts to "quick
> pass" settings.
Compare in what sense? Render speed? Quality? The settings to use?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/04/2014 07:49 AM, clipka wrote:
> Am 04.08.2014 13:31, schrieb James Holsenback:
>> On 08/04/2014 06:57 AM, clipka wrote:
>>> Am 04.08.2014 12:04, schrieb James Holsenback:
>>>> On 07/23/2014 07:27 PM, clipka wrote:
>>>>> I'm currently implementing a new UberPOV feature that allows bypassing
>>>>> the caching of radiosity samples, effectively resulting in purely
>>>>> stochastic unbiased Global Illumination computation. (See recent
>>>>> discussion on povray.unofficial.patches.)
>>>>
>>>> here's the image that prompted my parameter question in p.u.patches ...
>>>> the alcove is made of box primitives and has cylinders to round the
>>>> insides of the corners, used merge not union.
>>>
>>> I think what you're seeing is not an artifact at all.
agreed ... lack of light sounds better. changed spotlight to point light
and looks closer to what i'd expect, so then changed radius and falloff
a couple of times until it looked right. the values causing problem were
arrived at by backing off the camera and settled on values that
illuminated the test object and alcove, so i can't explain why the
chosen values were the problem ... yet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
