<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
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.<br>
<br>
Rendering without importance sampling (250spp, CPU):<br>
<a class="moz-txt-link-freetext" href="http://www.vrchannel.de/blender/Test_is_off.jpg">http://www.vrchannel.de/blender/Test_is_off.jpg</a><br>
<br>
Rendering with importance sampling (~50spp, CPU), only activated the
"sample as lamp" (512) for the BG:<br>
<a class="moz-txt-link-freetext" href="http://www.vrchannel.de/blender/Test_is_on.jpg">http://www.vrchannel.de/blender/Test_is_on.jpg</a><br>
<br>
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.<br>
The node setup:<br>
<a class="moz-txt-link-freetext" href="http://www.vrchannel.de/blender/Test_is_nodes.png">http://www.vrchannel.de/blender/Test_is_nodes.png</a><br>
<br>
I get no specific "importance sampling" massage in the console. But
there are some "Memoryblock free: attempt to free NULL pointer".<br>
I can't send my scene, will try to reduce the problem to a simpler
scene.<br>
<br>
Greetings and happy blending<br>
Conz<br>
<br>
Am 20.01.2012 06:00, schrieb Mike Farnsworth:
<blockquote
cite="mid:CAPZh=FuUmsJDpSQROFqhJ6o0sswGBtfDne_zHOhXPiHv+rKHBg@mail.gmail.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:mike.farnsworth@gmail.com"><mike.farnsworth@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:brechtvanlommel@pandora.be"><brechtvanlommel@pandora.be></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:mike.farnsworth@gmail.com"><mike.farnsworth@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:mike.farnsworth@gmail.com"><mike.farnsworth@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>