Blender – nicholasbishop

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.

Symmetrize in trunk

The symmetrize operator is now in trunk, r51356.

Since the 2.64 release, I’ve been getting a few of the commits from the dyntopo branch finalized and into trunk. The symmetrize operator is a nice independent piece of code from dyntopo, much as the convex hull operator was an independent piece of the skin modifier.

Note that during the code review for symmetrize some fixes were made; hopefully it should work better with dyntopo now. In particular, there was a bug that caused small unattached faces to hang around the plane of symmetry. That should be fixed now.

Thanks to Brecht for reviewing the code.

If you find any bugs, please report them in the regular Blender bug tracker.

Development continues on dyntopo as well. Most of the work is still related to the undo system, but there have been other stability fixes and code cleanups as well. Of note is that the layer brush no longer crashes.

Initial push of updated dyntopo undo code

As mentioned last week, I’m working on a different approach to handling undo in dyntopo. The new code is up in the usual place on a branch called dyntopo-slim.

The dyntopo branch has 36 commits touching 107 files with 7406 insertion and 624 deletions. The dyntopo-slim branch has only 25 commits and touches 51 files with 5377 insertions and 258 deletions.

The latter set of numbers will no doubt increase, but it should be clear that the new method is much less intrusive. It’ll be quicker to review and easier to maintain. Further, it should be more memory efficient.

The new code is not yet complete; it won’t work with the symmetrize operator (which is temporarily disabled), it’s leaking memory sometimes, and it’s leaving more loose edges lying around. (Dealing with loose edges is a general todo that needs solving in dyntopo.)

If you’re feeling brave, give the new branch a try. If you find crashes with undo/redo let me know, and I’m also curious to hear how memory usage compares.

Variations on Undo

I’m experimenting with a different method of undo for dyntopo. If successful, it will use less memory and affect fewer parts of the code outside sculpting. It’s still in the early stages, and not pushed publicly anywhere. Just wanted to pass that along so that y’all know the project is still moving forward.

“It’s a maker…”

Status update: I’ve just started a non-Blender-related job as a developer at a company called MakerBot that sells 3D printers. What with moving from South Carolina to Brooklyn and the usual getting-up-to-speed at the new job I’ve been a bit busy. I’m still working on dyntopo as time allows, and I expect that as I settle in, my Blender projects will pick up steam again.

My current focus is on finalizing parts of dyntopo that could be committed separately. The largest such component is the BMLog, which is what dyntopo is using for undo/redo. Rather than making full copies of the BMesh, it keeps track of the Euler operators applied to the mesh (and their inputs), and undoing simply applies the inverse operator.

If necessary, BMLog could be added as an optional system that is only enabled for dyntopo, but if possible I’d like it to handle undo in editmode as well. This will ensure it gets proper testing, and should generally be advantageous in terms of memory usage as well. I’m currently making the necessary changes to use BMLog for editmesh undo so that I can give it some better testing.

BMLog also needs thorough developer documentation and various code cleanups to meet my own standards. I’ll be going through each commit to do my own code review as well, before proposing it for inclusion in Blender (at which point, if there is interest from other developers, it will get additional review before being included in Blender.)

The 2.64 release is still planned for sometime in September. It’ll be nice to see that code finally get out the door; it’ll be the first official release with sculpt masking and the skin modifier. I’m hopeful that BMLog can be proposed for inclusion in 2.65, but that will depend on my schedule and feedback from other developers (who may be busy with GSoC merges.)

Dyntopo+symmetrize undo

The symmetrize work is now pretty much completed. I resolved the issues with BMLog (for undo/redo), and learned a bit more about BMesh’s internal structure at the same time.

There are more “nice to have” features that might yet happen for symmetrize. In particular I might experiment with more aggressive merging across the axis boundary to avoid small edges/faces in that region. For now though, it’s hopefully stable and usable, so I have merged the relevant commits into the main dyntopo branch.

Incidentally, since symmetrize is a BMesh operator in its own right, I will probably look at getting it into trunk separately from dyntopo. That will be after 2.64 is released, of course.

Also: I’d like to say a big thanks to all the people who have donated recently. It is much appreciated, and I look forward to “repaying” you all by getting dyntopo finished as soon as possible.

Symmetrize and dyntopo

Don’t have much spare time right now, but still slowly hacking away on integrating symmetrize and dyntopo. The existing work is in the dyntopo-symmetrize branch. It works except for undo, which is what I’m working on now.

Actually, symmetrize itself already works fine with undo, but re-triangulating the mesh after symmetrizing relies on the SFME (split face, make edge) BMesh euler operator, which is not supported in BMLog. I added that support in, but discovered that the inverse operator JFKE (join faces, kill edge) does not always act as a true inverse. Thanks to the Suzanne mesh for showing me that case.

Currently altering SFME and JFKE to behave as I think they should, then BMLog can be updated, and finally dyntopo-symmetrize can be completed. Once all that is done, all the work will be moved into the dyntopo branch and dyntopo-symmetrize & co. will go away.