Disassembling a 3D/CGI Scene (Detailed Version)

Perhaps some of you saw my 2016 Christmas card?

It wasn’t what I intended. Back in October last year, I’d actually planned to create a 3D/CGI image, and at that point Christmas seemed aaages away so I thought I had oodles of time. But the festive season is sneaky. There you are, bumbling along in the normal routine of things, working, exercising, eating, and so on… and then suddenly it’s mince pies, and presents, and carols, and tiny flecks of glitter stuck to your face from all the Christmas cards.

Anyway, ‘oodles’ of time became no time at all, and I ended up hastily bashing some Lego bricks together instead, to create a desktop Santa and Rudolph scene. Now, I haven’t owned any Lego since I was about 12, so I’m definitely no expert-level builder, but the results were kinda cute. I think I got away with it.

So, yeah, no CGI.


OK, I’ll come clean. It’s not Lego. I mean, it’s Lego, but entirely virtual. The 3D/CGI scene I’d planned way back in October is actually the one you can see above. It’s a photo of my desk, with my studio equipment, and some Lego bricks modelled in my 3D app, then composited in post with Photoshop.

I know… I could have just said this right at the beginning, rather than write two paragraphs of a LIE.

I’m weird. It’s OK. I do it so you don’t have to.

In truth, I thought it would make a nice surprise, for folks to see that the Christmas card wasn’t really, er… real after all. An illusion. Smoke and mirrors. An allegory for life, if you will. Or won’t. Whatever.

Below I explain the techniques; the software, the tips and tricks. Everything I did to create the scene. If you’re pushed for time/patience and want a really short explanation, try this link instead. Otherwise, keep reading!

1) The BIG idea

Every year since 2013* I’ve created a digital Christmas card, which tests my modelling, and/or, illustration and compositing skills. It’s cool because I can send it out to all of my friends across the world, via social media, without having to pay for hundreds of individual cards and stamps. Not that the ‘paying for’ bit is the main reason, obviously… I mean, it’s also *very* ecological… think of all the trees I’m saving! Right on!

I work in the digital graphics field, so I use 3D and 2D tools every day. However, it’s nice to have a personal project, to really push me and my equipment. I love Lego and I liked the idea of creating something that looked real, but wasn’t. This deceptive attitude comes from my sixth form art teacher, who instilled in me the idea that making art was a tricksy thing at the best of times, but if you could present an image or object that belied its nature then you were winning. Or something.

* Not 2014, or 2015. But every year, OK?!

2) The Tools

Before creating the individual bricks in my main 3D modelling software, I needed to work out if the objects I had in my head would a) look good, and b) actually work as real models. I wanted to build Santa’s sleigh, with a minifig Santa sitting in it, and Rudolph. Fortunately, there are a number of online and standalone virtual tools/applications that utilise Lego brick libraries, allowing you to build any model you wish, within a 3D environment. After playing with a few, to see how they worked, the one I plumped for was Lego Digital Designer (LDD), which is actually Lego’s very own software. It has a nice, clean interface, and as you’d expect, an extensive library of bricks.

Link to Lego Digital Designer

Sadly there are no more updates planned for this tool… but I believe it will still be available to use in its current version for some time yet. Go and have a play. It’s great fun! And no need to tidy up afterwards!

3) Initial Build

Using LDD meant I could test ideas/builds, until I was 100% happy with how the models looked, and also make sure that they would hold together in the real world, just like a real Lego model. I was keen on only using basic bricks where possible, rather than custom/kit pieces, so that anyone with some Lego at home could build them too.

After some mucking about, this is what I ended up with:

Initial build in Lego Digital Designer

As you can see, it’s definitely Lego, but it’s a bit cartoon-like. To be fair, LDD is not meant to be photo-realistic, it only has a basic OpenGL rendering engine… it’s just a fun (and very useful) tool. And for my purposes, it didn’t matter what the models looked like in these initial stages because I was going to export the LDD bricks to use as templates for modelling in my own software. The exports would provide accurate measurements for each brick type. Yahooo!

4) Exporting/Importing

For over 10 years now, my main modelling software has been Modo. It was created by a company called Luxology (now The Foundry), who were originally part of the core development team behind Lightwave, which was used for creating VFX on shows such as Babylon 5. Modo has been used in the production of movies such as Iron Man and Wall*E (awesomeness!) and is a subdivision surfaces modeller, though not only that… it’s a powerful and flexible application with its own incredible – and much revered – rendering engine. It plays nicely with most other software, too, with a whole host of import options, for models built in other applications.

