Well the weeks have rolled on since my last video and finally the new effect is finished. This took a while...

This video will eventually lead to my first tutorial really that focuses solely on python in blender. The script I wrote can basically take a few parameters such as the grid size, the number of moves (to mix the puzzle, the more the better/slower) and the number of frames each move should take.

This takes a specified 'tile' object and generates the grid based on it, I could have used just a flat plane or squashed cube for the tile, the script would run quicker, but I wanted it to have 'tabs' and grooves just like the real thing. It looks good, but the more verts the slower the script. You also have to set up the material beforehand, just to basically choose the texture, the script does the uv mapping.

The puzzle starts from the 'finished' position and the script animates each tile randomly to mix the puzzle. Keyframes are recorded in such a way that when played forward the animation appears to descramble as it goes on. There's also a few other things the script does such as printing out useful output to the console to show how far along the script has got, the final 30 x 30 grid at the end of the video takes a fair few minutes to create so it's nice to have progress reports. I also factored in that after you've run the script you'll often want to run it again but with different parameters, so the grid can also delete the old grid before creating the new one if you want.

This isn't going to be a beginner python tutorial or even a beginner python in blender tutorial, this is probably for people who've already made a few small scripts themselves using the blender api.

Ray.

So here's my latest tutorial based on the Icing Effect from a few videos back:

There's not a huge amount to say specifically about the techniques demonstrated other than it solely focuses on the creating of the icing and not the materials or rendering, but I talk about that in the video anyway. As often happens, I managed to improve the technique from the original video as I was preparing for the tutorial (more on that in a separate post), which is helpful because I wasn't particularly looking forward to recording this. It was a difficult effect (as they all seem to be) and the technique was particularly hard to develop as there didn't seem to be a definite explanation as to why certain things had to be done, which kind of undermines the point of a tutorial which is to teach.

Nevertheless, things did get easier and the overall process, while still difficult, is a lot less difficult than it felt while making it. Good organisation definitely helps, particularly when dealing with a rig with lots of controllers, something I lacked when I was making it...

Ray.

Introducing my latest effect, Inflating Text:

So this effect was a real tough one, it was really difficult at times to get it finished. I had to switch techniques after having worked on it for a few days and had already given up on several other effects when I realised they wouldn't work, so it felt like it took a long time to complete.

The effort was worth it though, I was really pleased with the final effect once I eventually got it finished and it attracted quite a bit of attention which was even more pleasing. Apart from getting a lot of positive comments and +1's over on the Google+ Blender Commnity (and people attempting their own versions, just hours after it was released, here and here) I had my work featured on Blender Nation, had a blender developer questioning how I achieved the effect and just over a week later it has 9,000 views.

As usual, there will be a tutorial at some point but I can't say for sure when. The basic technique is to reverse a cloth simulation so that instead of the text collapsing it appears to, well, inflate. When I first started this effect I had done the cloth simulation part and then spent quite a bit of time on working on reversing it. The normal way that a simulation might be reversed is to render out the sequence and reverse the image order before laying it over the top of a render that's going forward.

 I had come up with a different way to reverse it and it should work on any of the simulation types that can have an external cache. But that will have a separate tutorial all of it's own so I'll leave that there for now.

Suffice to say I had got quite far in using that technique before realising that it wouldn't fully work. I had wanted a slight deflation to occur each time the pump....pumps, so that it would inflate before deflating slightly as if the connecting valve wasn't 100% efficient and some air was escaping. This wasn't compatible with the reversing method I had used up to that point so I had to work on a new one.

The final technique I ended up using was to use a cloth simulation as I had done before but then applying it as a shape key at different stages of completion. The shape keys can then be animated on in the desired order (reversed) to give the inflating and deflating effect. While that solves the main technique there were a whole lot of smaller things to do before the effect was complete such as building, rigging and animating the pump, disconnecting the cable before the text shoots off, deflating the text as the air rushes out and then timing the whole thing into one cohesive animation.

All in all a lengthy and at some points stressful process but the outcome was worth it.

Ray.

I've put the rollercoaster project on hold for a bit. I did a bit of work on it the other day, which I'll talk about in a separate post, and I might work on it as a break from the current project but I just feel I should be focusing on work for my showreel.

While the rollercoaster project is something that will be included in my reel it's a bit more general than my modelling 'remit'.  Sure, it has modelling, but it's focus is vfx which is a bit more general. I've always heard you should be quite specific in your reel and that it should clearly represent what you want to do so I'm working on a more modelling heavy project. I'm not going to talk about it at the moment, for some reason I like to keep most of my projects secret, as if I've got a huge audience waiting in suspense. But I'll do a few posts once it's out, it's a complex project (for me) so that may be a while.

