Customizing Input and Mesh Handling in Unity

Hello!

In this devblog, we’re diving into some of the customization work we did on a Unity Asset Store package to better fit our needs. We want to talk about two big changes: how we rewrote the input system, and how we added custom logic for mesh handling, including but not limited to classification, numbering, and bounding box validation.
If you’re working with managing dynamically generated meshes, this one might pique your interest.

The Base Asset

Our starting point was a unity asset store package. Namely: Dynamic Mesh Cutter, created by Philip Beaucamp. This package handles collision cutting behavior and mesh generation via a flood fill algorithm. The base controls are mouse and keyboard the cutting was done via the update function in unity, this created a lot of new meshes and added the issue of 2 Dimensional meshes. Not only did it crash Unity, if the pieces cut were too many and too small, it also was unfit for our purpose of splitting meshes in two.
What we needed was more control over player input collisions and generated meshes, for validation, calculation and movement of cut meshes.

Input Customization

The original asset used Unity’s new Input System, but everything was hardwired to specific scenes and behaviors. Since we already had our own modular, persistent player system (detailed in our other devblog), we needed to restructure how input was handled.

What We Changed:

• Controller support: We swapped mouse input for controller-based actions using Unity’s Input System.
• Collision based cutting: The cutting function was refactored to trigger only once per collision, instead of continuously active or on button press.

This means we could use the asset’s functionality without being tied to its structure.

Mesh Generation: Adding Intelligence

The asset did a great job generating meshes, but we needed more than “generate mesh here.” During testing, our system was generating a large number of meshes dynamically. As development progressed, it became increasingly difficult to track their origins, understand which ones were important and decide whether some of them should exist at all. Many turned out to be tiny fragments that created bugs within Unity and added no gameplay value.

Our Solution: Automatic Mesh Classification

Every time a new mesh is about to be generated, a custom function runs to manage the entire process. It begins by checking the mesh’s bounding box to ensure it has enough 3D volume. If the mesh is too flat, effectively 2D, the script cancels its creation.
These kinds of meshes often cause issues in Unity. If the mesh passes this validation, the script attaches a custom component called GeneratedMeshLogic, which marks it as a tracked object. At this point, the mesh also receives a unique index.
This makes it easy to reference later, whether for debugging, grouping, or preventing the same area from being cut repeatedly.
Furthermore, we add physics components like colliders and rigidbodies. To ensure intractability as soon as it is created in runtime.
Lastly, we added scripts for movement and in game logic to the newly generated meshes.
With this step-by-step process, we maintain clean scenes, reduce unnecessary overhead and ensure that only meaningful, usable meshes are kept.

Final Thoughts

Modifying asset store packages can be a challenge, especially when they come with their own logic and structure. But with some editing and clear architecture in place, it’s possible to bend them to your will without rewriting everything from scratch. The changes mentioned above helped us gain full visibility and control over run-time-generated content. While also reducing unnecessary clutter from invalid or tiny meshes.

We’ve now got a player system and mesh pipeline that work hand-in-hand to ensure persistent, modular, and self-cleaning.

Thanks for reading!

Daniel