I haven't posted here much, but I'm hoping to do a weekly post of what work I've been doing each week. Seeing as I haven't done a blog post for a while, I'll cover a few things I've been working on in the previous months. Does that sound fun? I don't know, but you've already loaded the page now, so you may as well read a bit more.
An interesting little experiment in Blender I did a few weeks ago is something I'm calling 'Scene Nodes'. Blender used to have something called the 'Oops Schematic View' in the Outliner, which allowed you to view your 3D scene in a visual, node based way, showing the relationships between your assets. This feature never made it into the revamped Blender 2.5 so I thought I would have a go at recreating it with Python. Partly, that was because I just thought it would be fun (it was 50% fun, 30% googling, 15% deciding what colour each node should be and 5% crying) but also because I thought that if it proved to be popular I might develop another add-on to sell on the Blender Market.
The result above shows all the different objects and materials in my scene and also the relationship between them. 'Cube.001' (orange) is the child of 'Camera.001' (grey) and also a parent to 4 objects (orange) and a lamp (yellow). I got it working so that not only could you press a button to generate this node setup, but that duplicating nodes would duplicate the actual object, deleting a node would delete an object and changing the connections between objects would change the real object's parenting.
Before you go rifling through you wallet to find money to throw at the screen* (because you obviously love the sound of it, not because you're misguidedly attempting to throw loose change into my eyes), while it was quite fun to do, I'm not entirely sure that there's enough interest in it for me to make it an add-on. My last add-on wasn't really cost effective, considering the development time vs monetary return. I'm not ruling out making it an add-on, but I don't think it's a 'high-priority' project.
*and people say I'm a fantasist.**
**If anyone of importance is reading this, I'm lying, no one has ever called me a fantasist. It was just a joke, which we (I) here at www.RayMairlot.co.uk deeply regret.
Experiments with Unity:
I've also been making a game with a friend, not in Unity as the title might suggest, but in Flash. Flash might get criticised a lot, but for making a cross-platform game it really makes a lot of sense (to me). However, I'm well aware that several sites are moving away from flash, at least for video delivery, so I thought I would make some investigations into other game engines, just in case the day comes that Flash content is no longer run by web browsers.
I decided that I would try out Unity as it has a free version and I got to grips with one of the tutorials. I wasn't best pleased to find my simple tutorial scene of a ball rolling over a plane, collecting yellow diamonds, came to an eye-watering 170MB. God help me if I try something complex*. Maybe I can cut that size down somehow, but at least it does cross-platform publishing pretty easily.
*Dear God, I know you're busy, but please help me squash these megabytes. If you help me (for free) I'll tell everyone it was you that helped me and I think that will be great exposure for you. Thanks, Ray.
I had originally thought that if I wanted to learn Unity it would be better if I already had a working game in Flash, so that when trying to re-create it in Unity I wouldn't have to be worrying if the logic of the game was correct, only the conversion of AS3 to C# (one of Unity's coding languages). I made a little Tetris game in Flash, but having seen the large file size Unity creates I was put off from actually trying to convert it. I realised that Flash is still the better option for me, but that Unity was a viable alternative if I really needed it.
That's not to say making the Tetris game was a waste of time; it helped me a lot with realising how to implement OOP concepts properly, which I can put to good use in the game I'm making in Flash.
All in all, quite a few experimental projects, but now I'm back to my main one, which I may start to reveal soon. Or not, know one knows. If people say they know, they're lying.
Unless that people is me.
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 ;)
You really do start to realise how big a vfx project is once you get to the compositing.
Take shadows for example. This became (and continues to be) perhaps the biggest part of the post processing. I already knew I would have to build any object in 3D if it needed to receive a shadow, but there were several things, having never done a project like this from start to finish, that I didn't realise until I came to the compositing:
There were a lot more objects in the scene once I really started to look. Originally I just thought I had to build the main buildings and surfaces. But no, as I looked closer, railings, people, buses, taxis...the more I looked the more I found. Luckily most of this didn't require any new techniques, just more modelling and quite a bit more animation (more on animation in a separate post, later).
Most of the objects can be dealt with quite easily as they're stationary. There was, however, one pedestrian who was walking across the street and was close enough to the camera that the shadow couldn't simply go over them flatly but for realism should match the contours of the body.
I already had a person armature and model from the people I had made to sit on the rollercoaster so it wasn't much of a problem to re-use this model and animate the armature to the person in the footage. It was a bit tedious, and if you saw the 3D view from any other perspective than the camera you might think this person didn't have a lot of bone structure, with knees and elbows bending in directions that would make you wince. Nevertheless, from the camera view the little 3D figure appears to cross the road matching his real-world counterpart fairly well with shadows falling over his body instead of being flat, like some of the more distant people can afford to have.
If mid-ground people weren't annoying enough to recreate, then boy was I in for a treat when I noticed all the fore-ground people, with more detail than my generic 3D human could handle.
When we originally filmed, it took several takes to find one that didn't have cyclists or buses going right through the middle of the shot, but even so, it was impossible to film on a busy street without there being some pedestrians and vehicles in the way.
Any person that appears in front of the shadow means that a part of the shadow has to be removed. The only way to really deal with that was with masking, so I had to painstakingly mask the 3 or 4 people walking across the shot frame by frame. Frame. By. Frame. This was not enjoyable even though it was a fairly short sequence. But, once complete a simple 'Math' node could add the white mask back over the top of the shadow pass, cancelling out the shadow in one fell swoop.
These two previous points are annoying but at least I was already aware of those issues even if I wasn't completely aware of the scale they would need to be dealt with. Which left the detail I hadn't been aware of:
The footage has existing shadows. This sounds obvious. And it is! Of course there are shadows in the footage, things in the real world cast shadows. But what was less obvious is that I would somehow have to stop the CG shadows from overlapping them. If they overlapped there would be a dark patch, you can't cast a shadow onto something that's already in shadow without it getting darker than it should be, so the shadows have to very precisely stop at the exact point the real shadows begin.
This started to worry me slightly, I'd missed something which seemed obvious and I wasn't immediately sure how to solve this...
I realised that unless I wanted to try and roto (mask) the shadows very precisely I would have to attempt to use a technique similar to how I'd extracted the ripples from the river. My thought was that I could create a rough mask around the area in the footage with the existing shadow and then isolate the darkest parts of that area, which should be the shadows, with colour correction. For the most part this does seem to work, there's still a bit of fine tuning to do at the exact join between real and CG, but the vector blur helps to, well, blur that line.
A lot of work for just one part of the compositing and there's still lots more to do. Aside from compositing though, putting the people on the rollercoaster was a fun little exercise so I'll try and cover that next time.
In the last post I said I would talk about the Futuristic Car 2 project, but, well, enough time passes between these posts that I'm not always working on the thing I said I would be. I certainly was working on the other project, and I will definitely write about it at some point, but not today. It's always nice to have a little break from longer projects, it's easy to start to get sick of a project if you work on it solidly for too long so I reverted back to something I haven't worked on for over a year: The Rollercoaster project.
This time around I've mainly been working on updating the materials, which has been really quite fun to get back to, and feels relatively easy compared to the other project's myriad of objects, hierarchies and scripts. The materials didn't have to be updated, there's plenty of other things that aren't finished, but in the year since they were first created an anisotropic shader was added to Cycles. I thought I would at least update some of the brushed metals to use them. But of course, I ended up doing a lot more than that.
Here's a nice shot of the wheel the wheels on the rail and the base which connects them to the 'coaster:
Some of these materials have already been updated further, so there's a bit less wear and tear on the purple bolts and the gold wheels now have a bit of dirt on them.
This kind of detail, the worn edges, the subtle bumps and dirt maps are all unfortunately fairly irrelevant. The rollerocaster will be going fast enough that motion blur will hide most of this work, but I can't knowingly release something that's meant to be realistic if I know I could have made it better. Besides, it does at least give me a nice asset to show off in my portfolio even if the final video doesn't quite make the most of the work I've put into it.
With that in mind, I'm working on a few tricks to render a slightly closer camera than the original tracked footage might appear to allow to show at least a bit more detail...
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.