There is no obvious correct strategy (to me) when it comes to collecting data for this current experiment. Ideally, I’d replicate the situation from the previous experiment, a metaball would stop scaling (and for this case, moving around the scene) once its comparison sphere overlaps its size. The rest of the metaballs would still move around, however, until their spheres did the same. If, during the course of this, a moving metaball crossed path with a stopped one, the stopped one would need to scale again to match its new larger radius. Only once all the metaballs stop moving would I log a data point.
The above strategy seemed tedious to implement and slow to collect data for, so I opted for what I hope is a slicker method. I realized that I can design my model in a way that it only predicts the size of one comparison sphere at a time, which would let me collect data in a way where I only need to track the size of one comparison sphere at a time. So, whenever a metaball and its comparison sphere overlap sizes, I log the size of that comparison sphere as well as the sizes and positions of all metaballs at the time of the swap. In my data entry, I move the index of the metaball corresponding to the comparison sphere to 0, so that the metaball relevant to the sphere’s size is always first. The order of the other metaball indexes doesn’t really matter. I’m assuming that keeping the metaball relevant to the comparison sphere at a fixed index in my data will help my model discover a pattern more easily. Hopefully, it’s smart enough to do that because otherwise this method probably won’t work. The great advantage of this method outside of its simple setup is that I can collect data much, much quicker, since I never really need to pause the movement or scaling in the scene.
I’m not quite sure if there’s a conventional way to set up vector values in a CSV file, so I opted for another simple technique. The first column corresponds to the comparison sphere’s size, and each subsequent column is a sequence of a metaball’s radius, x position, y-position, and z-position. Here’s what that looks like:
combined_size,m0_r,m0_x,m0_y,m0_z,m1_r,m1_x,m1_y,m1_z,m2_r,m2_x,m2_y,m2_z,m3_r,m3_x,m3_y,m3_z,m4_r,m4_x,m4_y,m4_z,m5_r,m5_x,m5_y,m5_zIt’s a lot of columns, but this way I’ll be able to easily fill in tensor values once I import the CSV to python. It’ll be like dealing cards around a table, except each first card gets placed in the middle of the table, and each person playing receives four cards in a row. Hehe.