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.
I’ve decided to go to BlenConf this year, so I’m starting a donation drive to help pay for it. At BlenConf, I’ll have access to key developers to finalize trunk integration plans, and a great many artists for testing. I should be able to resolve a great many issues, and work with other developers to best plan out trunk integration.
Any donations are much appreciated! As an incentive, whoever donates first (at least $35) gets a free BMesh t-shirt!
BMesh is nearing completion. I’m currently doing another merge, and I’m aiming to do an intense testing sprint in the near future. My life is rather hectic at the moment, but hopefully I will get bmesh production-ready as soon as possible.
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.
I’ve been honored recently to be hired by the Blender Institute to work on the Durian project. I’ll still be devoting some time to BMesh, as much as I can spare. I’m not sure what to do about donations; they would still go to BMesh (I’m only here for three months, after that it’s back to relying on donations), but I recognize that others may want their donations to produce immediate work (I certainly try to treat donations as an obligation to code now, not later). Because of this, I’ve decided that I will refund on request anyone who donates during the time I’m here at the Blender Institute, no questions asked.
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.
So, I’ve managed to put in some BMesh time. Recently I ported a bunch of selection tools, select linked flat faces, select random, select sharp edges (as in edges with folded faces around them, not edgesplit-sharp edges).
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.
The last three weeks have been insane for me, but I’ve managed to make some progress. I recoded the join triangles tool, though I’ve not yet tested the more advanced uv/vcol features. I also finished getting all the primitives to work.
The next big thing will be the loop to region tool, and after that it should mostly be easy monkey work porting small tools, merging recent changes from trunk, restructuring extrude to match the way it works in trunk, fixing bugs, etc.
Unfortunately I’m not going to hit my self-administered deadline of having something complete and stable by the end of this month, due to health problems and homework (and fixing bugs in the main 2.5 development trunk so I could use it for my homework) crowding out my time. But I shall get there in the end, no amount of adverse circumstances shall defeat me.
When I originally got the updated BMesh API from Geoffry Bantle, we both knew it was going to be a lot of work to integrate it. We had tried and failed a from-scratch rewrite (that started by removing much of the old tools code) in the first BMesh project, so when I started again I decided to keep unported mesh code working via a compatibility layer, until it came time to rewrite it. This worked very well in the beginning of the project, as I could write tools and improve the BMesh API. More then that, I was able to rewrite or refactor a large portion of the mesh code one piece at a time, and still have everything mostly working.
Unfortunately, as more and more tools and code got ported to BMesh, the compatibility layer got more and more unstable and buggy. From a coding point of view, it made the code more confusing and muddled the underlying design. I finally realized I was going to have to remove it entirely, and port the remaining tools to the new system.
I have now started this process. I’ve removed the compatibility layer and all the old code it supported, and I’ve started porting it to BMesh. Currently join triangles, a bunch of selection tools, and some of the primitives code (cone/grid/circle/tube) remain to be ported. I hope to have all of this done within the next two weeks; the hardest will be join triangles and region to loop, the rest is only one or two days of work.
BMesh should be much more stable after this, as no longer will things randomly break or tools unpredictably mess up your mesh. After that, all I have to do is fix the remaining bugs and BMesh will be ready for a merge into trunk (yay!).