Here at the end of the SoC, I've taken a little time off to actually play around a bit with Blender's tools. With the sculpting tools and retopo I created a small scene, the process of which helped me to find some bugs and some workflow issues. Doing actual modeling (i.e., testing the code) is an important part of the process, but I don't seem to do it often enough.

I got my FedEx tracking email for the second SoC payment today, thanks Google! Once I have the money, I'll be getting the rest of the components I need for a new computer, including a new Core 2 Duo. Mmm. Shiny things.

Experimentation with retopo painting continues. I hadn't originally planned to spend so much time on retopo, but I think that in many ways, it's a more important tool than multires. Thanks to a suggestion I received, I currently working on an ellipse tool that should make it easier to add edge loops around eyes and such.

Ach! I'd like more time to expand the tools, but a lot of that will just have to wait until post-SoC. In particular, I'd really like to redesign multires. I have a lot more confidence with Blender coding now, of course, and having already implemented multires once, I have a much better idea now of what works and what doesn't. I think it should be possible to make multires levels much more generic, so that each vertex and edge and face doesn't have to follow exactly the same subdivisional pattern. Right now, every level after the first one is entirely predictable in terms of its topology. This means, for example, you can't delete a subd level from the middle of the multires stack and it also makes it very difficult to handle partially subdividing the mesh.

I'm taking a day or two off from the regular project to work on coding a displacement map tool in Blender. It's a frequently requested tool, and while Blender's internal renderer doesn't actually handle displacement maps all that well, it should still come in handy, especially if the displacement map is used in a different renderer.

To start off with, I'm coding this tool as part of multires, so it can create a displacement map from a low-res level to a hi-res level, but there's no reason it couldn't be easily extended to work with any two meshes. On the other hand, multires meshes have a certain structure to them that could improve the speed of the tool.

As a user of OpenGL, I'm naturally fascinated by all the OpenGL activity going on now. First, there's the transfer of control from the ARB to the Kronos Group, as announced at Siggraph. Also coming from Siggraph are the BOF presentations, available online here: http://www.khronos.org/developers/library/siggraph2006/OpenGL_BOF/

Particularly exciting among the planned changes are the new object model, which looks to be a pretty nice clean-up of OpenGL from the developer's point of view, and geometry shaders, which will allow programs to control the output of polygons, which could allow for a whole new set of interesting effects. (I'm not sure geometry shaders will actually for Catmull-Clark subdivision, but if so, that would be a great benefit for 3D modeling programs like Blender.)

Things are coming together nicely this week. I committed the first multires/animation code, which allows an armature to modify a lowres level for editing, then render at a high res level. I then added support for a few new types of data to multires: textures, UV coordinates, and smooth/solid faces.

This was followed by frantic bug hunting, trying to detirmine why saving multires files multiple times was causing them to balloon in size. (One file jumped from 2 MB to 74 MB) And when trying to render, my system's memory got completely swallowed up by the massive memory leaks I'd left in the render code. So I spent a day fixing that, and then I spent another day figuring out why the code that I'd removed the memory leaks from was now trying to free memory multiple times, or occasionally some random segment of memory that had never been malloc'd in the first place.

Users of the new sculpting/multires tools often suggest complex additions that are outside the scope of the project, e.g. ZSpheres. Most of these suggestions are good, it's just that I don't have enough time to do them, and in some cases, I don't have any idea how to implement it, either.

But one such project caught my eye: someone suggested the addition of a topology brush. So far as I know, this tool currently exists only in Silo (though there are some ZBrush 2.5 previews that show a similar tool.) I've never used Silo, but a tool to remake a mesh with the same shape, but better topology, would clearly be extremely useful, especially with the new sculpting tools.

Next up for the sculpting tools is basically a performance enhancement: interactive partial visibility for the sculpt mesh. From the user perspective, it works like this: add a mesh, go into sculptmode, then press Ctrl+Shift+Left Click, and drag the mouse across part of the model. This action will draw a rectangular boundary, and when the user releases the mouse button, all the vertices (and edges and faces) inside the boundary will be hidden. Sculpting can now proceed as normal, and if a lot of vertices are now hidden, it should be much faster.

Now, from the implementation perspective: hiding vertices and faces isn't enough. I tried that first; marking the vertices as hidden, then ignoring them for drawing and brushing operations. Unfortunately it didn't do any good, so I moved on to a more complicated approach: remapping the arrays of vertices, edges, and faces so that they start with the visible elements. So anything that deals with the arrays doesn't need to check for visibility anymore, it just has to loop from [0,number_of_visible_elements], which means that so far as speed goes, hiding vertices with the new tool should make sculpting just as fast as if the user had simply deleted the vertices.

Here's quick test of retopo. (Which is now in soc-blender CVS.) The mesh on the left is an old head I created a couple months ago in SharpConstruct. As is visible in the editmode view, it has lots and lots of polygons, and they aren't arranged in any particularly useful pattern. (The topology of that model is basically a subdivided cube.) On the right, you can see the new mesh created using retopo. It is much less dense, has some sense of order, and as the final model (which has the Mirror and Subsurf modifiers applied) shows, it still looks pretty close to the original. With a bump or displac

I've gotten started on part II of my Blender project, Multi-resolution Modeling. Multires, as I'm calling it, is an advanced modeling feature that (so far as I know) current exists only in ZBrush. This is a much trickier feature than the sculpting tools. Though there's still more work to be done with them, they're familiar ground for me, thanks to SharpConstruct.

Over the past few days, I've been evaluating how this feature is best implemented in Blender. Originally, I had assumed that the modifier system would be the best point of integration, however I now question that assumption. I think it could be made to work, but not without making modifications to the modifier system itself. (And another SoC student is already making modifications to the system anyway.) I'm now trying an implementation of multires similar to vertex colors or sticky coordinates, where you click the "Multires: Make" button to add multires data to a mesh. If a mesh has multires data, a new panel shows in the buttons window with the multires settings. This approach is more flexible, and still fits with existing Blender methods.

What's that burning smell? And why is the screen flickering? As you dive for the power button, you can only pray that it isn't the hard drive, which was last backed up in 1995. As it turns out, it was my graphics card. Seeing as I'm buying a new computer soon anyway, it's not a huge deal, but couldn't it have waited just one more month? Now I'm using a scavenged graphics card that is so old you have to use nVidia's "legacy drivers".

But I have actually gotten some work done. It's mostly pretty boring -- cleanup of the Catmull-Clark code to make it more flexible and less dependent on complicated nested if statements.