<?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: 7 things for January 4th</title>
	<atom:link href="http://www.realtimerendering.com/blog/7-things-for-january-4th/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.realtimerendering.com/blog/7-things-for-january-4th/</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: morgan3d</title>
		<link>http://www.realtimerendering.com/blog/7-things-for-january-4th/comment-page-1/#comment-247</link>
		<dc:creator>morgan3d</dc:creator>
		<pubDate>Thu, 07 Jan 2010 03:28:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=690#comment-247</guid>
		<description>I recently came across this 2008 OpenGL extension for 9-bit mantissa, 5-bit shared exponent (&quot;Ward format&quot;) RGB textures:

http://www.opengl.org/registry/specs/EXT/texture_shared_exponent.txt

It&#039;s my new favorite format.  At 32 bits, it has the same bandwidth and cost (on GeForce 280, at least) as RGBA8, you can use it as a render target, and this is enough precision to do HDR rendering and textures.  It isn&#039;t a compressed format, but other than that...pretty much awesome.  Especially since your LCD display only has about 6 fixed point bits per channel anyway :)

-m</description>
		<content:encoded><![CDATA[<p>I recently came across this 2008 OpenGL extension for 9-bit mantissa, 5-bit shared exponent (&#8220;Ward format&#8221;) RGB textures:</p>
<p><a href="http://www.opengl.org/registry/specs/EXT/texture_shared_exponent.txt" rel="nofollow">http://www.opengl.org/registry/specs/EXT/texture_shared_exponent.txt</a></p>
<p>It&#8217;s my new favorite format.  At 32 bits, it has the same bandwidth and cost (on GeForce 280, at least) as RGBA8, you can use it as a render target, and this is enough precision to do HDR rendering and textures.  It isn&#8217;t a compressed format, but other than that&#8230;pretty much awesome.  Especially since your LCD display only has about 6 fixed point bits per channel anyway <img src='http://www.realtimerendering.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>-m</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric</title>
		<link>http://www.realtimerendering.com/blog/7-things-for-january-4th/comment-page-1/#comment-246</link>
		<dc:creator>Eric</dc:creator>
		<pubDate>Wed, 06 Jan 2010 16:40:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=690#comment-246</guid>
		<description>I have to admit I just looked at the YouTube video (my current GPU has enough problems with overheating), so didn&#039;t see the readme. Thanks, guys - getting some explanation makes the demo even better.</description>
		<content:encoded><![CDATA[<p>I have to admit I just looked at the YouTube video (my current GPU has enough problems with overheating), so didn&#8217;t see the readme. Thanks, guys &#8211; getting some explanation makes the demo even better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fabian Giesen</title>
		<link>http://www.realtimerendering.com/blog/7-things-for-january-4th/comment-page-1/#comment-245</link>
		<dc:creator>Fabian Giesen</dc:creator>
		<pubDate>Tue, 05 Jan 2010 17:05:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=690#comment-245</guid>
		<description>Hi, I&#039;m Fabian &#039;ryg&#039; Giesen, one of the coders involved in &quot;the cube&quot;. Chaos (who did the effect) actually wrote a small explanation on our homepage (http://www.farbrausch.de/prod.py?which=167). Start there :).

During the first few parts, the number of triangles being drawn is actually in the hundreds (500 or so). The parts that also &quot;wobble&quot; the grid mesh use a tesselated version with a lot more vertices, but that&#039;s not the reason for the slowdown - the wobbling causes a lot more overdraw in a scene that is already very fillrate intensive and incompatible with hiearchical Z. Not good. And yes, the wobbling uses vertex textures as displacement maps.

No need to do any stencil tricks to get the irregular slices; that mesh is generated from a cube by repeatedly clipping one of the active polyhedrons against a randomly chosen plane.

There&#039;s no particular reason for the Voronoi distortion pattern except that it looked nice. As you correctly suspect, it&#039;s using a texture anyway, and we simply tried a lot of likely (and some unlikely) suspects and this is what ended up looking best overall.</description>
		<content:encoded><![CDATA[<p>Hi, I&#8217;m Fabian &#8216;ryg&#8217; Giesen, one of the coders involved in &#8220;the cube&#8221;. Chaos (who did the effect) actually wrote a small explanation on our homepage (<a href="http://www.farbrausch.de/prod.py?which=167" rel="nofollow">http://www.farbrausch.de/prod.py?which=167</a>). Start there <img src='http://www.realtimerendering.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> .</p>
<p>During the first few parts, the number of triangles being drawn is actually in the hundreds (500 or so). The parts that also &#8220;wobble&#8221; the grid mesh use a tesselated version with a lot more vertices, but that&#8217;s not the reason for the slowdown &#8211; the wobbling causes a lot more overdraw in a scene that is already very fillrate intensive and incompatible with hiearchical Z. Not good. And yes, the wobbling uses vertex textures as displacement maps.</p>
<p>No need to do any stencil tricks to get the irregular slices; that mesh is generated from a cube by repeatedly clipping one of the active polyhedrons against a randomly chosen plane.</p>
<p>There&#8217;s no particular reason for the Voronoi distortion pattern except that it looked nice. As you correctly suspect, it&#8217;s using a texture anyway, and we simply tried a lot of likely (and some unlikely) suspects and this is what ended up looking best overall.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: keldor314</title>
		<link>http://www.realtimerendering.com/blog/7-things-for-january-4th/comment-page-1/#comment-244</link>
		<dc:creator>keldor314</dc:creator>
		<pubDate>Tue, 05 Jan 2010 05:58:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.realtimerendering.com/blog/?p=690#comment-244</guid>
		<description>I bet the Cube is rendered as a simple set of slices, front to back, for each of the three cube face axises.  The shapes would arise from a procedural texture on the alpha channel.  This would also generate a proper z buffer for use in the SSAO in the demo.

The complicated shaped walls later in the demo could be sets of misaligned slices, using the stencil to alternate visibility between cells in order to make the wall boundaries not match.

The warped coordinate system in some of the later sequences looks like it&#039;s done with brute force tessellation of the slices followed by warping in the vertex shader.  This is also consistent with the framerate slowing for those parts, no matter what the resolution.

The idea of it being rendered as a series of slices is also supported in the readme, which mentions the demo as being fillrate hungry.  It also mentions vertex textures, which suggests that much of the noise is seeded through vertex lookups.  It also makes a lot of use of Voroni distance, seeded by most likely a single random point for each cell, probably looked up from a texture - I think I see some repetition.  These are probably in two dimensions, mapped to each slice.

Also in effect are bloom and depth of field.</description>
		<content:encoded><![CDATA[<p>I bet the Cube is rendered as a simple set of slices, front to back, for each of the three cube face axises.  The shapes would arise from a procedural texture on the alpha channel.  This would also generate a proper z buffer for use in the SSAO in the demo.</p>
<p>The complicated shaped walls later in the demo could be sets of misaligned slices, using the stencil to alternate visibility between cells in order to make the wall boundaries not match.</p>
<p>The warped coordinate system in some of the later sequences looks like it&#8217;s done with brute force tessellation of the slices followed by warping in the vertex shader.  This is also consistent with the framerate slowing for those parts, no matter what the resolution.</p>
<p>The idea of it being rendered as a series of slices is also supported in the readme, which mentions the demo as being fillrate hungry.  It also mentions vertex textures, which suggests that much of the noise is seeded through vertex lookups.  It also makes a lot of use of Voroni distance, seeded by most likely a single random point for each cell, probably looked up from a texture &#8211; I think I see some repetition.  These are probably in two dimensions, mapped to each slice.</p>
<p>Also in effect are bloom and depth of field.</p>
]]></content:encoded>
	</item>
</channel>
</rss>