This post is basically just announcing two new videos I released. It was originally going to just show one of the videos but then I left writing the post for so long that a new video was finished by then.

The first video is a new effect based on icing:

It's one of the most complex techniques I've used so I'll have to try and work out a smooth workflow for when the tutorial comes out. It makes use of semi-complex drivers (depending on if you've used drivers before) and it also has a pretty complex control system. It also takes a lot of repeated work for each curve that makes up the text, there's no easy way to duplicate it, it's all custom, so this is better for simple logos or shapes which require few curves rather than full words.

The second video is a tutorial for one of my favourite videos so far, Ice Shatter and Crack (a preview of the effect is at the beginning of the tutorial):

I was looking forward to recording this tutorial because most of the techniques seem pretty simple, but when it came  to recording it was the longest recording yet at 1hr 45min (looking at the timecode in the video above shows  how much usable footage I tend to get).  The techniques are simple, there's just quite a few of them and then I cover scripting a bit which takes a bit more explanation and I'm not sure how well I did on that. I tend to always get  a few people who say that the tutorials aren't suited for beginners and I'd agree, they're not! They're intended as intermediate, if you're a beginner and you can follow it then great, but this is even more true with the small scripting section. I give an overview, but it's really an overview for people that don't find programming a completely alien subject, maybe they've done another language or have tried some basic stuff out. This was more to say "Scripting can be very useful if you only know a small amount, here's how you could use it", rather than "Let's learn programming from scratch!".

I'll probably do separate blog posts for both the subject of tutorials (both my techniques and in the context of the blender community) and scripting.

Ray.

I've just finished my latest video and thought I would give a few details (ok, it turned into quite a few details) as to how it was created. The finished result is below.

Intro

There are several different elements that came into play to create the finished result:

• Fracture the original object
• Use the game engine to get physics (by recording game engine to frames)
• Use a particle system for the smaller shards
• Manipulate keyframes to create reversing effect
  
• Control the particle system so that it pauses and then 'reverses' (it merely gives the impression of reversing)
• Using the compositor for the final look, including motion blur, depth of field etc.

Materials

The first thing I quickly decided on was the fact that I wanted to use the classic Suzanne model in blender as the focus was the effect and not the modelling. Secondly I knew that I wanted the material to make it look like a jewel and luckily I had the perfect HDRI image for creating this effect courtesy of http://ict.debevec.org/~debevec/Probes/ (I used the Grace Cathedral).

Game Engine

The second part and one of the main points of the video is the actual shatter effect. After a quick scope out of the various posts on Blender Artists looking for a suitable script I foolishly realised that Blender already comes packaged with a fracture script and I started playing around with the settings to get a good result.

Having made several attempts to create the shatter effect by using a particle system I realised that my only option was to use the game engine (not one I wanted to resort to as my ATI graphics card has issues when using the game engine). Knowing that I would be using the rigid body features of the game engine I set the monkey model to be a rigid body with a 'Convex Hull' collision bounds type before using the fracture script. When the fracture script runs it keeps any properties the single object had and copies them to the individual shards that are created, so it makes sense to choose any settings before fracturing.

