Mercifully, Geoffry Bantle, Campbell Barton, and two or three others whose names escape me have really taken up the slack, for which I am very grateful.  Anyway, I’ll be back coding as soon as I can.  I also have a character modelling video tutorial coming from a friend of mine (I promised to do a video tutorial at Siggraph, but that didn’t happen; I decided to have someone with better modeling skills do it), so watch out for that.

I’m setting a $1000 USD target.  If we reach half of that, I’ll commit to doing a talk at Siggraph.   At two-thirds I’ll commit to a video-taped ngon modelling demonstration, and at 1000% I’ll commit to daily bmesh demos.  Any other suggestions for ways I can “pay back” would be appreciated.

The donation deadline for fulfilling the commitments would be the start of siggraph (late donations are still helpful), but I’m going to need at least the first half fairly soon if I’m to go at all.

It’s not completely perfect–the rules for recursion are too simple, and vert/edge customdata interpolation (e.g. vgroups, edge creases) doesn’t work correctly (though uvs and vertex colors do).  It also doesn’t always get normals right.  Still, I had no idea bevel was such an awesome tool or I would have coded it ages ago.  I ended up not using Levi’s code (the old bevel), which was written in a prior version of bmesh.  It’s not bad code, but it since it was coded for 2.4x its a bit overcomplicated.

In addition, I rigged my Sakura character,  and fixed bunches of little issues in the modifier stack (though a problem with mirror at high merge limits remains).  Thank God for Nathan Vaghdal, Campbell Barton, and rigify.  It makes rigging easy.

She’s a character from Naruto Shippuden.  It’s a real challenge; reference images are completely useless, I found it vital to watch the anime itself, and pay attention to the underlying volumes  as she moves.  It’s fun, since anime characters do have a consistent form, but you have to watch them move to see what that form is.

Anyway, things are much more stable/usable now, although there are probably a ton of bugs I’ve not found yet.

Things have been a bit hectic lately.  I’ve been living with my parents lately; the winter here makes me extremely sick, and I wasn’t able to move to where I spend winters before the weather changes (I’ll be heading over there in three days).  This happened last year,  and after the move I got much more work done.  I expect to bounce back relatively quickly this time as well.  I apologize for the delay and not answering comments/emails.

In other news, I have all the tools I need to fully stabilize BMesh–it required writing some a (extremely hackish) unit testing framework (it’ll work for me, but is not a competitor with Leaf’s SoC project)–and I expect to move much more rapidly.

Any donations are much appreciated!  As an incentive, whoever donates first (at least $35) gets a free BMesh t-shirt!

I’m currently in northern Utah for health tests.   I’m planning to head back to northern California (Sacramento) in a few weeks.  If anyone knows of competent blender modelers  in travel distance of Sacramento, I’d appreciate very much if they could leaves comments or email me so I can start making contacts (don’t post email addresses though).

I’m not sure of an exact time frame for completion (some unpredictable things came up) but hopefully bmesh can be merged into trunk sooner rather then later.

This opportunity shouldn’t be seen as a threat to BMesh.  I think I’ve proven I’m dedicated to finishing this project, given that this is the third time I’ve  done it.  And to be honest, I don’t think my professional career would survive if I did not.  I strongly feel I entered into an implied contract the moment I went public with hemesh five years ago, and no matter how long it takes I will fulfill it.

I also ported select mirror to bmesh, and in the process I decided to try my hand at writing a topological-based function to find the best mirror candidate for a vert.  It works pretty well, except I’ve later learned that Campbell Barton beat me to it in svn trunk.   I’ll have to take a look at the code, see how it compares with my method.

A good mirror-finding function is important.  In a perfect world, the function would be entirely topological (e.g. no need to have your model in a t pose, perfectly split by the x axis), but I’m not sure if I’ll be able to do that anytime soon.  What I’ve done is coded it to detect the best match among possible candidate vertices in a sphere around the vert’s mirrored location, based on how similar the topology around the candidate is to the topology around the source vert.

I’ll have to put up some illustrations later.  I’ve not yet hooked this up to x-axis mirroring, weight paint, etc; I need to look at Campbell’s code, and decide if I should modify my version to use the same method.  Mine isn’t completely perfect, and I suspect his approach would work better in certain situations.  Most likely I’ll end up combining the two.  This isn’t something I’ll likely be spending a lot of time on in the near future, though, since there’s lots of porting work and debugging to do.

I’ve also been chugging away at aforesaid porting work, and merging in recent changes from the main development trunk.  I’ve decided to put off the dreaded loop to region tool (ctrl-e, for example, loop select a forearm and loop to region will select the hand) until later, since it seems few people use it and it’d be more effective to spend time on other parts of the code right now.