<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Quick Gaussian Filtering</title>
	<atom:link href="http://www.realtimerendering.com/blog/quick-gaussian-filtering/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/</link>
	<description>Tracking the latest developments in interactive rendering techniques</description>
	<lastBuildDate>Mon, 17 Jun 2013 03:17:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.1</generator>
	<item>
		<title>By: venzon</title>
		<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/comment-page-1/#comment-1745</link>
		<dc:creator>venzon</dc:creator>
		<pubDate>Thu, 23 Sep 2010 23:26:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=1718#comment-1745</guid>
		<description>The mipmap chain stuff is very useful for very-large-kernel gaussian blurs (for example, you can get results identical to applying a 40x40 gaussian kernel by recursively applying a 5x5 gaussian blur kernel over 4 mip chains). I&#039;m not sure of any other way to do big kernels efficiently on DX9 hardware.</description>
		<content:encoded><![CDATA[<p>The mipmap chain stuff is very useful for very-large-kernel gaussian blurs (for example, you can get results identical to applying a 40&#215;40 gaussian kernel by recursively applying a 5&#215;5 gaussian blur kernel over 4 mip chains). I&#8217;m not sure of any other way to do big kernels efficiently on DX9 hardware.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: castano</title>
		<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/comment-page-1/#comment-1743</link>
		<dc:creator>castano</dc:creator>
		<pubDate>Wed, 22 Sep 2010 07:05:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=1718#comment-1743</guid>
		<description>No, Philip is just being too modest. I suppose he&#039;s referring to the mipmap chain stuff which is not really necessary for a gaussian filter, but it&#039;s nevertheless useful for some effects (Halo 2 for example uses a similar approach for their bloom filter). In any case, that&#039;s completely orthogonal to the main points (pascal triangle, separability and bilinear interpolation).</description>
		<content:encoded><![CDATA[<p>No, Philip is just being too modest. I suppose he&#8217;s referring to the mipmap chain stuff which is not really necessary for a gaussian filter, but it&#8217;s nevertheless useful for some effects (Halo 2 for example uses a similar approach for their bloom filter). In any case, that&#8217;s completely orthogonal to the main points (pascal triangle, separability and bilinear interpolation).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric</title>
		<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/comment-page-1/#comment-1741</link>
		<dc:creator>Eric</dc:creator>
		<pubDate>Tue, 21 Sep 2010 20:03:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=1718#comment-1741</guid>
		<description>&gt; A similar article that predates these: http://prideout.net/archive/bloom/

Interestingly enough, the author of that article has the first comment on Daniel&#039;s blog post, warning people away from it (which begs the question, why not just fix that article?):

Sweet. This is similar to my old bloom tutorial, which I wrote when I was young and stupid: http://prideout.net/archive/bloom/
Some aspects of my tutorial are an embarrassment to me now, so I hope folks will encounter your article before mine. Keep up the good work Daniel!</description>
		<content:encoded><![CDATA[<p>> A similar article that predates these: <a href="http://prideout.net/archive/bloom/" rel="nofollow">http://prideout.net/archive/bloom/</a></p>
<p>Interestingly enough, the author of that article has the first comment on Daniel&#8217;s blog post, warning people away from it (which begs the question, why not just fix that article?):</p>
<p>Sweet. This is similar to my old bloom tutorial, which I wrote when I was young and stupid: <a href="http://prideout.net/archive/bloom/" rel="nofollow">http://prideout.net/archive/bloom/</a><br />
Some aspects of my tutorial are an embarrassment to me now, so I hope folks will encounter your article before mine. Keep up the good work Daniel!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: castano</title>
		<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/comment-page-1/#comment-1740</link>
		<dc:creator>castano</dc:creator>
		<pubDate>Tue, 21 Sep 2010 19:12:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=1718#comment-1740</guid>
		<description>A similar article that predates these: http://prideout.net/archive/bloom/</description>
		<content:encoded><![CDATA[<p>A similar article that predates these: <a href="http://prideout.net/archive/bloom/" rel="nofollow">http://prideout.net/archive/bloom/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: imbusy</title>
		<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/comment-page-1/#comment-1739</link>
		<dc:creator>imbusy</dc:creator>
		<pubDate>Tue, 21 Sep 2010 08:26:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=1718#comment-1739</guid>
		<description>And now there are tricks for saving bandwidth and storing texture access results in thread local storage with OpenCL/DirectX Compute/CUDA.</description>
		<content:encoded><![CDATA[<p>And now there are tricks for saving bandwidth and storing texture access results in thread local storage with OpenCL/DirectX Compute/CUDA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ivan-Assen</title>
		<link>http://www.realtimerendering.com/blog/quick-gaussian-filtering/comment-page-1/#comment-1738</link>
		<dc:creator>Ivan-Assen</dc:creator>
		<pubDate>Tue, 21 Sep 2010 06:11:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=1718#comment-1738</guid>
		<description>Keep in mind that on a certain platform that can&#039;t directly texture from its render targets, a non-separable 9x9 Gaussians is faster than a separable 9+9 version with a resolve (transfer from RT to texture) between the H and V passes.

Whether it&#039;s faster to calculate offsets in the VS and pass down via interpolators to the PS, or directly calculate there should be benchmarked on your particular hardware - some GPUs really hate additional vertex attributes.</description>
		<content:encoded><![CDATA[<p>Keep in mind that on a certain platform that can&#8217;t directly texture from its render targets, a non-separable 9&#215;9 Gaussians is faster than a separable 9+9 version with a resolve (transfer from RT to texture) between the H and V passes.</p>
<p>Whether it&#8217;s faster to calculate offsets in the VS and pass down via interpolators to the PS, or directly calculate there should be benchmarked on your particular hardware &#8211; some GPUs really hate additional vertex attributes.</p>
]]></content:encoded>
	</item>
</channel>
</rss>