I realized that implementing my vacuum effect as-is would undo the user’s ability to “throw” their energy ball because the forces that held it together would dissipate as soon as the user closed their hands. My idea to fix this is by using per-particle attributes to determine whether or not a particle is already part of the energy ball (vs. on its way to it) at the time of the hand close event.
First, I experimented with collision data, since the Set Collision Shape (Signed Distance Field) block has the ability to write contact to a built-in attribute called hasCollisionEvent. However, since this attribute updates on a per-frame basis based on whether or not a particle is currently colliding with a collider, I needed to create a custom attribute, hasCollided, and use it to store a permanent boolean value based on whether a particle has collided with the SDF at any point in its lifecycle. The initial results are promising.
My concern with this approach is that not enough of the particles actually collide with the SDF. You can see in the above video that even many particles that appeared to be part of the ball still moved back to the hands. One unfortunate aspect of the Collision Shape blocks is the inability to simulate collisions without reactions. Even if I set bounce, friction, and lifetime loss to 0, particles still clearly stick to the surface of the shape when they collide with it.
The solution is to use a Trigger Shape block instead. I had no idea such a block existed until I looked at the attribute menu for the Collision Shape block and started playing with the menu options. I created a spherical trigger with a radius set to 1.25x the size of the main sphere SDF. Just look at the difference now…
I also needed to increase my max particle count so that this would stop happening:
I discovered the annoying unitybug of the day when I decided to figure out once and for all why the angular velocity was affecting the visibility of the particles. As I mentioned yesterday, leaving the angular velocity too low caused the particles to disappear near the hands, and removing the angular velocity altogether caused the particles to disappear completely. Cranking the angular velocity to absurd amounts, however, caused weird spaces in visibility between the hands and the sphere. By digging around, I realized that the issue disappeared if I changed the first of the four meshes in my output particle context to something other than one of the shard meshes in Keijiro’s asset pack. Soon after, I realized that none of the meshes other than the first one were even visible at all! I should have realized something was off because each of the mesh’s submesh masks showed a super high int value rather than that weird sectional rectangle toggle thingy (which I have no idea how to use but know should be there).
I fumbled with this for a while but simply couldn’t get my shard meshes working. I soon realized that trying to use more than 1 mesh simply doesn’t work right now. Oh well. Beyond that, using any of the shard meshes in my graph as output’s doesn’t work either. What’s dumb is that I’m able to output shard meshes for any of the simple hand animation graphs, but not on this one. Ugh. For now, I’ll just use the triangle mesh since that shows up and still looks more interesting than a regular circle.
I’ll end this entry with a couple of bug fix. The first is getting my trail distorters to interpolate between the hand and sphere’s radius instead of the sphere’s center.
According to my code, I’m already trying to do this.
Vector3 leftStart = player.leftHandCollider.position;
Vector3 leftEnd = player.sphere.position - player.sphere.transform.forward * player.sphere.transform.localScale.x / 2f;The other needed fix…I can’t remember the other fix. It’s been that type of day.