A few days ago I released my first add-on on the Blender Market: Animated Render Border. It's an add-on that allows the render border feature of blender - which allows a portion of an image be rendered - to be animated and track objects. This can cut down render time by skipping rendering the background (which might be blank if using render layers) or by rendering only a specific part of an image for a whole animated preview. I won't go too much into the details of it as that's all I seem to have done over the last few days, and frankly, I've bored myself by writing the same blurb on all the various social sites and forums. Instead, indulge yourself by watching the (relatively) short video below which is a full demo of the add-on, and of course, feel free to head over to the Blender Market to buy yourself a copy:
This add-on was originally started in February this year. It was just an experiment that I thought might be useful at some point. I'd seen a few attempts at such an add-on and a few more blog posts lamenting the lack of such features and surprisingly, I had quickly got the core code to work in the viewport. After that, other priorities took hold and I left the add-on, only to be reminded of it recently by a few posts on Blender.StackExchange and by my own attempts to use it, forgetting I had left it unfinished. I had thought at some point I could release the add-on as a bit of publicity for my site, but the fact that some highly skilled python coders seemed to be coming to the conclusion that an add-on like this could be useful, prompted me to finish it before they might be tempted to do the same and 'steal my thunder'.
At that point I hadn't thought about selling it, I just wanted to quickly finish it and release it. I'd thought about it originally, an extra revenue stream is always welcome, though I wasn't sure if the add-on might be too simple for the Blender Market, but all that slipped from my mind until I was a few weeks away from releasing it for free. Reminded of my idea to sell it I did a bit of investigation and applied to be a vendor on the Blender Market by describing the product I would like to sell. My application was approved, which meant I had to fill some of the extra requirements of releasing on the Blender Market. Don't get me wrong, they're perfectly acceptable requirements, ones I would have set myself, just ones I hadn't been thinking of when I thought I'd "quickly finish and release it". I wasn't just finishing up the code, I now had to think about a video demo, documentation, product images and descriptions, future updates and promotion. I was reminded of each one of these just at the point I thought I might be nearing the end. So the project, like all projects, was a bit longer to finish than expected.
There is also a bit more pressure when releasing a paid add-on. Getting it functional wasn't good enough, I now had to look at it from the perspective that someone would be buying this and expecting it to work in a professional way. People might be using this in their workflows. What if it crashed and they lost their work? Suddenly, things that I thought were fine for a free release stuck out as dysfunctional. Things that I knew had to be in place for tracking to work had to be checked for and the user warned if they were missing. Every circumstance a user might get into needed to be accounted for. The add-on requires a camera present in the scene. What if they delete the camera? What if they manually turn off settings the add-on has turned on so it can work? What if they're idiots start pouring pasta sauce over their keyboards because I've accidentally pasted a lasagna recipe into the documentation!?*
The days after the release were spent answering questions from all the various places I'd posted it, solving bugs and talking about future features. I hadn't quite anticipated the amount of attention it would need after the release, though I was aware that part of the Blender Market commitment is that authors provide support for products. Luckily, it seems to have settled down now and I have received a modest, but pleasing amount of sales so far. This coming week I hope to be able to return to my modelling projects and improve the add-on steadily over the next few weeks and months.
*I will not be held liable for any damages incurred by pasta sauce or any other ingredients which when combined could constitute a 'lasagna'.
I released a new video on youtube last week (inspired by this), the first in nearly a year. I think I can safely say it went down rather well, getting featured on BlenderNation, which helped it gain 10,000 views in just a few days.
As usual, this project went on longer than I wanted, growing from an idea of just showing the actual fluid part to deciding that it needed some context, meaning I felt I should add some type of scene, rather than just some bricks in blank space. I thought I should at least show the bricks appearing (I managed to resist having a submarine surface, I'll leave that for another day ;) ), and to have them appearing from somewhere I added a brick pile.
Annoyingly, the 'build up' part' was actually more challenging than the fluid as I had a few problems rendering. The build up is done with particles that are affected by an 'explode' modifier, and despite displaying correctly in the viewport, the render would only read a few frames of the particle cache before getting 'stuck' and no longer update. I presume this is a bug and not a dependancy graph issue as it's only the render which doesn't work, but narrowing down the problem to a small enough sample to be able to submit it as a bug may be challenging.
I tried several python solutions to try and get the frames to update properly, such as using a script to render each frame individually (with various pieces of code intended to update the scene between frames) or even generating a new blend file for each frame, each one offset by one frame, which another script would then render. None of these solved the refresh problem. It was annoying, because the build up obviously wasn't the main part of the video, but it was holding everything up, which made me question if I shouldn't include it in favour of a quicker release. I decided I had spent too much time on it already to not include it so I pushed ahead with my 'last-resort' method. The brute force, feel my wrath, this-is-definitely-going-to-work-and-nothing-will stop-me method.
Every project usually has several fallback solutions, when the easiest "Click one magic button and it works! Yay!" solution doesn't work you fallback to the next possible method, all the way down to "I'm going to have to do this frame by frame, aren't I". Normally it never gets to the last one, there are enough fallbacks that one ends up working, but unfortunately, in this case their were no other solutions to fall back on.
I knew that if I updated the current frame manually it would then render that frame correctly... Which meant...I would have to update, render and save every frame by hand. For 70 frames.
Now, it didn't turn out quite that bad, I realised that if I saved out a new blend file for each frame I could at least get a script to render all of those blend files, and with shortcuts and the 'increment file name' feature it only took a few minutes. But that doesn't make it fun. And less fun when you realise after saving all 70 files that the texture paths are relative and the locations of the blend files have just changed...
Suffice to say, this isn't exactly an acceptable method for a tutorial (which will follow in a few weeks). "Bye the way, don't want to worry you, but we're going to be doing it all by hand" probably wouldn't go down too well. Both viewers and I expect that the tutorial is going to offer some kind of shortcut to the method. Otherwise, what's the point in the tutorial? We can all look at something and go "Well, sure, I could probably do it by hand, placing different objects on different frames" (or animating on each frame or whatever technique is necessary for that effect), but who would want to?
Now, even if I did manager to report and get it confirmed as a bug, the fix wouldn't be in an official release of Blender for a few weeks. So I'll have to investigate another method. I have a few ideas and it's not uncommon for a few methods to get tweaked or changed inbetween the teaser video and the full tutorial. Looking at something afresh a few weeks after the initial video release helps that.
I also had someone ask if it could do fire so I had a play around with that too. Or at least particles, as this method currently requires a mesh to work:
It's certainly satisfying having a successful video release, it makes all the difficulties completely worth it. On one hand it's a bit weird to see my technique out 'in the wild', with some people already putting it to use, and on the other it's nice to see that it garnered so much interest, becuase that's never guaranteed.
Though it is a bit annoying that people aren't always completely clear that they got the technique from someone else and end up recieving praise for their 'creativity'. It doesn't matter too much though, ultimately other people's lego fluid videos will end up acting as an advert for the tutorial I release.
And anyway, they haven't quite worked out all my secrets ;)
Well, it's slightly to my surprise that I hadn't actually posted the 4th part of my tutorial series on my blog:
It's been a few weeks since this video was released, the content of which has all but slipped from my mind, but I presume from the helpful title that it contains the actual animation of the pieces. After re-watching the intro I'm also informed that it contains some optimizations to make the code run a little more efficiently. So that's nice.
Blender Nation were also kind enough to feature the tutorial series in this post, which was a good boost to the views. Not that views are all that count, but ultimately it's made to be watched.
Onto other things.
In a few blog posts I've mentioned the project I've been working on but have been somewhat reluctant to reveal what it actually is. I think the time is upon us (or just me if no one is reading) to reveal that my current Big Project is simply called 'Futuristic Car 2'. I'm sure the title will change but it refers back to the video I completed in the 3rd year of my computer graphics university course:
The premise was fairly simple, a futuristic car that has the ability to hover. At the time I was fairly pleased with the outcome, but, as can often happen with large projects, particularly when working on several at the same time, some compromises were made to the original idea without realising as the project progressed.
The car is made out of lots of small panels, a design change that was made after seeing 'suitcase suit' from Iron Man 2 but I didn't quite have time to animate a lot of the smaller panels and instead the transformation is a bit chunky. It was only a few months later, back in 2011, that I imagined the next version, a sleeker, sportier car more in keeping with my original design and yet keeping the idea of many smaller shifting panels.
Work on the project is slow and difficult, much of the time is spent on efficiency and workflow. Without careful management the many objects in the scene can become overwhelming. I'll cover my workflow in future posts. Hopefully.
If I remember.
Which I might.
Well, another week has shot by which means it's time for part 3 of my tutorial series:
I've also been working on my other main project. I haven't really spoken about it yet or shared anything about it other than that I've done some scripting for it. I'm still not ready to do that, maybe after this tutorial is out the way I can start sharing more about it.
But, as part of it I did come across what I thought was a bug in Blender, and I reported it as such. Reporting bugs for Blender is important. We use it, so it's in our benefit to improve it, even if all we can contribute is pointing out a problem in the hope that someone more skilled can fix it. It can be a bit of an alien concept to people who aren't familiar with open source programs, that there might be a way to contact the people who made a piece of software and get them to fix something or answer a question. Of course, it isn't limited to open source projects, I contact many services if I find an issue, open source just tends to promote it a bit more and, well, be a bit more open that it's a possibility. But whatever it is that you use, it again comes down to: Why wouldn't I want it fixed?
This is turning into a post about bug reporting, really I just wanted to highlight the specific issue I had...
Turns out that what I reported wasn't actually a bug at all but a known design limitation. It's not exactly a bug because it's working as expected, even if the way it works isn't exactly ideal. It's annoying, but it basically means they, the developers, are aware of it, but can't currently change it.
I came across the limitation because I'm working with duplicated objects which all share the same object data (OD from now on) and they all need to share the same vertex groups. I thought that sharing/linking OD would solve this, which it partially does. Apart from one slight problem. It turns out that the OD stores the vertex groups and their weights but it doesn't store their names. The names can be unique for each object that shares OD. So two objects which share OD will have the same vertex groups and they'll be linked, but they could be named completely differently.
Edit one vertex group called 'group 1' on one object and 'group 2' might be edited on the other object if you've renamed a group on one object but not the others with linked data...
Cue a series of scripts to try and manage all this. Haven't quite fixed it all yet, have to work out which vertex groups aren't being used by modifiers so I can clean it all up a bit and maybe have some global counter which handles the naming of any new groups.
Anyway, I don't regret reporting it as a bug even though it's technically not. I've at least come away knowing how it works, thanks to Campbell Barton (a Blender developer) and I don't think it does any harm letting the developers know that people are still finding this is an issue. It's also far better to have reported it than potentially be trying to work out workarounds when a simple report could have fixed it.
Better safe than sorry.
Here is the second part of the Slider Puzzle Tutorial, this part focuses on unwrapping and texturing the grid:
I think I just need to confirm that while I said there wouldn't be any more tutorials on a regular basis, that only comes into effect after this tutorial series is over. There are 2 more parts of this current tutorial still to be released, after that, it's a bit less certain.
Anyway, onto more coding...
I've found that since having worked on bigger python projects, smaller scripts are far quicker to write having become far more familiar with the code. I've always found myself writing little mini scripts for things like enabling/disabling Subsurf modifiers for all objects in a scene, so for my current project I decided to create a little toolset that I can eventually develop and use across all my projects.
The layout is a bit of a hack at the minute as I'm kind of forcing a 2 column menu to look like a panel. Eventually as I add more tools I'll probably collapse the modifier tools into proper submenus.
Another cool thing I found was the ability to have an operator set a custom property when it runs. So I can use the same operator to make both the modifiers visible and invisible. On line 7 you can see I define a new property within the operator. To make sure I can access it I pass 'self' and 'context' into both the execute function and the function that has my main code on lines 9 and 10. It's with 'self' that you access the property, so I haven't yet experimented if 'context' is actually needed:
Then you can access the operator property with '.propName' after the normal operator call and set it's value:
You can then access the property with 'self.propName':
Now I just have to work out how to set multiple arguments with an operator call...
Anyway, have to actually do some work now instead of just writing about it. Part 3 of the Slider Puzzle tutorial is out on Tuesday.
Ps. I hope to have proper embedded code working soon.
Well, it's certainly been a long time since my last video. Here's the first part of the tutorial that accompanies it:
I had actually planned on stopping doing tutorials, or at least 'ramping down'. I got a job in November (unfortunately not related to 3D or graphics), so my spare time is a little more precious now.
In the past year, without realising it, the effects I make have steadily becoming more complex as I attempt more ambitious ideas. I think it's natural that that should happen but it means the tutorials have become a lot longer to accommodate all the extra processes and all of this has started to take up a great deal of my time. The effects have gone from taking a few days to complete to needing about a week, mainly of troubleshooting, and the tutorials have steadily crept up to the 1hr mark (edited down from 1hr 40min of recorded material).
Because of this I've actually done very few modelling projects in the past year and for someone who wants to be a 3D modeller, this isn't great. So, all my time has to be focused on modelling now and tutorials have to take a back seat for the minute. This isn't the end of the tutorials, but certainly they can't be a priority any more and this tutorial marks the end of any frequent videos.
Knowing that this would be the last tutorial and frankly, looking forward to getting it out of the way so I could continue modelling, I certainly hadn't bargained on this being the most complex tutorial I've ever done. Longer, harder ideas to explain, harder to edit, everything was more complex. And it took a whole lot of time to complete.
Turns out explaining programming is pretty difficult, some of the concepts start to seem a bit abstract when you sit down and try to explain them so I had to create extra graphics to try and visually explain them and extra annotations for things I'd simply forgotten to mention. Suffice to say that with all this added up, the tutorial was long enough that it seemed beneficial to split it up, so this video is part 1 of 4, each to be released weekly.
It's a shame, because I like coming up with projects for tutorials, I even started thinking about the next project I wanted to do. But, like I said, that has to take a back seat. If I get some time to work on it, which I hope I do, then great.