Exciting development! I began testing Keijiro’s recently released ComputeMarchingCubes repo this week with the hope that I might be able to get some working metaballs once and for all. After initially struggling to comprehend how his code even ran in the first place, I noticed (and remembered) he hides his compute shaders from the inspector. What makes his repo so cool and unique is that the marching cubes compute shader is isolated so that other compute shaders can be plugged right into the visualization algorithm. Seeing how simple his random noise compute shader was (less than 15 lines) made me confident that I could maybe get metaballs working (with some help from my trusty LLM buddies). Suffice to say, ChatGPT got me to the gold!
Unlike my last attempt at metaballs, these ones are scaled correctly and can be resized independently of one another.
Another hurdle to clear was grid size. Here’s a clip of me running a test in a 16 by 16 by 8 grid:
One issue I did come across was exceeding the triangle budget. More tris == worse performance, so I’ll need to tread this line carefully.
I’m able to skirt the triangle budget limit by increasing the grid scale. This, of course, comes at the expense of metaball resolution. Another line to tread carefully…
Increasing the grid scale also increases the dimensions of the box the metaballs render inside
The great thing about this implementation (other than the fact that it works) is how straightforward it is. I can determine the actual box size by multiplying each of the dimensions by the grid scale.
I don’t want to get ahead of myself and declare a victory before implementing this into my energy ball project, but this looks extremely promising! Thanks Keijiro!
Tags: unity vfx metaballs shaders marching-cubes optimization gamedev keijiro