So, you can click on the thumbnail below to get the full sized image of the network.

Film Look node tree

Download a .BLEND file here.

The effect is created from an old tutorial I had found on some kid’s website for adding a film style look to his digital photography in Photoshop. I re-purposed the decently complicated Photoshop layer-based work flow into a nodes-based one for Blender. I went looking for that original one, so I could link and credit, but I’ve been unable to find it since that one lucky strike a couple of years ago. To be fair then, the general theory behind this technique isn’t my own, although I added and adjusted a bit while I was nodifying the process. As a reminder, the results are:

Before

After

You adjust the way that the shadows, highlights and midtones cast by changing the colors in the RGB color node, and in the Color Ramp node. If you’re going to use this, make sure to set the render dimensions to match the dimensions of your input image.

Merry Christmas!

But really, who am I kidding? I’m going to end up fighting with this all weekend and into next week when I should be writing my book.

Tracker link: Similar Surface modifier patch

Obviously, there are workarounds, but I have a solution that I’m not going to have time to implement myself. I built the modifier structure and basics, but once I realized I’d never coded with the modifier system or dealt with mesh data directly I understood that it would require more time than I had, and would be fairly easily accomplished by someone already familiar with it.

I think a good solution to this problem would be a “Similar Surface” (name for artists) or a “Hook Web” (name for devs) modifier. Simply put, the modifier is a “bind” type one, a la the cage deformer. The user creates a fairly simple structure upon which to run a cloth sim (or any other deform technique, actually). Then, the user creates their “high res” clothing, which includes all the nice things like buttons, epaulets, cuffs, pockets, layering, etc. Clearly that would never survive an actual cloth sim. When the user BINDS the high res clothing to the sim’ed simpler one, the following happens:

1. For each vert in the high res, a virtual hook is created. Within the modifier, it would be an array of hook objects (obHook). The hook data structure is deprecated in favor of the hook modifier, but the DNA is still there.
2. Where does the virtual hook attach? The shrink wrap “nearest point on mesh” procedure is used to identify. Then, the verts that make up the identified face of the underlying mesh become the vertex parents of the virtual hook.

That’s it. This would allow complex, multi-layered clothing to be driven by an underlying cloth simulation.

From reading the DNA and modifier code, it appears that everything is already there. We need someone who is familiar with mesh coding and modifiers to put it together. Unless I miss my guess, the Durian team WILL be asking for something like this in the near future.

Edit: If you’re interested in patching your own for working on a laptop, click here to get it. Remember, this isn’t a permanent solution.

Egad. Karmic broke my wifi. It’s an Atheros card (AR2413), and there is a long list of gripes on teh Internets about Atheros not playing nicely with Linux. There is a set of open drivers (ath5k) for the cards, but after finally getting Ubuntu to use them, I got really really horrible connection. Oh well. That’s why they say not install the beta on a production machine! The solution I came up with? Order a different card. Edimax makes cards that play very well with Linux, and for $20 I not only get a card I don’t have to fight with every time I do a system upgrade, I get one with an extensible antenna with a cable. Hopefully I’ll be able to position it more freely than a card with the antenna attached directly and nab some extra signal.

So from a Blender perspective, just remember that beta really means beta. Don’t use it for production unless you are either extremely fault tolerant or can fix problems yourself. When 2.5 rolls out (hopefully) at the end of the month, by all means grab it and pound on it. It’ll help the development process. But don’t think you’re going to be doing end-to-end production with it.

Blender 2.49 is still where it’s at, and really, I don’t think I’d roll 2.5 into my production pipeline until after Durian is over and the gold release (or 2.60 or whatever it will be called) happens next summer. That in mind, if you’re foggy on the higher order aspects of using Blender in a real production, it wouldn’t kill you to check out my book in the sidebar (turn your ad blocker off for a second!) It’s been called both “the best software book I’ve ever read” and “a replacement for Inspired Short 3D Film Production“, and not just by my mom!

Bad bad bad.

Apparently, there’s now an active worm, er, worming its way around demolishing unpatched older versions. With a sense of urgency, I’ve just followed the “detailed upgrade” instructions from wordpress.com, which worked flawlessly for me. My old plugins and the changes and new code I had done for my theme worked perfectly after the upgrade. If you use WordPress for your blog and haven’t updated/upgraded in a while, now is the time!

It’s actually just an image filter! You render your water and objects from directly overhead into a sequence of images. Make the water shadeless white and the objects shadeless black. I’ve written a little image processing Python script that uses that image sequence as input and generates the ripples into a new image sequence. That sequence is then used as either a displacement map or bump map for the water back in the original .BLEND file.

There’s a lot of tweaking to do, but this was just a proof of concept.

NOTE: This isn’t a Python script that runs within Blender, although I suppose it could. It’s just a command line program. I’ll post it when it’s finished.

Did I freak?

No. Because I keep backups. Twenty-one days worth, with a full backup every ten and incrementals in between. Yeah, it took several hours to acquire a new HD and load all the data back into it, but it was all there.

