BMesh undo and RangeTree

I’m continuing to work on the BMesh logging system that will provide undo/redo for dynamic-topology sculpting. One aspect of this logging system is assigning unique IDs to elements. In order to do this efficiently, I wrote a small C++ library to efficiently¬†store and query non-overlapping ranges. This code is now used in the bmesh-undo branch¬†to keep track of unused IDs. Since the code is fairly generic and might be useful elsewhere, I’ve pushed the RangeTree code into its own repository on Github.

Another recent change in the bmesh-undo branch is an easier way to examine the BMesh log. I added a new view to the outliner which shows changes to the mesh while in edit mode:

This is of course just a temporary debugging tool, not something that would be released. Note that low-level actions like mesh-element deletion and flag setting are now nicely grouped into high-level actions like “Translate” and “Extrude Region and Move”. Pressing CTRL+A/CTRL+SHIFT+A while in edit mode will now step back by high-level actions, and seems to work fairly well. (Again, the CTRL+A hotkey is just a temporary debugging tool.)

Back on the dynamic topology side, I am continuing to make updates to integrate the BMesh logging system with sculpt’s undo system. It is starting to work a bit, but still lots of glitches and crashes to deal with yet. I’m hoping that by improving the testing tools in the bmesh-undo branch I can work out a lot of these issues separately from dynamic-topology sculpting.

2 thoughts on “BMesh undo and RangeTree”

  1. Looks like excellent work being done here! Will this system help phase out the old undo method, which if I remember correctly, loads in the entire file again.

    1. The Blender-wide undo function indeed stores a copy of the entire file, however edit mode (both pre- and post-BMesh) have a separate system that stores a copy of the entire mesh after each action.

      Storing a copy of the mesh is more efficient than storing the entire file, but of course there are many mesh actions for which it is still quite inefficient. For example, adding a single vertex to a million-vertex mesh requires storing a million and one vertices. With the BMesh logging system, it would only record that a single new vertex was added at coordinates XYZ, which is much more memory efficient.

      To answer your question, this method might someday replace the current mesh undo system, although probably not any time soon.

Leave a Reply

Your email address will not be published. Required fields are marked *