[This post was originally posted on Half-Man Half-Bird's website and has been reposted here with permission so that my future posts on this topic are not out of context.]

The problem of writing a blog post is that while I'm writing it I feel I should be working on the thing I'm writing about. That's probably why it's been roughly a month since the last blog post even though I said it would be every Wednesday. The trouble is it doesn't always feel that there's a blog post worthy amount of work done. Maybe I should do smaller more regular updates.

Anyway, on to updating you on the progress of the vfx for our project. I got a bit bored just working on the same shot all the time, it was starting to get a bit monotonous so I started work on the other two shots so that if I get tired of working on one I can switch to another. Turns out that although I originally wanted to focus on shot 2 which I felt would be the most interesting, it was also the hardest. So progress on one of the other shots, shot 3, has probably overtaken progress on shot 2 because it's a lot easier.

Shot 3 is the last shot in our sequence and it shows our rollercoaster looping around a bridge and going through one of the bridge's archways before going off into the distance. Oh and it's over water so we also have to contend with reflections. Which is fun.

Below on the left (click to enlarge) is the original frame of shot 3 and on the right is with all the geometry added.

So you can see the track is in place and then there's all the proxy bridge geometry for catching shadows or acting as a mask.

It got a little frustrating at times, the tracking gives more than a good start to the camera motion but it isn't perfect. I decided to just brute force it and keyframe out all the problems but it turns out it was nowhere as bad as I  thought. The camera needed only about 7 keyframes to give it a bit of improvement from the original track. That still didn't mean that the geometry fitted the footage perfectly, I don't know what causes that issue, whether it's still a bad track or if it's lens distortion. However I changed the geometry it still wouldn't fit at some points so again I decided to manually keyframe it. Again it was only a few keyframes on some objects, nothing major.

There were two other areas of the bridge mesh that needed a bit more work as it wasn't individual objects that needed to be animated but vertices, the archway of the bridge and another small part. For this I used empty hooks (below) which I could animate and their associated vertices would follow.

There was another part where I also had to add an empty for each vertex so I invested a little time in creating a script that would do this automatically for a set of selected vertices which should save a bit of time in the future.

The current issue to contend with is how to apply motion blur to the reflection of the rollercoaster in the river, reflections can only be motion blurred if you are using full 3D motion blur, but at the minute we're using vector blur as a post process. I'm thinking I might have to created an inverted camera that renders a fake, but 3D reflection (seeing as a reflection is basically just the geometry but upside down), but I can't actually find a picture of that to explain how that's set up for the minute.

As I said, I also worked on our other shot in the sequence, shot 1, but all I've done is set up the track in that and some proxy geometry, so it's not as far along as this shot and not really worth showing at this point.

Shaders and textures are constantly being updated at the minute, that's a given, but some shaders might have to be different on a per shot basis just to account for the different lighting conditions, it may be less realistic, but it's more aesthetically pleasing.

Now I know how easy it can be to correct the geometry with hooks the other shots feel a bit less intimidating so hopefully I can continue at the same speed when I move onto them. Onwards.

Ray.

[This post was originally posted on Half-Man Half-Bird's website and has been reposted here with permission so that my future posts on this topic are not out of context.]

So it's been a couple of weeks since the last update but things have advanced quite a bit. I'm still working on 'Shot 2' but the tracks have been laid out, rendering tests have been done and shading has started.

One of the first things I did was set up the track which was simple enough and just meant scaling the imported (from the other scene) track so everything was roughly the correct size and then match it to the geometry I had already built that represents the buildings. You can also see the support struts that I've made which 'hold up' the building, because it's not like it would end up pulling down the building or anything...

Having set up the track and carriages I then worked on a few shaders and preliminary renders. The lighting was pretty simple (once I'd figured out how simple it could be) and is just a sun lamp, the shadows of which I managed to match pretty close to the source footage. The colour's a bit off for the shadows but I was working on the direction and angle at this point. I've changed the position slightly since then and a changes in ground height to match the footage also alters the look of them.

This was also a chance to quickly test the motion/vector blur which was done after the render in the compositor and doesn't look too bad. Of course, to get vector blur there has to be some movement so I very roughly animated the carriages along the track. One issue I noticed during the render tests was not the speed of the render, which wasn't bad at all, but the time it took to load all the geometry into memory. It took a good while to load everything so I optimised the track by animating the 'count' property in the arrays so that as the camera pans the track extends, but before it's needed it isn't visible. I think I can take this further with more geometry being invisible/not rendered until it's needed.

Here's just a closer look at those support struts, they're the sort of thing you see supporting big buildings or bridges. And of course it's only after I've made it that I've found out the support strut's proper name is 'tension bars'.

And here's a quick rendered view of the track and support struts, it's a bit different to the rendering above which was done last week. The shaders were looking pretty dark and all of the reference images I'd looked at showed bright colours so I updated the shaders to reflect that, but I might try and find some in-between.

Although you might not notice it (but you'd notice if it wasn't there) I've also added a slight bevel to the blue blocks that the struts connect to and a few other objects, they were looking a bit sharp but I was thinking that they would be covered in thick paint; the bevel gives a slight highlight along the edge.

Aside from all that I also started setting up render layers and doing a quick composite in blender, even though Matt will be doing the compositing probably in Nuke. I need to do this to make sure render layers are getting outputted as intended. There were a lot of complexities involved where certain layers should be receiving shadows but not appearing in reflections but I'll probably go into the details of that in a couple of weeks.

Ray.

[This post was originally posted on Half-Man Half-Bird's website and has been reposted here with permission so that my future posts on this topic are not out of context.]

It was a long week last week. Long enough that I didn't do a blog post and barely did any work on the rollercoaster project. A week filled with waiting around for various renders to finish. Unfortunately, the renders weren't for this project but for a personal project that I finally finished yesterday. But that's not to say that there's not been an update to this project, after last weeks blog post I had a few days of working on it and managed to get some important steps completed.

The main/only thing I did was to figure out how to rig the rollercoaster to be able to travel along the track in a way that will make it easy to animate. I had a feeling it was either going to work right away and be completely simple, or take a bit more work. No need to guess which one it turned out to be then.

The most obvious thing to try when trying to get something to travel along a path in Blender is the follow path constraint and then use the path animation properties on the curve to move the object along.  It was easy enough to do for the first carriage/set of seats, which gave me a bit of hope the others would work.  When I used the same settings on the other carriages I found I couldn't just parent the other carriages to the first one and have them all move at once as I'd hoped. The first one moved and even matched the direction that the rails were bending in but the others just followed the first one and ignored their follow path constraints.

I then moved onto a slightly weirder but ultimately successful technique that I've used before. It's weird in the sense that we are basically using a tool that would normally be used for modelling, but under certain circumstances can be useful for animation. The technique uses the curve modifier to deform a single cube (one for each carriage) along the main curve that determines where the track is. You can then, and this is the quirky part of the technique, move the cube on it's local y axis (direction curve is pointing in) and it will appear to travel along the curve. You can then parent the carriage to it's controller cube without any issues.

The cube itself isn't rendered and is only used to get the 'direction' or tangent of that point in the curve. In actual fact I couldn't do a simple parent to the curved cube I had to do a parent to 3 of it's vertices. If you just do a normal parent operation the carriage wont follow the cube properly as the cube isn't being rotated as it travels along the curve, it's just being deformed. But you can parent directly to the vertices  of the cube which seems to work. Then it's just a case of parenting all these controller cubes to a single empty, the empty can then be moved and everything follows correctly. The empty also has to be moved on it's local axis so even if the curve is going in all directions you only ever move the empty on it's local y axis to move everything along.

Below you can see all the carriages bending as the curve is deformed.  I just added in a quick hook (the cube) which can control a point on the curve. It means I can quickly move the cube to deform the curve to see if the rigging is working.

The above animation also highlights another issue I had to contend with once everything was following the main curve properly.  As the curve bends, the distance between each carriage increases which caused me to have to really think about how I could actually connect the carriages together as whatever I used would have to adapt to this increase in distance. You can see that it's increasing because the arrays which make the rails are having to auto extend on the left hand side to accommodate the new length of the curve. I don't think real rollercoasters have the distance problem but I couldn't actually find any references of how the carriages are joined so I don't know for sure. I eventually went for a piston option, or telescopic might be a better word. A series of constraints mean that the beam and joining objects point to the next carriage in the line, so the beam parented to carriage 1 points to carriage 2 etc. When the distance increases more of the beam that was hidden in the 'joint' is revealed. In the above animation it's the line of objects below the main rail.

It was pretty important to get that done because without it animation could have become really tedious. Another bonus is that it seems to move really quickly in the viewport, but there may be a bit of a slowdown once the rails are fully extended.

Next is to extend the track and match it to the footage and construct the support struts which connect the 'coaster to the surfaces.

Ray.

[This post was originally posted on Half-Man Half-Bird's website and has been reposted here with permission so that my future posts on this topic are not out of context.]

In our last post we outlined how we got on getting our footage for this rollercoaster project. I wanted to get started pretty quickly with this project and I'd actually already started modelling the rollercoaster before we had the footage, but seeing as it was the tracking that I thought would give the most problems I changed focus to trying to get Shot 2 in our sequence tracked. This would effectively work as our test shot; if we could get this shot done we could continue with the rest of the project, and if I decided it couldn't be done then we would move on to something else. I think I was right about this being the most difficult part (at least so far).

I started by brushing up on my knowledge on the camera tracker in Blender 3D by watching an excellent tutorial by Sebastian Koenig. I wont quote directly what he said but it was roughly:

And Shot 2, the first shot I was tracking, the first real shot I had ever tracked, the first time I was using Blender's tracker? A shot that contains just rotation and is effectively a tripod shot. Great. I actually got a little worried at this point and thought we would have to re-film everything with added motion, but Sebastian also mentioned that the tracker should get tripod support in the future, and luckily, after a quick google, I found that it now did.

So then began quite a lengthy process, which isn't over yet, of tracking the Shot 2 footage in the hope of getting a solved camera. The actual process is quite easy, but thanks to a hefty amount of motion blur due to our fast pan it's probably not as accurate as it could be, so I added a few manual keyframes to the camera to correct a few glitches in the motion. I don't think when it's all done that the camera tracking will be perfect, but I think it will be close enough. The other shots should be slightly easier as there's no major movement, just a bit of camera jiggle.

Then comes the easy part in the project, you've got past the hard part, now onto the easy rewarding part. I've tracked the camera, so surely the proxy geometry that will have shadows cast onto it will simply pop into place, how hard can it be? Surprisingly (or not, if I'd remembered all the other projects that were more difficult than expected) things didn't turn out like that. For whatever reason, perhaps my inexperience, it was really difficult to get the geometry to line up with it's real world counterpart in the footage.

The geometry on the left of the picture now thankfully matches the footage pretty well, but at the moment the geometry on the right, although vertically straight, as I think it should be, isn't lining up yet. I think it's because of the camera distortion as the geometry seems to be less accurate the closer to the camera it is. I'm just going to have to change the geometry to try and match the warping in the footage which feels like cheating, but then isn't all of CG cheating?

I haven't yet spoken about the actual rollercoaster model that I mentioned at the beginning. And that's simply because it wasn't much of an issue, apart from a small problem that was fixed with a few constraints. Annoyingly it seems while the internet is full of pictures of cats there are very few blueprints or even up close pictures of rollercoasters, so much of the general design is my own creation from whatever information I could glean from wide shot photos. The wheels that clamp onto the track though seem to be standard among most rollercoasters, so I managed to find a few detailed pictures of them.

I'm quite pleased with how the roller coaster model is set up. The whole thing is controlled by one central curve. The track will automatically extend when the curve is extruded and when the curve is deformed the hanging seats (which need a better name) will rotate to match the curvature. Everything can then be slid along the track with a single empty controlling everything.

So that's pretty much it. Tracking and modelling this week, probably more modelling next week with hopefully a few test renders. One thing I haven't yet investigated is whether we're going to be able to use motion blur in Cycles or do it as a post process....

Ray.

[This post was originally posted on Half-Man Half-Bird's website and has been reposted here with permission so that my future posts on this topic are not out of context.

Unlike the other posts this was written by Matthew Griffin and not by me.]

I'm delighted to be on your screen telling you what our new project is all about. Put simply, we're going to put a rollercoaster in a town centre. London was lucky enough to be graced with its one whole day of Spring on Tuesday, so we took our opportunity to go filming in the small town of Kingston in South West London to get our source footage.

We shot with my EOS 7D and 18-135 EF-S, and we went hand-held. The traffic and pedestrians also proved a problem, as the street we to used is primarily a load of bus stops, and last time we checked, we couldn't get a rollercoaster through a double decker bus. Also for technical reasons, the fewer buses, cars and people, the less reflections and shadows have to be faked later on.

Below is a frame from our footage - imagine the rollercoaster coming down from the distance and around towards the camera, before flying off to the left, where the camera pans to follow it.

We shot two other shots as well, one slightly further up the street and one by the riverside all in 1080p, but we may just use 720p and use the extra pixel space for  a bit of re-framing, but it's useful to have the higher res if we need it.

We also need to make sure that any 3D we put in the footage, which is a lot (all of the windows need to be replicated in order to reflect the roller coaster, the buildings need to cast shadows etc.), can be lit realistically. For that we needed some environment photos. There isn't really an easy way to do this, and we didn't fancy standing in the middle of the street and taking an HDR image of a chrome ball (which we don't actually have). iPhone and Photosynth by Microsoft to the rescue! Photosynth is almost the perfect app for this, as it creates a 'photo sphere' which can then be exported as an equirectangular image (below). We don't get the same light range as an HDR image, but it should be good enough for what we want.

We didn't use a full spherical panorama, we just took all we needed to without looking too suspicious, as the sky  and the paving can be fixed later. The images have some slight oddities where the joins are, but only have to correct the major ones, (including the severed limbs that appear at some of the joins). The rest won't be noticeable, as this is only to cast reflections and accurate lighting on the model. See our photosphere below, for the shot in the image above.

We're doing this project shot by shot, as we may not actually be able to pull it off how we imagine, and we're not going to release something that is sub-standard. We can always add more shots in later if these turn out alright. First, we have to test if we can actually track the shots, before we do anything else, as if we can't - we're pretty stuffed!

So that's what we're up to, and how far we've got so far. We don't have a clue how long it will take for us to finish this, but we will post a weekly update on this page, and also minor updates/information on the Twitter-sphere.

Matt