The goal of this task is to discuss the current status of Dyntopo as well as to evaluate the future development of this feature.
Currently in Blender we have the Voxel Remesher, which covers the same use case as Dyntopo and it does not have major issues that affects its functionality. Because of that, I don’t consider that developing Dyntopo specific features right now is a priority.
Dyntopo use cases
- Some brushes that produces big shape deformations (like snake hook) are much more intuitive to use with Dyntopo than with the voxel remesher.
- Some new clay brushes look much better and more detailed with the Dyntopo triangulation enabled. This does not mean that they are bad with static topology, but supporting this feature adds extra polish to the software.
- Dyntopo is the only way to work with dynamic topology in surfaces that do not represent a volume (like cloth). Quadrilfow + Multires should work for these use cases, but currently Quadriflow is not 100% reliable.
Current Issues
- Dyntopo performance is not enough, even for stylized models. It can only be used for sketching simple shapes. Regardless of the hardware, Dyntopo starts lagging at around 150k vertices, and it becomes almost unusable at 500k. When working with the voxel remesher, it is possible to work on models up to 20M vertices. In order for Dyntopo to be usable at the same level as the voxel remesher workflow it needs to be in the order of 30 times faster, so I don’t think that any of the optimizations listed in T68873 are enough for that.
- When developing new features I’m always testing them with the Voxel Remesher workflow, but some people keep using Dyntopo as their primary dynamic topology system. This makes that almost all bugs I fix during the development of new features are related to Dyntopo compatibility and not to the feature itself, which does not make much sense as Dyntopo is something that is not active being developed.
- The voxel remesher provides almost the same functionality as Dyntopo and it is much easier to maintain because it is completely decoupled from the sculpting code. With the development of the volume objects and its modifiers stack, it will also get new features automatically without dedicating extra time to it.
- Dyntopo was always explained as an optimization (it adds geometry detail only when it is needed) when actually it is much slower than using regular meshes or multires and it takes a much more memory. This causes a bad impression and confusion on users as they usually work with Dyntopo without being aware of the huge performance implications it has, so they think that the regular sculpting performance in Blender is that slow.
Solutions
- Deprecate Dyntopo: Dyntopo is a feature that was not developed for years, but it exposed in the UI next to the Voxel Remesher. This may confuse users as they may think that both features are equivalent, but one of them is being active developed and supported and the other one is not and it has functional issues. In order to avoid this, we could explicitly say that Dyntopo is deprecated or a experimental feature. In order to do that, a possible solution could be:
- Remove the global Dyntopo toggle and hide it as a experimental feature.
- Add a per tool Dyntopo option in tools where it creates an effect that can’t be easily achieved with the remesher (snake hook, for example).
- Replace Dyntopo with volume sculpting: Supporting levels set in the volume object is already planned and it should be possible to add a sculpt mode to edit level sets. I don’t know what kind of performance we can expect from level set sculpting or how much work would it be supporting the current tools in that mode. We can wait until we can test it and if performance is enough, we can simply remove Dyntopo and replace it which a voxel based sculpting solution.
- Design some structural optimizations: I think that using BMesh as the Dyntopo mesh structure is too much complexity. Dyntopo only needs to store triangles, split and merge them, so it does not need a structure that can represent all kinds of ngos, loose edges, non manifold geometry... This does not mean that we should remove the PBVH_BMESH code, as it may be useful in the future for some other kind of tools that may need to do topology modifications or more advanced mesh queries. Probably using a much simpler mesh structure specifically designed for this use case could improve performance and memory usage, but I can’t evaluate the scope of this project or the time that is needed to make it.
