@snacktime based on my testing, even if there is partitioning done on Unity’s end, it’s not efficient for constant runtime updates to the heightmap. If you’re doing small area updates to a huge heightmap, partitioning is the way to go. I’d go further and say that making your own collision API specificly for the terrain would also drasticly improve performance, simply because you can use the already gathered new data without needing to go through SetHeights() which incurs a high performance penalty to use at runtime or SyncHeightmap() which stall the CPU to wait on the GPU. However, before creating your own libraries, you should consider how big the deformation is at any point during runtime.
As far as my experience with the terrain API, assigning new 33x33 heightmaps to 33x33 terrain after you have calculated them has a penalty of 0.1-0.2ms on my i7-5820k via SetHeights(). Considering the high ms point, thats about 10k heightmaps for 2ms, or 3k heightmaps for 2ms per 1GHz main core processor speed, since the updates are not multithreaded. If that’s still in your ballpart, i’d stick to Unity’s terrain.
Here’s a few links where i ran into a similar problem:
Here’s a workaround by @isaac-ashdown for using NativeArrays. The workaround will still incur a heavy penalty, not because of the processing speed, but because once you call the SyncHeightmap() method, the CPU will stall to wait on the GPU, which can be from 0.5-15ms. Some of the lag correlates to the amount of data being retrieved or how much work the GPU has, though a lot of times, it’s just random. An Async SyncHeightmap() option to gather the heightmap would be able to fix a lot of the performance issues relating to runtime heightmap deformation, but it hasn’t come yet.
Here’s a partitioned version of the terrain in action. Dark red areas are the partitioned terrains. Blue checkered area is a single terrain manipulated via TerrainData.CopyActiveRenderTextureToHeightmap():
