Campbell Barton ported the OpenStreetMap import script to 2.6 for us !
And it’s now in trunk.
The script loads XML files saved from the OpenStreetMap website (http://www.openstreetmap.org) into Blender (as edges).
This was quite helpful in blocking out the Oude Kerk area for mango (to correctly place the church and the buildings around)
Now, we’re integrating these maps with more detailed infos (necessary for the final models but also for animatic / previz purpose)
The the finer measurements will come from survey or more accurate plans : city planning maps can be very useful in these situations (especially roads height measures)
We haven’t got those yet but we might be able to get all needed data from tracking (Sebastian is testing that on the ground surfaces just now)
Here’s a small selection of the thousands reference photos shot during the last weekends.
Boats, bridges, canals and the Oude Kerk, of course. but also many refs from the architecture and design of the Amsterdamse School (1910-1930~)
Especially interesting are the street furniture pieces (like the electrics box and the street-lamp in these pictures ) partly used directly as typical dutch environment props , but also as a base to build sci-fi and tech pieces (some of those shapes and geometries seems made just for that !)
The actual work on Mango production started this week, so everyone started various parallel tests, experiments and actual assets for the movie, here are a few:
Quick test for the dome structure :
A technical test, using 4k footage from real Amsterdam, tracked, integrated with some cg elements, all rendered in Cycles.
Of course being a test, we focused on some aspects and moved quickly on to others, so the modeling is a real simple kit-bashing, but still, kits are incredibly useful and a lot can be done with a small number of beam/girder/truss modules.
These use materials similar to the greeble objects in an earlier post, but even simpler: no AO bake, just an image with various B/W gradients, then each piece is UV mapped on one of those to set rusty/shiny parts, then tileable textures using a cube map projection.
With the production start of project Mango getting close it’s a good idea to test your own workflow a bit … because when instead you’re swamped with tons of work you can’t spend time thinking how to make things smarter and faster. So I tried to put together some questions and topics that always bothered me when I do environment models and shaders. Nothing amazing or innovative, but hopefully good for speeding up work, here’s what I came up with:
You got to love a carefully painted custom texture map, with all those subtle (or strong) weathering effects placed in the right spots just for that object.
Only issue: painting textures takes a lot of time! :)
Speaking of environments, that’s a real issue: your environment is often made of tons of different pieces, all quite detailed as models but not that important by themselves to afford the time for accurate custom painting. In my experience, in arch.viz. you only can afford tileable textures and no custom painting, in games you have to custom paint, and in movies you ‘simply’ need the best quality and realism…
Still, in any case it could be handy to have some kind of automation to get some weathering effects (based on the shape of the object) without custom painting, and keeping the unwrap phase reasonably fast. ‘Automation’ for this stuff won’t help quality much, but speeds things up. So it’s good for minor objects or as a base for important ‘hero’ pieces.
That’s the idea behind the tests below, dealing with: batch-bake of AO/dirtmaps, unwrapping multiple objects together, node shaders (cycles in particular)