Dynamic-topology sculpt mode is in trunk

dyntopo-trunk-00
Sculpted from a single quad. I swear my real-life handwriting is better.

It’s finally done! Huge, huge thanks to everyone that helped out with test builds, bug reports, suggestions, code review, donations, encouragement, and of course awesome test images! The models and renders in the Dyntopo tests thread on BlenderArtists are really something to see.

Although dyntopo won’t be in an official release of Blender until 2.66 comes out in February, any test builds made from trunk r53450 or later will have dyntopo. Please check out the documentation, play around with the tool, and report any bugs you find to the Blender 2.6 bug tracker. Thanks again everybody!

A change to the dynamic-topology branch workflow

I’m switching to a slightly different git workflow for my dynamic-topology branch: instead of force-pushing rebased updates to a single dyntopo branch, each push that involves a rebase will go into a new branch with a numbered suffix.

If you are building dyntopo, you won’t need to do the “git checkout trunk && git branch -D dyntopo-slim && git pull && git checkout dyntopo-slim” dance anymore. Instead you can just do “git fetch” followed by “git checkout dyntopo-N“, where N is whatever the latest branch is. Currently the latest branch is dyntopo-2, but I rebase frequently with dyntopo so that will change.

Update: for people who were having trouble building, it looks like there was a build problem in trunk with OSL disabled. The dyntopo-6 branch has latest trunk which should fix that issue.

Being a responsible developer means not committing code

A common question I’ve seen is “why isn’t dyntopo in trunk”? Sometimes it’s phrased more as a statement: “dyntopo is no more unstable than some other features in trunk, so it’s time to commit it!”

I want to reassure folks right now: there’s no secret cabal keeping dyntopo out of trunk. It hasn’t been code reviewed and found wanting. Rather, I don’t want it in trunk yet. As the owner of the code, it will be my responsibility to maintain the code more or less forever. I need to handle any bugs the code creates. I need to make sure the code is comprehensible for other developers. And in order for sculpt development to continue, I need to ensure that new features don’t make the code harder to develop further.

There is code I wrote years ago for Blender that still causes me (and other developers) headaches. I try to reduce the chances of that happening again by doing very careful review of my own work, writing documentation, getting user feedback, getting the code reviewed by another dev like Sergey or Brecht, and only then committing it.

I want to be clear that I don’t mind people asking the question “why is dyntopo not in trunk?”. Most people fully understand that I have a job and limited time for doing Blender work, and are asking an honest question about the process. Hopefully this post clears up any confusion.

Time for some more dynamic topology testing

Although I’ve been quiet on the website, I’ve continued work on dynamic topology sculpt mode. All of this work has been of the non-exciting variety; there are no new features, just cleaner and more robust code. In particular it took a while to figure out how to get everything in the undo system to fit together, but it’s working pretty well now in terms of stability. Undo/redo of masking and hiding works now too. The smooth shading toggle is more robust, the info header stats show new vertices and faces created during sculpting, and the mesh wireframe toggle is fixed.

With the code now much closer to being merge ready, I’d like to get some user testing to shake out bugs and find things I’ve overlooked. I’m particularly interested in ways to crash dynamic topology, problems with undo/redo, and problems with saving or loading. If you find a way to reliably reproduce an issue please describe it in the comments. (I’ve been keeping a list of test cases for undo/redo, that’s the sort of steps-to-reproduce I need.) Please check that you have an up-to-date build before reporting issues. The code is still in the dyntopo-slim branch here: https://github.com/nicholasbishop/blender/tree/dyntopo-slim

Another thing I could use a hand with is getting an icon for the “Enable Dynamic” button. Right now it’s reusing the remesh modifier’s icon as a placeholder.

There is still a significant amount of work left to do before dynamic topology can be merged into trunk, but we’re getting closer now. Thanks to everyone who has helped the project along.

Update: just pushed (4:03UTC, Dec 4) a fix for a crash when collapsing edges.