Why am I writing this? I’m sure you’ve all read “All my file are gonerz man!” articles and posts elsewhere, which then proceed to admonish you to have a backup system in place. This is the other side of the coin. Success. Everything’s fine. Nothing’s gone.

1. Have a backup system.
2. Check on it every now and then to make sure that it’s actually making backups.
3. When you check to make sure, do a little test restore to make sure that it’s working from end to end.

That’s what I did, and why I’m not thinking about walking in front of a bus today.

Which reminds me, I need to get my home backup server running too.

Malcolm Tredinnick’s review on Defying Classification.

That review pretty much covers it. If you’ve been thinking about tackling a short animation project, what are you waiting for?

AN INTERFACE EDITOR
Right now, the one and only way to edit/change/test/configure the Blender interface is through c coding. That’s a huge problem. Let’s call the set of all people who can code in c “Group C”. Let’s call all people who are good at interface design “Group I”. The overlap between Group C and Group I is dwindlingly tiny. Very tiny. Most likely just a few people. Restricting the job of interface work to the C/I overlap is a huge mistake. Why not put in some more work up front, and give access to the entire Group I? I’m proposing that Blender’s interface (and by this I mean buttons, panels, header elements, panel elements, etc., not such things as Click-n-Hold vs. modal click) be configurable directly from within the application, and that any configurations that are created be savable to an external file, much like Themes are saved into Python files currently.

DESIGNING THE INTERFACE WITHIN THE APPLICATION
At the moment, a user can change the “rt” value and play around with button configurations. That’s nice for making screen shots, but very limited. Best would be a system in which all interface elements (colors, panels, button contexts, menus) are changable by the user, along with some nice examiner and informational panels a la an IDE. Call it an IDE for Blender’s widgets. At any point, the current state of all controls could be dumped to a Python file. In fact, Blender’s base configuration would be converted (one time!) to such a format, and that base file would be loaded at runtime to configure the default interface. Elements could also be exported and imported on a modular basis.

This would not only be great for users, but for developers as well. If you code a new feature or module, the last thing you want to have to worry about is digging through the interface code, doing the math for buttons, etc. You build your feature, properly code it’s DNA and RNA, compile and run. Switch into “interface edit” mode, create a new panel in the proper buttons context, add/configure/arrange widgets and link them to proper RNA right in Blender. Bind key commands to the operators you’ve written. When you’ve got it as you like it — export the new panel and bindings either as a simple module that anyone can import to try (sort of like a patch), or just save your entire configuration as a new default. When it comes time to commit your feature/module/etc., the interface code exports and patches right in to the trunk version of the interface configurator.

From a user standpoint, one could configure tools, menus, and pop-ups to suit their workflow — even creating toolboxes or toolbars with their favorite widgets. They would be easily sharable with others, and if useful enough could be included in future releases.

A scheme like this really continues and extends the promise to the artistic community that Blender has already begun. To the artistic community, Blender says: “Here’s a great tool, at no cost to you.” And now, this great tool can be customized by you without any special knowledge. But even better than that, you as an artist get the potential to benefit from the entire community of Group I, not just the C/I coincidence.

Will people do stoopid things to their Blender interface? Of course. Will this take the onus away from Blender’s development team to make the interface as good as it can be? Of course not. I think that such a system, though, would drastically improve the interface in short order. You’re reducing the testing and experimentation cycle to virtually zero time. It’s instant feedback, and almost no effort to game something differently and give it a try. Our interface people will be significantly more productive with such a system.

PREFERRED TOOL
Apart from my system-level suggestion above, I do have one specific idea that’s nagged at me for a while. It’s a “preferred tool” designator. When working in the 3D, which comprises a vast majority of the time, Blender artists are confronted with a number of pop-up menus: Specials, Merge, Mirror, Edge, etc. While it’s fairly simple to, say, press the W-key followed by a number to select an option, I’ve found that in my own work, I tend to use tools in clusters. While I’m performing a certain portion of the modeling pipeline, I might use Subdivide a number of times in a row. What would be fantastic would be to structure those sorts of pop-ups to allow for the on-the-fly designation of a “preferred tool.” Then, instead of repeatedly pressing W, then 1 (or just using the mouse to choose it), you hit the menu key (W) with a modifier (like Ctrl) and it just activates the preferred tool. Done with that part of your work and moving on to something else? Set a different preferred tool. You could also include secondary and tertiary tools (Alt, and Ctrl-Alt?). This way, Blender works the way that you want it to — losing nothing in the process. All of the options are still there, but you can easily bend Blender to the specific task you are doing, on the fly.

SUMMARY
While I have great faith in rest of the development team to come up with good solutions for the road ahead, I wanted to place a vote for ultimate configurability. A system that lets interface design and configuration take place directly in the application workspace would not only benefit users in the long run, but have immediate benefits for the developers themselves.

The sort of sharability and openness that we already enjoy with BLEND files and artistry could be extended even further, and we would all come out ahead.