Yesterday when taking my measurements, I was just doing approximations by eyeing a sphere and metaball side by side. Today, I overlayed the two by setting each to the same position, and then adjusted the metaball generator’s target value parameter so that a sphere of scale 1 and and metaball of radius 1 perfectly overlapped each other. It turned out my target value needed a little refining. Once I set it to 2.54, a sphere of size 2 and a metaball of radius 2 perfectly overlapped, and same with 3 and 3, 4 and 4, etc. Here’s what overlapping looks like:
As you can see, the meshes render on top and below one another at different spots. Now that scale was accurate, I redid the tests from the night before, and found a linear relationship with the data!
| # Metaballs Merged | Init. Radius = 1 | Init. Radius = 2 | Init. Radius = 3 |
|---|---|---|---|
| 0 | 1 | 2 | 3 |
| 1 | 1.295 | 2.59 | 3.885 |
| 2 | 1.425 | 2.85 | 4.275 |
| 3 | 1.51 | 3.01 | 4.515 |
| 4 | 1.56 | 3.12 | 4.68 |
| 5 | 1.60 | 3.20 | 4.80 |
ChatGPT and Claude gave me two different formulas for plotting the data. ChatGPT used an exponential decay model
while Claude used a quadratic polynomial equation
Intuitively, ChatGPT’s logic makes more sense since the radii increases decrease as the number of metaballs merging together approaches infinity. The quadratic approach seems to work just fine, however, with the data I provided. Either way, the real issue is that while I can estimate the combined radius size for metaballs of the same radius, I have no idea how to do so for metaballs of different radii!
One idea I have is to just pretend all metaball radii in a merge are the size of the largest radius involved. Scaling might be a bit exaggerated, but I wanted to add additional scaling anyways. The good news is that when the Spherical Collision node’s radius is larger than the metaball’s radius, the particles conform the sphere’s larger radius shape without any distortion from the inner metaball.
Another thing I noticed is that when the collision sphere’s radius is set to slightly less than the metaball’s, it helps to remove attraction vortexes without introducing some of the weird pooling issues I wrote about in yesterday’s experiments.
If I make the collision sphere’s radius too low, the attraction vortexes return. And ergo the previous issue arises where I need to know the size of the metaball to determine what size to make the sphere. Ugh. I need to collect more data, this time between radii of different sizes.
At first, I tried manually collecting data. After tediously collecting 66 samples, I remembered that doing a task over and over again is something a computer should do instead of me.
I had ChatGPT write me an algorithm for getting the outer bounds of the metaball mesh. Then, I linked the size of a sphere at the same position with the bounds size. Unfortunately, due to the low resolution of the voxel grid and the way the algorithm worked, the reported bounds did not change at the same rate that I changed the scale. Instead, the bounds would step with the voxels in a jittery fashion.
My solution was to only document the individual metaball sizes when the combined bounds scale changed from its previous value.
Manually scaling the metaballs and logging their scale in a spreadsheet still consumed more time than I cared to spend, however, so I wrote code to automatically scale the metaballs randomly and write the data to a CSV file. Now we’re cookin’!
With all this data collected, I now hope to extract an equation from it that lets me input a set of radii sizes and return a combined mesh size. I’ve been taking a machine learning course—it’s time to put these new skills to work (next time I log on -_-)!
One thing that’s been annoying the hell out of me is the fact that I’ve lost my connection between Unity and Visual Studio. I think it’s been going on since I switched over to Cursor, but I can’t get it working in either application now. I need to fix this ASAP before doing anything else.