[Bf-cycles] Environment/lightprobe importance sampling patch

Constantin Rahn conz at vrchannel.de
Sat Jan 21 11:06:31 CET 2012


Hi,

i have tested the importance sampling with one of my current scenes 
(Blender 2.61.43676, Win 7 64). But I have the problem, that there is no 
shadow with activated imp. sampling.

Rendering without importance sampling (250spp, CPU):
http://www.vrchannel.de/blender/Test_is_off.jpg

Rendering with importance sampling (~50spp, CPU), only activated the 
"sample as lamp" (512) for the BG:
http://www.vrchannel.de/blender/Test_is_on.jpg

Maybe it has to do with my node setup. I am using two different BG 
images, one JPG as visible background and one HDRI for the lighting with 
different power.
The node setup:
http://www.vrchannel.de/blender/Test_is_nodes.png

I get no specific "importance sampling" massage in the console. But 
there are some "Memoryblock free: attempt to free NULL pointer".
I can't send my scene, will try to reduce the problem to a simpler scene.

Greetings and happy blending
Conz

Am 20.01.2012 06:00, schrieb Mike Farnsworth:
> Okay, one more update.  This version hopefully fixes an issue where
> any changes to nearly any setting were causing a re-render, because I
> wasn't checking for opportunities to skip the background light sync.
> This version seems to trigger fewer progressive render updates, but
> still updates at the right times.
>
> Brecht, let me know when you think this might make it into trunk.
>
> Thanks,
> Farny
>
> On Tue, Jan 17, 2012 at 10:59 PM, Mike Farnsworth
> <mike.farnsworth at gmail.com>  wrote:
>> I've updated the patch to include the task split (max of 16384 shader
>> evaluations per task), as well as turn off the background
>> sample_as_light switch by default to not adversely impact performance
>> for those who haven't set a custom environment.  I don't know of any
>> other outstanding issues.
>>
>> -Farny
>>
>> On Tue, Jan 17, 2012 at 6:18 AM, Brecht Van Lommel
>> <brechtvanlommel at pandora.be>  wrote:
>>> Great work! I'll do a proper review of it later.
>>>
>>> Regarding the task size, there's a function to split up tasks in the
>>> device code. It's used in device_opencl.cpp, task_add, if there's a
>>> CUDA issue with maximum size being exceeded a similar thing could be
>>> done there.
>>>
>>> Brecht.
>>>
>>> On Mon, Jan 16, 2012 at 6:16 PM, Mike Farnsworth
>>> <mike.farnsworth at gmail.com>  wrote:
>>>> Someone tried the patch and had a crash when using an importance
>>>> resolution greater than 1023.  (It's really just eating it with a
>>>> cuda_assert(cuLaunchGrid(cuDisplace, xblocks, 1)) when launching the
>>>> shader task.)  I had the same issue with my GTX 260, and I thought it
>>>> was just because that was an old(er) graphics card.  On my GTX 460 it
>>>> doesn't seem to have any issues with the importance resolution.  If
>>>> the GTX 560 Ti is crashing too, though, then I should probably to do
>>>> something about it.
>>>>
>>>> The issue is that when running a cuda task, you can't have 65536
>>>> blocks in any dimension.  We use a block size of 16, and with a
>>>> resolution of 1024x1024, that results in 65536 blocks in the X
>>>> direction.  The near-term workaround is to keep the resolution under
>>>> 1024, perhaps limited in the UI.
>>>>
>>>> The long-term solution is that I need to break up the background
>>>> evaluation task into, say, chunks of 128x128 and go through them one
>>>> at a time in order to cover the whole background.
>>>>
>>>> -Farny
>>>>
>>>> On Sun, Jan 15, 2012 at 11:35 PM, Mike Farnsworth
>>>> <mike.farnsworth at gmail.com>  wrote:
>>>>> This patch includes a full implementation of importance sampling for
>>>>> environments, including the MIS solution we talked about.  It adds two
>>>>> items for the user to control: on/off switch for whether to treat the
>>>>> environment as a light (off is old behavior), and a resolution control
>>>>> for the importance map.  Here are a few notes about the patch:
>>>>>
>>>>> * For environments that are a solid color (or very slowly changing),
>>>>> turning on the env light machinery is overkill, and will actually
>>>>> result in reduced performance.  For anything complex (textures, sky,
>>>>> noise, etc) it produces noticeably less noise for the same number of
>>>>> passes, so it should be a solid advantage.
>>>>>
>>>>> * Any HDR environment textures are chopped down to SDR range by the
>>>>> texture upload to device right now (nothing to do with my patch, of
>>>>> course); this reduces the effectiveness of this new environment
>>>>> sampling.  If we can fix that, the env light sampling will have an
>>>>> even greater effect, not to mention potentially improved visuals in
>>>>> general.  Just sayin'...
>>>>>
>>>>> * The patch includes a change where the displacement device function
>>>>> now outputs to a float4 buffer, not a float3 buffer, because on my
>>>>> older GPU that was causing completely screwed up sampling of the
>>>>> background when building the importance map.  So, displacement and
>>>>> shader tasks now have a slightly larger output buffer, but it now
>>>>> works on both my older GPU (GTX 260, sm_13) and my newer GPU (GTX 460,
>>>>> sm_21).
>>>>>
>>>>> * There is a commented #define that allows dumping the sampled
>>>>> background and both parts of the importance map to /tmp for debugging
>>>>> purposes.  Those sections of code can be removed, but they could come
>>>>> in handy in the future.
>>>>>
>>>>> I'm going to post some before/after images to morecycles.blogspot.com
>>>>> tonight, so you can see the difference in quality.  I apologize for
>>>>> this taking longer than I had anticipated.  I had left in a
>>>>> __int_as_float(f) where I should have just had an (int)f instead, and
>>>>> it manifested itself with a zero PDF for the environment light, just
>>>>> causing noise.  It took a while to dig through it and find it.
>>>>> Brecht, let me know if you have any issues with the code, and I'll try
>>>>> to turn around any suggestions you make ASAP so this can be included
>>>>> in 2.62.  I understand the deadline is the 22nd?
>>>>>
>>>>> -Farny
>>>> _______________________________________________
>>>> Bf-cycles mailing list
>>>> Bf-cycles at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>>
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20120121/6f5ddd77/attachment.htm 


More information about the Bf-cycles mailing list