<story><title>Sphere Rendering: Flat Planets</title><url>https://emildziewanowski.com/flat-planets/</url></story><parent_chain></parent_chain><comment><author>mrsharpoblunto</author><text>The author dismisses cubemaps pretty quickly, but imo it’s the simplest solution &amp;amp; it’s what I did when rendering dynamic gas giants on my own personal project a number of years back* . Using a cubemap doesn’t result in a 6x increase in memory usage, you’re just splitting the texture size from one large rectangular face into 6 smaller rectangular faces, but the total texture detail is the same. The nice part about a cubemap is you don’t have to worry about pole pinching at all + you can use a 3 or 4 dimensional noise function to easily create a seamless flow field for texture animation&amp;#x2F;distortion.&lt;p&gt;* &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.junkship.net&amp;#x2F;News&amp;#x2F;2016&amp;#x2F;06&amp;#x2F;09&amp;#x2F;jupiter-jazz&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.junkship.net&amp;#x2F;News&amp;#x2F;2016&amp;#x2F;06&amp;#x2F;09&amp;#x2F;jupiter-jazz&lt;/a&gt;</text></comment>
<story><title>Sphere Rendering: Flat Planets</title><url>https://emildziewanowski.com/flat-planets/</url></story><parent_chain></parent_chain><comment><author>JKCalhoun</author><text>Reminds me to revisit displacement mapping — probably not going to be a replacement for the problem that author is trying to solve but simpler and kind of fun.&lt;p&gt;I wrote a kind of cool music visualizer for SoundJam perhaps 25 years ago I called &amp;quot;Eclipse&amp;quot;. Input data was an array of levels (probably integers) across some range of audible frequencies — a left and right channel.&lt;p&gt;Think of the eclipsed sun with corona ejections — that was what I was going for. The music data was the &amp;quot;ejections&amp;quot;. The frequency of the data determined where around the disc of the sun it would appear.&lt;p&gt;Over time the ejecta moved away from the sun and soon disappeared as they &amp;quot;cooled&amp;quot; to black — the initial color of the ejecta being white for the strongest signals — yellow, orange, red, brown when weaker. (Think of the black body curve.)&lt;p&gt;I had to keep a circular buffer of the sound data values (an array of arrays) large enough to represent how much time the ejecta would &amp;quot;live&amp;quot; before disappearing to black.&lt;p&gt;In any event, the whole display of the &amp;quot;eclipse&amp;quot;, ejecta, was just a displacement map. I had pre-calculated a bitmap where the value for each &amp;quot;pixel&amp;quot; was an offset into the buffer of sound level values. &amp;quot;pixels&amp;quot; close to the surface of the sun would have offsets to the new data coming in, pixels further out would have offsets into the tail of the buffer that was about to expire. With the circular, radial aspect of the ejecta, there was some math involved in generating the displacement values in order to map from essentially a radial space to a cartesian one.&lt;p&gt;With that established as described, the main loop simply pulled in new sound values, over-wrote the oldest values in the circular buffer with the new and then iterated row and column-wise over the displacement map, grabbing the corresponding sound data value, mapped it to a color in a fixed palette and pushed that color into display buffer.&lt;p&gt;Although not as &amp;quot;flashy&amp;quot; as other visualizers, there was I thought a calm beauty to it. And it very much represented the music data (you know, as opposed to later visualizers where, even when presented with silence, they seemed to be unable to settle down).</text></comment>