When I give a talk or lecture using my digital model of Rome, I am usually asked about the technicalities of how I made it. Time and differing levels of interest in the audience tend to preclude a really detailed answer, so here are some facts and figures. I think this is going to be quite a geeky post, and I am an ancient historian, not a computer specialist, so please bear with me.
A lot of my initial modelling work is done in SketchUp. This is the first piece of digital modelling software I taught myself to use, and it has many virtues (and several limitations). It’s free in its basic version and relatively easy to pick up. When you reach the limits of the built-in feature set there are thousands of plug-ins that expand its capacity enormously. My favourites include a dome-maker, a tool for extruding a shape along edges (more easily than SU’s own FollowMe tool for some uses), and Chuck Vali’s terrific set of instant roof and wall tools.
SketchUp has such a nice working environment that I am reluctant to abandon it for smarter modelling software. I teach it now to my Classics students at the University of Reading, where I have a module in digital reconstruction working on our local town of Silchester. I find students can pick it up relatively easily – as I did – and create some very nice models with it.
It does have limitations, though. It’s not 64-bit software and gets unstable when I’m working on large models. It can throw shadows but it has no render capability. It can’t really deal with organic shapes and all its curves are really groups of straight lines.
So when I have finished a building or an area of the city, or for some specialist tasks, I take it over as a .3ds export into Cinema 4D, which is an extremely powerful and versatile piece of software. People use it for making movies and all sorts of commercial projects. I taught myself to use it and really only scratch the surface of what it can do – I ought to use its modelling tools more, for instance – but it works well for me.
It can hold the entire model at once (though it’s slow to open and work on), and I can turn elements of it on and off in the viewer to try to lessen the load on the graphics card. It allows me to create multiple render instances of iterated items like columns or trees to reduce the memory demands of the model, and can apply various sorts of sophisticated treatment to the textures which give the model its colour. It has a nice 3D painting module called BodyPaint that I use with a graphics tablet to paint on the backdrop map of the city (the roads and all the farmland). Here’s the city without its buildings, in a C4D editor window:
The gaps are where large buildings, mostly on terraces, have intersected and cut the terrain
Early versions of the model relied on this ground texturing for suggesting vegetation, which left the model looking rather stark and bare. In reality Rome, like most European cities, is actually very green when seen from the air or from many vantage points on the ground; its stands of pine trees in particular are a hallmark of the city. So after some experimentation I bought suitable libraries of trees from XFrog and VBVisual and have put an appropriate mix of Mediterranean species into the model, using a handy plugin called PaintOnSurface which allows you to scatter render instances of an object or group of objects (in this case, trees) across a surface (in this case, the terrain), with adjustable parameters of variation for rotation, scale, selection, and so on, which stop the trees from looking too uniform. I can also use it to plant rows of vines and olives. I particularly like adding the large stone pines which are so much a feature of the city today. The vital feature of this plugin is its ability automatically to adjust trees down to the local height of the terrain; doing this by hand for the c.50-60,000 trees in the model would take too long and be far too boring. After discussion with an expert PhD student in our department I have started adding quincunx planting formations of crop trees and at some point will try to add some commercial flower fields too, as we know ancient Rome had some of these close to the city.
Trees and agricultural planting amid the tombs on the Via Latina. The density of tree cover in the finished model is higher than this.
These trees add a lot of visual realism to the model, but come at a price: even professionally made low-polygon trees deployed as render instances will, when used in sufficient numbers, eat up a lot of computing power and take a very long time to render, since each has thousands of leaves and branches which all reflect light and cast shadows.
The current instantiation of the Rome model is 3.96Gb and it causes my computer to run very slowly when it is open. I’ve always aimed at making the model slightly overstretch my current hardware, on the grounds that Moore’s law and generous University funding would allow me to buy a new computer by the time I reached that point.
So far this has worked, though my current machine, a 2010 twelve core Mac Pro with 64Gb of RAM, cannot now render the model. I think the trees are responsible and that the bottleneck is insufficient RAM; I have ordered an upgrade to 96Gb (thanks, Reading’s Digitally Ready project). The graphics card also struggles to refresh the screen when modelling anything with a high polygon count, so I am eyeing up the new Mac Pro’s twin cards with some excitement.
Backup became a problem as the model grew. I use ChronoSync to keep my various machines in sync with each other but my MacBookAir hard drive is now far too small to hold the model data I need, which meant buying an external hard drive. For a while this was my only backup, and it rode around with me on my bicycle between home and office. The University’s IT people didn’t like this, so they kindly set me up with a nice large secure local backup accessible over our University ethernet. I also have a 2Tb Time Machine drive, a 2Tb portable hard disk, some DropBox storage, and a backup backup hard drive at home. I tend to try not to have more than one or two of these data stores in the same place at the same time.
Render times for the model now extend into several days for a flyin animation of the city (of around 300 frames at 24ish frames a second), which makes it annoying when one discovers a mistake at the end of the render. I have on occasion used commercial cloud rendering, from Rebus, to help meet BBC deadlines for some work they commissioned from me, and this worked well. But over the medium to long term I’d rather spend the money on a fast computer that can sit in my office and be used for other tasks too.
When OS X Mavericks and the new Mac Pro comes out I will upgrade to a model with 128Gb of RAM, using the imminent Cinema 4D Release 15’s ‘team rendering’ feature to add my existing machine (and a new 27″ iMac that our department owns) into a little rendering network. By then the model should be largely complete and unlikely to grow much in size – at least in this version – so I hope this will take care of the rendering needs of my book and e-publications based on this modelling project.
So, to summarise:
Software:
SketchUp, with various plugins
Cinema 4D, with RebusFarm and PaintonSurface plugins
XFrog and VBVisual vegetation libraries
Hardware:
Various Macs, chiefly a 2010 12-core Mac Pro, 64Gb of memory, with a 30″ Cinema Display, 3-button mouse, 3D mouse, and Wacom graphics tablet.
SaveSave
SaveSave
Great work, Matthew! Very impressive.