The last few days of experimentation with metaballs got quite messy, so this afternoon I resolved to clean things up. First, I had to fix the compilation errors caused by a corrupted VFX Graph install. I couldn’t remove the VFX Graph package without removing the HDRP package, so I removed that too. For OCD kicks, I also removed several other packages (mostly from Keijiro) that looked cool but weren’t being used. Clutter only when necessary.
I reinstalled VFX Graph, but a few of my graphs were still corrupted. I knew I was on the right track, however, because I could create a new VFX graph asset that worked correctly. Since I still had an older, working copy of my project on my other PC, I logged into it remotely and grabbed the working VFX graphs from there. I was able to directly copy and paste between the VFX Graph editor windows on my two computers!
I re-modified my VFX Graph package in order to fix the compilation errors in my scripts. I also renamed the metaball scripts to match my file-naming conventions (see post on 12/18/23). Digging into the scripts to fix renaming errors showed me some links between scripts I hadn’t noticed before, but I’ll get back to that later.
Once all that was cleaned up, I did some light testing to see if my metaballs mesh now transferred seamlessly to an SDF in the VFX graph. It did not, but I did realize something—when I tried saving the mesh asset and then baking it to an SDF while my scene was running, the SDF output was corrupted. However, when I disabled my BakeSDF() function and tried again, the manual baking worked fine. This makes me think that the SDF Baker doesn’t like being used in multiple places at once, and maybe, it thinks its being used like that in my code.
The metaballs controller script was set to execute in edit mode so that metaballs could be previewed in the editor. The memory leaks occured even when the application wasn’t playing, so I disabled the script’s [ExecuteInEditMode] flag for now until I fix them.