Armature skinning (is the devil?)

Thanks to all for the feedback on the armature skinning patch. I think it’s clear at this point that most people would prefer the mesh modifier approach to armatures. I’ll be going back to that approach and looking at adding a “create-armature” operator to aid in posing the mesh modifier output.

Not sure when the next update will be, my car broke down yesterday so that’ll be my focus for a few days :)

Lastly, please permit me to lecture briefly on some commenting issues:

  • Code doesn’t disappear just because we try something different. Some folks made it sound like I destroyed the skin modifier code in a shredder in order to make the armature-skinning code. Not so much.
  • Negative feedback is great, but it needs to be specific to be useful. Saying anything along the lines of “it is useless” really needs to be “it is useless [to me] because of X, Y, and Z.”
  • Resist the temptation to use hyperbole, caps-lock, or exclamation points. Do embrace whitespace and punctuation.

And thanks once more to everyone for taking the time to test this code out. :)

Update: Rebased skin modifier against latest trunk, pushed new branch to blender-bishop on github.

Armature skinning

In addition to the partial visibility and masking tools I’ve been posting about, the skin modifier is another target I’m working on under the Blender development fund.

I’m looking at taking it in a slightly different direction than its previous incarnation as a mesh modifier. First, have a look at this demonstration video. (I know, you are all wowed by the amazing modeling going on there…)
Continue reading Armature skinning

New Blender repository on Github

I’m going to start pushing WIP code to a public repository again. This will replace my recent habit of posting unified diffs and tarballs of git patches here; it also differs from my former use of Gitorious in that the branches will be updated with rebase rather than merging.

The new repository is located here: https://github.com/nicholasbishop/blender-bishop.
Continue reading New Blender repository on Github

Clay strips

The clay strips brush coded by Jason Wilkins is enabled in trunk now.

The default .blend hasn’t been updated yet, so you’ll need to create a new brush and change its tool to “Clay strips”. Note that the tool property is now in the Brush menu rather than the toolbar.

Unlike the other brushes, the clay strips brush uses a cube test to define its area of influence (as opposed to a sphere.) The brush curve still behaves normally, so you can choose between a full cubic effect or a softer look that blends better. In the image above, the three embedded cubes were drawn with a flat brush curve and anchored stroke mode; the rest uses spacing stroke with various brush curves.

Memory-usage reduction for non-multires sculpt smoothing

Earlier tonight I committed a memory-usage reduction for the function used to generate adjacency for the smooth brush in sculpt mode:

r44933 – Reduce poly map memory usage (used by sculpt smooth brush.)

The poly map tells you which polygons use each vertex, information that is not normally available outside of edit mode.

It’s a relatively small amount of memory compared to some of the bigger mesh element/VBO allocations, but for a mesh of 1.5 million quads (non-multires) it reduces the size of the adjacency allocation from 168MB to 48MB (for 64-bit builds.)

Partial visibility in trunk

I’ve just finished committing partial visibility for sculpt mode:

  • r44864 – Don’t wait for sculpt stroke to create PBVH.
  • r44865 – Add BKE mesh function to update edge/poly hidden flags from verts.
  • r44866 – Add new CCG accessor functions.
  • r44867 – Add MDisps.hidden bitmap.
  • r44868 – Add DerivedMesh.gridHidden and CCGDM implementation.
  • r44869 – Skip hidden elements in PBVH iterator, raycast, and drawing.
  • r44870 – Copy hidden flag to vertices when applying multires modifier.
  • r44871 – Skip hidden elements in PBVH iterator, raycast, and drawing.
  • r44872 – Add partial visibility operator including keymaps and menu items.
  • r44873 – The first, and hopefully last (ha, ha) fix-up commit.

Check the documentation on the wiki for usage info. Please report any bugs you find, either here or in the Blender bug tracker.

This feature began as an ugly hack back in 2.4x, got rewritten during GSoC, and is finally committed to trunk with support from the Blender development fund. Thanks all for your help and support; there’s more to come!

Quick masking update

Here’s an updated masking patch that should apply cleanly against current trunk: masking-03.diff

Note that in this update, material colors aren’t working correctly. I’m pondering how best to address this and other drawing problems now.

Past couple days I’ve been committing some code cleanups to the non-sculpt drawing code. It’s still a lot of code to wade through, but it’s at least a little less verbose now.

Improvements for sculpt drawing

Example of multiple materials drawing correctly in sculpt mode (click to embiggen)

Recently I’ve been committing some improvements to the sculpt PBVH drawing code. None of these changes affect the fancier drawing modes — GLSL and all that is still not accelerated by the PBVH when sculpting. However, there are still some performance and feature improvements.

The most noticeable change is pictured at right: materials and shading mode (smooth/flat faces) are now drawn correctly in sculpt mode. Previously, the material and shading mode were set once for each PBVHNode (each of which typically contains thousands of polygons.) This is still the case, but now PBVHNodes are split until all the faces they contain (whether mesh or multires faces) all share the same material and shading mode.

Another recent change involves building VBOs for multires meshes. This is done by mapping a vertex buffer as write-only and copying multires grids (containing coordinate and normal data) into the buffer. There was a small bug in this code though: when sculpting on a flat-shaded model, the normals in the buffer were updated in a way that read from the buffer before writing to it. This is an invalid operation for a write-only buffer, and while most drivers won’t crash if you do it, I found that on my particular drivers (Gallium/Radeon) it makes a huge difference in performance. (This was on the order of seconds for dense meshes.)

Finally, improvements have been made to use better normals for flat shading. The results should in general look quite close to non-sculpt normals, with the exception of non-multires with VBO.