Spline Mesher Pro is built on a foundation of the C# Job System and Burst Compiler. Which results in highly optimized native code running in parallel on multiple CPU cores. Functionality has been built on top of Unity’s native Splines framework to use it with this technology, which greatly enhances its use beyond Unity’s original scope. There is no asset on the store comparable, which is ready to take advantage of!

Mesh generation as a whole is up to x50 faster than in Spline Mesher Standard

Splines

Sampling splines is slow, even through Unity’s provided job-friendly method. Therefor this asset employs a custom caching solution to fork up the sampling cost just once. After which, sampling the cached data is extremely fast in comparison (up to 26 times faster).

Spline alterations

Whenever a Spline changes, it’s required to cache it by reading it out over it’s entire length and convert the data into a format usable by the Job System (eg. native arrays). Once this process has completed, the spline data will be used extremely efficiently for mesh generation.

But, the process itself is relatively costly. This means: rebuilding that happens based on spline changes is slower than just rebuilding by calling the Rebuild() function or changing parameters in the inspector.

Procedural splines

⚠️ If you are creating one or more splines through script it is highly inefficient to call SplineContainer.Spline = newSpline (overwrite). This is because it will first trigger the removal of a Spline (causing its related mesh/cap objects to be destroyed) before it is added again (objects/arrays being recreated from scratch).

✅ Instead use SplineContainer.Spline.Copy(newSpline). This will count as a spline change, which is far more efficient. You will find that the performance difference is significant. Adding, removing or altering Knots (on a spline already in the container) also counts as a “change”.

Garbage collection

In the Editor and in Development builds the mesh generation as a whole yields some garbage collection. This is related to some QoL processes.

For example, all the created meshes are neatly given a name, rather than appearing blank. This is to make it possible to identify them in something like a build report or the memory profiler.

In a regular build this would not be the case and peak performance is maintained.

Runtime mesh generation

By and large, this asset is designed as a level design and world-building tool. Resources used during mesh generation are disposed of once the mesh is built, rather than being kept in memory for repeated regeneration. This keeps memory usage low and avoids long-lived allocations.

Can you create a snake-like mesh that deforms in real time? Absolutely, simply modify the spline knot positions through script!

However, CPU performance will not be nearly as efficient as using a rigged mesh or a GPU-based deformation system. In practice, continuous spline mesh regeneration can easily consume 10–20% of a typical frame budget (≈16.6 ms at 60 FPS).

This is largely due to the flexibility of the Unity Spline framework and the design goals of this asset. It prioritizes extensibility and functionality over minimal, highly specialized performance. A custom solution written specifically for a single use case will usually be faster.

Practically speaking, effects such as moving tentacles or physics-driven bridges are possible. However, in production games these are typically implemented using rigged animations rather than runtime spline mesh deformation.

Where this tool excels is procedural generation. If you need to generate landscapes, roads, or other spline-based structures at runtime, meshes can typically be built in milliseconds rather than seconds, making runtime generation entirely viable.

Footnote

This tool is developed for a wide range of use cases and experience levels. It favors flexibility and user-friendliness. Whilst being highly optimized, this does come at the cost of bare bones performance in some cases.