Unfortunately, LDD doesn’t have a wealth of export options, the main two being .lxf and .ldr. Neither of which are recognised by Modo. Ouch.

OK, I needed a bridge application… something that would import either .lxf, or .ldr files, but then be able to export in a format that Modo could work with, say, as .3ds, or .obj. I initially looked at Blender, which is a free and very competent modelling/rendering/animation package:

Link to Blender

I had to install a plug-in for the .ldr format (and bricks library) to be recognised and it did the job well enough but the resulting import into Modo was really messy. It was hard to see what was going on with each file… each one needed a fair bit of clean-up before I could even start creating my own bricks.

Messy import

I needed a better option. A bit more Googling later and I’d found an application called LeoCAD, which is another self-contained (and free!) Lego modeller, with a good bricks library. It could also import and export the file types I needed and, fortunately, the results were pretty clean too. Yay!

5) Building

Lego bricks are fairly basic (being mostly cuboid) and modelling them is easy. Once I had good templates from LDD, via LeoCAD, it was a relatively quick task. I also only had to model one version of any brick, of course, because I could copy it multiple times. It therefore didn’t take very long to create the 200 or so bricks I needed, and putting them together as a Lego model was a snap too.

There are two main modelling methods in Modo; standard polygon, and subdivision surfaces.

Standard polygon modelling is essentially triangles or, preferably, quads stitched together to represent a 3D surface.

A sphere (or any curved surface) created in this fashion appears smooth when viewed from a distance.

Polygon modelling1

But get up close and you can see the individual faces as a series of steps. This effect can be nullified somewhat by increasing the resolution of the object (essentially making all faces smaller, and making lots more of them), or creating extra faces at the edges to create bevels/chamfers, but it’s still only going to work to a point. And adding extra geometry to objects can make for an unwieldy scene.

Polygon modelling2

Subdivision surfaces, on the other hand, have mathematical smoothing applied based on the amount of polygons present in an object. Curved surfaces will appear rounded/smooth at whatever distance they are viewed.

Subdivision surfaces modelling1

Subdivision surfaces modelling2

I normally model everything as subdivision surfaces for the above reason, but in this case I would have been adding unnecessary geometry. It made much more sense to use standard polygon modelling, and apply the ’rounded edges’ function in Modo. This is a render-time effect, i.e. it’s only seen when you render the object/scene, rather than it being visible in an OpenGL view, or actually present as geometry.

Once I had created material tags (names) for the bricks, I could then apply this rounded edges function, along with colours, and other effects, to make them look like the real thing.

Right, now it was starting to look good.

6) The Logo

Since 1954, every Lego brick has had a logo on each of the studs. My models would use a fair amount of flat plates, but I wanted to keep a few studs exposed for added credibility. I tried a displacement map at first, which is where information within a greyscale image is used to produce render-time geometry. Essentially, black equals low, and white equals high.

Displacement map and resulting logo

The results are OK but the problem with displacement maps is that to get a really smooth finish, you need to crank up the settings, which causes render times to go through the roof. Therefore it made more sense to model the logo with real geometry.

Real geometry logo

The results were good… really clean. And because only a few studs were going to be exposed, the scene wouldn’t suffer from being too polygon-heavy.

7) The Man in the Red Suit

I needed to model a minifig Santa to sit in the sleigh. Luckily, I’d made a base minifig model about a year ago that I could customise the colours for, and add a hat, beard, and decals.

Base Minifig wireframe

Base Minifig render

Et, voilà!

Santa Minifig wireframe

Santa Minifig render

8) Other objects

There were a couple of extra objects that I needed to create for the scene that weren’t Lego bricks; namely the reins, and the reins attachment/halter to go around Rudolph’s neck. Because this was supposed to be a real Lego model, I wanted these objects to be things that you could find in the house. So, for the reins I modelled some twine, and for the halter, I modelled an elastic band.

The elastic band was easy… but the twine was a bit of a challenge. I create some tubes that twisted around each other for the main twine object, and then used the hair/fur options in Modo to give the tubes some random fibres/strands. It took a fair amount of tweaking, and test rendering before I arrived at something that was believable, but in the end I was happy with the results.

Twine reins render - untextured

Twine reins render

9) Lights, camera, action!

OK, there’s no action (unless you count me frantically eating copious amounts of Maltesers to keep my brain sugar-ised) since this was going to be a still image… but there are definitely lights and a camera! At this point I needed to set up the background plate (photo of my desk) as a front projection for the 3D camera in Modo, then adjust this so that the models matched the angle of the desk in the plate.

