<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>slow polymathy</title>
    <link>https://hubbardian.io/</link>
    <description>Recent content on slow polymathy</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>Ian Hubbard © {year}</copyright>
    <lastBuildDate>Sun, 12 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://hubbardian.io/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>faster signing, xSDF/1</title>
      <link>https://hubbardian.io/fieldnotes/faster_xsdf_intro_1/</link>
      <pubDate>Sun, 12 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://hubbardian.io/fieldnotes/faster_xsdf_intro_1/</guid>
      <description>&lt;!-- &#xA;I am investing a bit into xSDF and I want to make it much faster. &#xA;&#xA;The two main speed bottle necks: &#xA;- The unsigned per point to triangle distance queries (currently AABB)&#xA;- the signing method itself (currently solid angle signing)&#xA;&#xA;I am planning on some big changes, firstly moving the point-triangle unsigned queries from the current brute force with some acceleration via axis-aligned bounding box (`AABB`) method pruning, which is already quite fast in a vectorized formulation. I will change to an Bound Volume Heirchy (`BVH`) method, which apparently should be faster. BVH in general is quite sequential as a method even if vectorized, so I aim to actually try and implement something more gpu parallizable, which I think Linear BVH (`LBVH`) from [Kerras](https://research.nvidia.com/sites/default/files/pubs/2012-06_Maximizing-Parallelism-in/karras2012hpg_paper.pdf) (also these refs., 1 and 2) would be the gpu way forward. Originally written in CUDA, I will implement in xSDF as pytorch. Also, my first introduction to `Morton Codes` and using a `XOR` function...&#xA;&#xA;&lt;!-- Moving on to tackle the signing, I will also couple the LBVH traversal with a flood-filling method. This should help speed up the whole thing even further by rapid signing the regions further from the geometry neighbour band (like the far-field) quickly. For the near geometry, I will not sign by flood fill sign, although it is faster, it is not exact, but I do want to swap the solid angle signing for something faster. I have found this great paper by Burill et al. outlining a Fast Winding Number (FWN) method which I want to get a vectorized gpu friendly version working. --&gt;&#xA;&lt;!-- &#xA;Moving on to tackle the signing, I want to swap the solid angle signing for something faster. I have found this great paper by Burill et al. outlining a Fast Winding Number (`FWN`) method, which I will also vectorize.&#xA;&#xA;Overall, these two additions should improve speed significantly with parallelize tree traversals on the LBVH and faster signing.&#xA;&#xA;&#xA;### References&#xA;Tero Karras, &#34;Maximizing Parallelism in the Construction of BVHs, Octrees, and k-d Trees&#34;, High Performance Graphics (2012) -[HERE](https://research.nvidia.com/sites/default/files/pubs/2012-06_Maximizing-Parallelism-in/karras2012hpg_paper.pdf)&#xA;&#xA;https://devblogs.nvidia.com/thinking-parallel-part-ii-tree-traversal-gpu/&#xA;&#xA;https://devblogs.nvidia.com/thinking-parallel-part-iii-tree-construction-gpu/&#xA;&#xA;G. BARILL, N.G. DICKSON, R. SCHMIDT, D.I.W. LEVIN and A. JACOBSON, &#34;Fast Winding Numbers for Soups &amp; Clouds&#34;, ACM Transactions on Graphics, Vol. 37, No. 4, Article 43. (2018) -[HERE](https://www.dgp.toronto.edu/projects/fast-winding-numbers/fast-winding-numbers-for-soups-and-clouds-siggraph-2018-barill-et-al.pdf)&#xA; --&gt;&#xA;&lt;!-- ---- --&gt;&#xA;&lt;p&gt;I&amp;rsquo;m investing a bit in &lt;a href=&#34;https://github.com/srcterm/xSDF&#34;&gt;xSDF&lt;/a&gt;, a GPU numerics side project to convert .stl geometry files into signed distance fields for JAXFLUIDS&amp;rsquo; levelset.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Piecewise grids /1</title>
      <link>https://hubbardian.io/fieldnotes/piecewise_grids_1/</link>
      <pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://hubbardian.io/fieldnotes/piecewise_grids_1/</guid>
      <description>&lt;/br&gt;&#xA;&lt;!-- # xSDF new feature, generation of piecewise grids --&gt;&#xA;&lt;!-- &lt;/br&gt; --&gt;&#xA;&lt;p&gt;Some new feature work on &lt;a href=&#34;https://github.com/srcterm/xSDF&#34;&gt;xSDF&lt;/a&gt; over the Easter long weekend.&lt;/p&gt;&#xA;&lt;p&gt;I haven&amp;rsquo;t written anything about this project yet, but it is basically a signed distance function (SDF) generator, written in PyTorch for GPU acceleration. I wrote this a while back when I was trying to get custom geometries into JAXFLUIDS (something else I haven&amp;rsquo;t written about), which requires the geometry to be converted to an SDF for the solver&amp;rsquo;s levelset. I didn&amp;rsquo;t like what I could find for this conversion, and trimesh (python) was super slow, so I just wrote one.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Fieldnotes</title>
      <link>https://hubbardian.io/fieldnotes/fieldnotes/</link>
      <pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://hubbardian.io/fieldnotes/fieldnotes/</guid>
      <description>&lt;p&gt;This is just a note about the point of this new &lt;code&gt;fieldnotes&lt;/code&gt; section. Basically I want to have a notebook for quick posting of ideas, progress, thoughts, whatever. I will leave the &lt;code&gt;posts&lt;/code&gt; section for more polished posts. I might even merge the two later on.&lt;/p&gt;&#xA;&lt;p&gt;For now this is an experiment to see what is and isn&amp;rsquo;t working. I can say atleast, writing long-form polished posts isn&amp;rsquo;t, so I hope to break it down a bit and be able to write more consistantly with less friction.&lt;/p&gt;</description>
    </item>
    <item>
      <title>bits, bytes &amp; numerical sound / part 1</title>
      <link>https://hubbardian.io/posts/quest__soundbytes/</link>
      <pubDate>Thu, 19 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://hubbardian.io/posts/quest__soundbytes/</guid>
      <description>&lt;h2 id=&#34;building-an-acoustic-solver-from-scratch&#34;&gt;Building an Acoustic Solver from Scratch&lt;/h2&gt;&#xA;&lt;p&gt;This is the first in a series where I document building an FWH acoustic solver, a differentiable, GPU-native tool for predicting flow-induced noise. The choices, the detours, and what I learn along the way.&lt;/p&gt;&#xA;&lt;p&gt;This project is also a means of learning and applying a bunch of ideas to see how they could work, which will later inform some of my other projects down the line. FYI, nothing is finished and the code base is still cooking.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Hello, World</title>
      <link>https://hubbardian.io/posts/hello-world/</link>
      <pubDate>Wed, 11 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://hubbardian.io/posts/hello-world/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve been heads-down for a while now, building, experimenting, and learning across a bunch of different directions. Most of what I&amp;rsquo;ve picked up lives in my head, scattered across half-finished repos and random quick-notes. This blog is where that changes.&lt;/p&gt;&#xA;&lt;p&gt;The plan is simple. As I work, I write. Not polished tutorials or finished showcases, but honest documentation of what I&amp;rsquo;m building, what I&amp;rsquo;m learning, and where things break. Some posts will be technical deep dives. Some will be shorter reflections on process. I&amp;rsquo;ll mostly write about side and personal projects, though some of my relevant professional engineering work will make its way here too.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
