 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