I set the 3D camera viewing angle to 28mm, which is the same as my HTC phone on which the shot was taken, then created a ground plane and a cube, so I could more easily perceive the correct angle.

Ground plane with cube

Once I was satisfied I had it right, I then had another use for the ground plane. In it’s current state, it obscured the background plate, which was obviously no good. However, there’s an option in Modo for using a ground plane as a ‘shadow catcher’. This is not some cool detective type character, who arrests ghosts, which is a shame… but the reality is almost as awesome. Honest.

One of the secrets to good compositing is… shadows. Compositing is the blending together of several images and effects, like shadows, to create a single image. Shadows are key because they provide a way for any models you place in a background plate/photo to sit properly, and create what appears to be genuine contact with a surface.

The shadow catcher option within Modo turns a ground plane transparent, apart from where shadows are cast on its surface. So, the surface vanishes, but the shadows remain. Soft edges are preserved because the plane is turned into an alpha image. Alphas are used all the time in 2D/3D processes to mask objects. They denote how pixels are merged together when two images are overlaid.

Cube and shadowcatcher

This means that when I render the image, the model shadows look as if they’re being cast on the background plate/photo. Oooo!

You can create reflections in a similar fashion too, though there are few extra things that need doing to the objects, and ground plane, in order to get the best results.

10) Final render

When modelling, or creating a 3D scene, it’s essential to perform test renders as you go. Rendering is where the computer calculates all the parameters and options you set, including object colour, object surface properties (is it glossy, bumpy etc.), reflection, refraction, lighting, shadows and a whole lot more besides.

I’ll ordinarily press the render button hundreds of times during a build, and since rendering can take a while, especially full/final scenes (and especially with my machine which is getting a bit long in the tooth), it can be a time-consuming business.

Once I was completely happy, I set up the final render size, which in this case was 2000 x 1116. A strange aspect ratio, admittedly, but I’d already cropped the background plate/photo so I just went with it. There are several options for rendering in Modo, including the ability to create alpha channels, depth-of-field layers, and so on. Each of these separate renders can be combined later in Photoshop, to create the final image. If you don’t have Photoshop, there are free tools available, like GIMP.

Alpha layer render

Depth-of-field layer render

The alpha channel, as seen above, is a pure white render of the objects in a scene. It can be used to mask off the full colour 3D rendered objects from a background plate/photo. This is useful is you want to, say, adjust the colours of the rendered objects without affecting the background, or vice-versa.

The depth-of-field render is made up of different levels of grey. If you take white as high/on and black as low/off, you can see how these grey shades coincide with the distance of objects to the virtual camera. So, whiter/brighter is nearer the camera, and blacker/darker is further away. If you use this depth-of-field render as a mask in a photo editor, you can affect the image in a more natural fashion.

11) The Compositing Bit

Nearly there!

OK, the full-colour render was done. The extra channels/layers were rendered out. It looked pretty darn good, but there were still a few little adjustments needed to REALLY sell it! 3D/CGI renders are notoriously clean, whereas photos often have a degree of noise present. My phone camera isn’t the best, and shots taken with it contain a fair bit of said noise. The first tweak then was to also add a tiny amount of noise to the sleigh, Santa, and Rudolph, to match the background shot. There are filters in Photoshop that allows you to add various types and amounts of noise but I wasn’t happy with the options in this case. I therefore made my own noise brushes. Of course I did.

I used the rendered-out alpha channel to isolate the 3D models from the background, so that when I painted the noise in, it didn’t bleed into the background photo.

The other tweak was to add some depth-of-field. I applied the rendered-out depth-of-field layer via the Lens Blur filter, which lets you choose a point in the image from which to create the depth effect. I only wanted a subtle amount but it makes a big difference to the final result.

And here are the before and after shots.

Back plate of desk

Back plate of desk with 3D models

Thanks for reading. My hope, in getting all of this down, is that it might inspire some of you to have a go at creating a 3D model/scene (it doesn’t have to be Lego!)… or you might want to build the 3D model I’ve created with real Lego. Maybe you’ll try even some compositing too. If you get stuck with any of the stages, please feel free to ping me and I’ll see what I can do to help.

I’ve listed some free tools, with links, below:

Lego Digital Designer (virtual Lego builder)

LeoCAD (virtual Lego builder)

Blender (3D modelling and animation)

GIMP (Photo editor)

I can’t wait to see what you create!

There are no comments yet, add one below.

Leave a Comment

Your email address will not be published. Required fields are marked *