To ensure that the final scene matches up with the composition of the concept, I’ve used it as a background image for the camera and started playing around with the height, perspective and rotation of the camera in relation to a flat plane. Once the horizon lined up, I could start extruding the terrain and placing basic shapes. Of course, when working in just screen-space, everything is placed weirdly in the 3D space, so getting things to look right and having correct scales in 3D requires some back and forth between camera and perspective view, moving things around, resizing, checking back with the concept and so on.

What was really handy here was the walk navigation option in Blender. At any time, I could just hit Shift+F and start flying through the scene with the common first person controls found in games. Gravity for walking can be activated with TAB, and since I had the view height set to 1,7m in the user preferences, I could also easily preview if things were too small, big, high or low when seeing through the player’s eyes.

Once the blockout was done, I exported everything as one big .fbx file and imported it into UE4. (A big thanks to the Blender’s .fbx exporter’s presets, the scale and the axis were all lining up with the default settings! Yay!)

What I would’ve done differently, now that I know it:

Based on my experience with this project I would recommend starting replacing the blockout meshes by correctly categorized and named assets as soon as possible. I’ve made the mistake to jump straight into each asset and detailing it, moving to the next one and so on, which resulted in the scene filling out quite slowly and having to go back to redo the detailing quite some times, because it turned out later that the assets weren’t playing well together visually.

To avoid this, I would recommend doing the blockout as usual, importing it, testing some lighting and maybe some effects, but immediately after that start preparing the asset folder structure, splitting the blockout into the major assets with correct filenames, and importing them correctly into the game engine as soon as possible. This way, the organizational part is taken care of at the beginning when things are simpler to keep track of, before becoming overwhelming. This improves motivation during production due to less confusion on how assets should be named, where they should be put and how many variations you’ll need, and it also reduces overall visual noise in the scene.

The rest then was quite straightforward. For most of the assets, I would take the low poly and either use that as a base to sculpt high polys in ZBrush or make the high polys with standard Box-Sub-D modeling in Blender. Then retopoing them in Blender or ZBrush, or just refining the box modeled low poly’s, creating a cage mesh and exporting them for Substance Painter. I usually try to bake exclusively in Painter for the convenience.

A word on file management:

I think I found a good workflow for file management when working with the Unreal Engine now. Basically, it turned out to give me the least hassle to have one source file folder that holds a systemized naming and ordering convention, with all the source files, including ZBrush and Substance files, and then have the same structure inside the UE4 content folder, but with just the final low poly’s and textures. This ensures that work in progress and source files that are not needed for the final assets won’t interfere with UE4, which can be really annoying.