Developed in Unity
 Joined July 2019 – Present

Tablecraft is a VR title that focuses on discovering elements of the periodic table. Players would combine different elements in the form of cubes to create objects based on those elements (i.e. a sodium combined with a chloride element would create salt) to fulfill objectives and gain even more elements. My role for the project is to create and implement particles and shaders optimized for the mobile VR space. Other tasks involved rigging and creating the animation pipeline for integration from Maya to Unity.

Visual Effects

For visual effects since we were developing for mobile VR there were a lot more restrictions to keep in mind when such as:

  • Limiting texture sizes to 512 x 512 maximum.
  • Grayscale packing.
  • Utilizing texture sheets/atlassing.
  • Pooling effects after they’ve stopped playing.
  • Using minimal tri-counts for mesh particles.
  • Keeping the emission rate of particles at reasonable amounts.
  • Restricting use of vertex animated shaders.
  • No post-processing.
For the visual style, the effects are simple as the game has a very cartoony aesthetic. So simple shapes and iconography are used for these effects to stay consistent with the simplicity of the overall aesthetic. Many of them used mobile friendly shaders. Because of the simplicity of the renders, this meant the composition of the effects had to carry a bit more their weight in order to really make them satisfying. I approached this utilizing animation principles and some basic color theory to really make the particles an impactful part of interacting with the environment.

Animation Pipeline

Since we were working in VR, we had to do our best to avoid using expensive animation techniques such as skinned mesh renderers if possible. For our mechanical assets we mostly used nurb curve controllers with constraints to animate them with and then we would export the FBX with the animations baked in.

This would prove to be effective until it came to adding and/or updating animations later on. Since we’re not using a skeleton to store all the animation data, instead of being able to export new animations to a skeleton and just import that animation data into the project, we had to import new FBXs with that animation baked in. Thankfully once we had the FBX in the project it is actually possible to duplicate the animation file so not only is the animation data separate from the FBX, but this duplicate file becomes writeable allowing us to adjust the key frames if necessary and add/remove events with ease.

For implementing I used many of Unity’s animation utilities such as:

  • Avatar Masks: These are used to mask out parts of the animations so only certain parts animate with the key frames, this has been useful for our mechanical assets with many moving parts as it lets us mask out individual parts to animate under certain conditions without needing to separate and edit the FBX itself.
  • Animation Layers: Unity’s Mecanim Animator supports animation layers which work similarly to other layer concepts where animations in certain layers can add or override animations in other layers which I’ve utilized so that if certain parts are supposed to animate under certain conditions they can do so separately regardless of the animations occuring in other parts of the asset
  • Animation Events: Ways for animations to trigger functions in code on the attached animator object, this is utilized to help pass information along the animations so that certain particle effects can trigger at certain points in the animation.
  • State Machine Behaviors: A Self-contained method to access parameters in the animator without needing a separate script to pass in updates. I currently use this method to check if at certain states the machine should play an idle animation if enough time has passed.