Well, I couldn’t exactly bring my Kinect to work, but I had to work on something…so I worked on the metaballs again, alright? Forgive me Lord, but also tell me how FREAKIN SICK THIS IS!
I was able to make the sphere’s look more 3D at their larger scale by increasing the spread of particles along the Y and Z axes.
That jitter from the other day doesn’t seem to be present anymore, either. Hopefully it stays gone. Also, I realized that I accidentally used the VFX graph from my Mesh VFX Design scene for the metaballs. Progress was not lost! I had duplicated the original VFX graph asset when I created the metaballs scene (with the intention of using said duplicate with the metaballs), so I just swapped the assets between scenes. Afterwards, my original regular-sized player bodies look and behave how they should, too.
Now that the jitter is gone, I need to fix the scaling of these metaballs when they merge. I’m positive that scaling them works since I did it successfully in my dev log on 4/19.
Doing testing on the scaling of these metaballs and it seems like the maxRadius property actually does control the max radius of each metaball. The scale property, however, is not behaving as one would expect.
Notice how scaling one player body scales the other one as well. Well. Well well well… It looks like we have a case of superposition on our hands. This suggests that the index positions of the metaballs within the metaballs array are not consistent.
This neat visual was the result of a failed attempt to conditionally call code in FixedUpdate() from within Update()
I’ve confirmed that NOPE, there is no superposition going on. It instead seems that the scales of all the metaballs are linked, as scaling up one also scales up the other. I haven’t dug into the metaball algorithm’s code (and was hoping I’d never have to), but this seems to have once again moved to a place that’s out of reach. Unfortunate, but after swiftly caving in my commitment to ignore the metaballs until the other components of the project are tested and ready, I now have even better reason to reinstate it.
I have to ask myself, though, if I really need scaling. The metaballs already scale when merging, but I’d be sacrificing the ability to control player scale using the hands. To sacrifice scale or blobbiness? That is the question.
Just kidding…BYE METABALLS (for now :’())
In trying to fix the metaballs, I actually found an issue in my player scaler code. I’d been forgetting to account for the pulse sizes of merging players when calculating the distance to start scaling at.
I’d like to refine the attraction of the particles to the closest player body, because the presence of other bodies sometimes distorts the sphere shapes significantly. I tried linking the average particle lifetime to the distance between the hands, in effect giving the particles less time to bounce off the SDF body and careen toward another player, but other player bodies still factor too much into a particle’s direction. I’d like to avoid breaking up my single VFX graph into individual graphs for each player, but honestly, I might have to if I can’t find a better way. The original experience ran just fine using that approach, and implementation would only really require removing the mesh combiner script.
Fixing the particle bounce is the best way I can think of enhancing this post-metaball, blobless-but-still-morphy experience. I might be best suited to apply both approaches simultaneously, because giving each player an individual VFX graph ensures the spherical shape of each body, and having a combined graph allows for more interplay between players.
Tags: unity vfx metaballs particles debugging gamedev scripting