Now I knew that I could do the smaller shards with a particle system and it takes a bit of pressure off the game engine as although it can handle hundreds of objects it can be a difficult to control them, so a particle system it was to be (I'll get on to the particles a bit later, this just explains that only the main shards are controlled by the game engine). This meant that there would be relatively few shards created by the actual script, in the end I opted for 20 shards to be created (once enabled script appears in search menu, press T after running the script to see the options) as I wanted them to stay quite bulky.

I wasn't quite sure how to get an explosion to work but when I ran the game engine as a test the objects exploded simply because that's what happens when the objects are too close together in the game engine, it treats it as a collision. So problem solved, almost. I turned the gravity property in the scene settings tab to 0 so that the shards would continue to fly outwards, but there seemed to be quite a few that flew downwards anyway due to their collisions. Because I wanted a more spherical explosion I created a small static object that was placed in the monkey head which would cause a bit of an extra collision (below).

Logic

This worked technique (previous section), but to enhance the effect I animated the scale of the object to increase in a couple of frames while still intersecting with the monkey head. To get this animation to work in the game engine I set up a few logic bricks (not something I'm familiar with, so although it did the job it's possibly not the best way to do it) shown below.

I set up a game property (press N in the logic window to bring up the property window) with a default value and then set the sensor to listen for when that property was zero. But seeing as the property was already zero it set off as soon as the game loaded, which is exactly what I wanted. The sensor is connected to an FCurve Actuator which is how the scale animation is loaded into the game engine.

After all this was set up I set up the game engine to 'Record frames' from the Game menu so that after running the game I could manipulate the keyframes of the objects in the time line.

Particles

Having created the main shard explosion I now wanted to create the smaller particles that would act as tiny shards. To do this I created several different objects that would act as my custom shards and grouped them (shown below).

 

I then went into the render settings section of the particles tab (I applied a particle system to a sphere) and chose 'Group' and plugged in the name of the group of custom shards I had made, I also checked 'Pick Random' (shown right).

What these settings do, for those that perhaps haven't used them before is to replace every particle emitted with a piece of geometry from the group we just plugged in. 'Pick Random' simply says to randomly choose 1 of the pieces of geometry from the group when emitting a particle. I also turned off the emitter check box which is also in the screen shot to the right to make sure that the sphere that the particle system was applied to didn't show up when rendering.

I wont totally go into all the settings for the particles but a major point is to turn off gravity completely in the 'force field weights' section of the particles tab, allowing the particles to continue to fly outwards like the bigger game engine shards.

The Reverse

We now have all the shards that we need and we just have to get all the shards (both particle and game engine ones) to pause and then reverse back into the monkey head. I considered just reversing the image sequence once rendered but I thought this would be a bit obvious and I also wanted to have a different camera move on the reverse part of the animation.

All the game engine shards are easy to reverse as they have keyframes. I selected the objects and opened up the 'Dope Sheet'. I then selected a point that I wanted the shards to stop expanding at and deleted all keyframes after that (press B to box select groups of keyframes at a time). To get the reverse effect and pause you have to select all of the keyframes and duplicate the whole section for all the shards and move them along the time line leaving a 50 frame gap between the first lot of keyframes and the new duplicated ones (same controls as in 3D view, so Shift+D to duplicate and G to move). Click to confirm their place and move the timeline marker (the green vertical line) to the centre of the duplicated group of keyframes.

Select the duplicated frames and press S and then type -1(minus one), this reverses the block of duplicated frames, the timeline marker was important as when you scale keyframes Blender uses the timeline marker as the centre point for the scaling operation. You should have something like the image below except for all the shard pieces.

The shards should now animate outwards, pause, and then reverse back together to create the monkey head. the orange bar in the image above shows that there is no change between the 2 keyframes that end and start the blocks of keyframes, creating the pause.

To create the pause effect for the particles was a bit difficult to figure out, but quite easy to implement once I realised what settings needed to be changed. The main thing that will stop the particles in their tracks is the dampening value on the physics section of the particles settings. This will need to be an animated value (hover cursor over and press I - i not L).

To reverse the particles I created another sphere and placed it over the sphere that has the particle system applied to it. This new sphere will be the forced field that drags the particles back to the centre whether they like it or not. Set it to be a force field in the physics panel, the only settings that have to change is the strength which will have to be a negative number to bring the particles back in. The strength value will have to be animated from 0 to whatever strength you want (I set it to -0.150) and be in time with when the keyframed shards start to reverse.

This new sphere also has to be a collision object so that once the particles are dragged back in they are killed, so set the object to be a collision object in the same place you set it to be a force field and check the box that says 'kill particles'.

You may find that when the particles are meant to be paused by the dampening value that they continue to spin, I found that I had to set the initial rotation for the particles to be 'none' and then animate the 'spin' value to control the spin of the particles.

That effectively concludes all the elements that make up the shot apart from the camera move, which is up to you. To get a similar lighting effect the next section is about the compositor.

The Compositor

I'm not going to explain the whole compositing process as you can get a lot from the image below, but I will just add a few things worth noting:

• To get the speed value for the vector blur to appear you have to make sure that 'Vector' is checked to render in the 'layers' section of the render tab.
• Because I didn't want the HDRI map to appear in the background of the render I created another scene and used the background from that. You have to set alpha to be 'premultiplied' in the shading section of the render tab of the main scene to allow the background to be transparent. But this depends on whether you use an HDRI map at all.
  

End

Phew! That was longer than expected, hope someone finds it useful.


Ray

PS. I used a little script explained here, which reduces the number of keyframes on objects that have physics recorded from the game engine.