So this is the story all about how our project got flip turned upside down so I’d like to take a minute just sit right there and I’ll tell you what became of the town Belisaere.
My own feelings on the way this project played out are a bit dismaying, not because I think the group worked poorly overall, but because it was one of the suggestions I put forward and in hindsight (I honestly realised by week 3) we were never going to be able to do justice within the time-frame. This is not to say the team didn’t work admirably, it’s just a matter if scope. Scope of producible assets led to an overall repetitive feel to what the final scene, clear skill gaps and associated program knowledge between members caused issues in workflow speeds and tasks might have been divided differently to achieve more in the timeframe. Additionally there were general misinterpretations of sections of the brief and ways of overcoming steps early in production which led to some fairly bottlenecks further down the track.
THE GOOD, THE BAD, THE CRITICAL REFLECTION
Starting from the beginning there were issues relating to pre-production work. The book in question, ‘Sabriel’ had only been read by myself previously and as such the understanding of the rest of the group was coming from the 3 short chapters I’d set aside as being the best describers of the environment. Going on record as being almost entirely my fault this was in hindsight not a great piece of source material to work from. Much of the greater description of the town comes from the broken pieces across the series as a whole, and I found my own initial interpretation to be skewed from what was being described, to the point where we had to revise our entire initial interpretation from French to Mediterranean architectural inspirations. While none of this was world ending by any means it did definitely slow pre-production right down, leaving us initially without clear views for an art bible, compounded by the fact that colour concepts were produced by only 3 of the members, the other two opting for a more placeholder 3D approach which ultimately also became what we had assumed to be the requirement for a pre-vis at the time. These were not intended as shortcuts, the work done at this stage by Ed and Heaven in particular was far and away the most impressive. My own concept image was unfinished, though from how things eventuated probably because the basis for a good deal of the composition in the final product.
What all this did amount to however was a fairly weak pitch, and the pre-vis was rendered as a 3DS Max file. Strictly speaking all of this was the plan at that time, under the assumptions that we made regard the FBX import functions available in Unreal 4.12, we believed it possible that our entire scene could be adequately set up in max and then transferred to Unreal for rendering. Here we made a couple of crucial mistakes, which could have been solved with with better prior research. Fore-mostly the exported scene doesn’t acknowledge instancing or referencing, instead treating each model in the scene as it’s own entity. For reasons of general file size this is already an issue, as well as making any changes in engine fairly long winded given the objects dwell in a sub-file existing separate to the entity list for the scene. In addition we could have avoided a good deal of pain even in using this method if materials had been created and imported from max with the FBX, as in the end Ed spent a good deal of time going through and selecting each instance of the specific models to apply textures to that otherwise could have been handled in a single application. In truth though the lesson to be learned is create your pre-vis in unreal if your intent is to make that the end of your pipeline, so as models can just be swapped out at a later time, and each genuinely remains an instance, greatly cutting down on system resources and file size, as well as just keeping your digital work-space neat and easy to read.
Asset production itself suffered a bit simply on workload divide, and as previously mentioned, some misconceptions of prior knowledge and working speeds of members. In certain respects it wasn’t a bad thing that people tried to tackle new ground here, it was clear Duncan picked up a lot from the exercise which really is the intention of such assignments. Things took longer than expected, however, especially on my end. I made the mistake of treating two detailed character models as a trivial matter, and the results of the guard character in particular were less than stellar (though I was happy to note how much faster my Zbrush workflow has gotten). In the end this meant shots were vague come the pre-screening in week 6, and as a result the feedback we received was limited, as there wasn’t really much on which to comment. I like blaming myself in these circumstances (probably some acute narcissism there), though I was likely putting as much time into the activity as anyone else involved. It likely needed more overall, and better communication and cohesion (I was fully guilty there) on a regular basis to get things done. But mostly just time. I in particular still struggle to manage tasks as they mount up, had my focus on the pitch for final project that week. It doesn’t excuse me being lax, I just know it was a factor in my own poor time management. I have real trouble actually sticking to a schedule outside of class, and it’s something I need desperately to sort out. I’ve recently found through final project that I can remain more focused as long as I’m verbally in a meeting (skype) with the group I’m working with, so that may be one solution for the future.
We did eventually get a result we could be fairly proud of, in accordance with what we set out to do from our concepts that showed off talents from all members strongly in the framing of the shots, so I’d qualify that as a success. As gloomy as all that sounded as well everyone did work hard, communicate excellently and complete every task they were set to the best they could offer within the scope of time. Overall this was a pretty excellent group to work with.
TOOLS AND PROCESS
Given the relatively wide difference background of skills and practices of the members and the fact we were all working on the same overall scene for this project we stuck to a fairly straightforward low-poly with high-poly sub-division for the purpose of normal-map baking in max, taken to Quixel Suite 2 for texturing, then imported to Unreal Engine 4 to compose the scene, lighting, particles, shaders and cameras for the final render. In addition to this I used ZBrush into 3DCoat prior to the standard workflow to create the character models.
I’ll talk specifically on my own workflow in a moment, and first address the overall way the team was coordinated in the task. From the first day we had in place a quality control rule, relating to the parameters listed in the art bible an associated paperwork, in addition to an agreement to revise all assets produced each week as a group in the Wednesday class. Overall this fostered a very consistent style to the assets produced, in addition to providing an excellent chance to share knowledge on different modelling techniques and workflow elements people hadn’t previous tackled. There is always the potential that this could have backfired and limited the work being produced, but overall I’d say that the team found their stride, and outside of a few small instances where another member spent some time tweaking or cleaning up a couple of small geometry and unwrapping mistakes the whole pipeline was handled by the person producing the model until it came time to bring it into unreal.
If there was anything majorly lacking to the workflow it’s that there was an inconsistent amount of objects which received any kind of normal bake. This was an experience thing, and left too late in production to do anything about, despite being integral to a efficient reduced polygon workflow. This could be avoided in future by handling workflow study in the preliminary stages of the project.
This more just pertains to myself, though Duncan did make a concerted effort to learn a new tool in ZBrush during the thick of the process, for which he should be commended. My primary role for the project until it came to compositing was primarily character models to go into the scene for the guards of the city and the undead infesting it. (and the background buildings)
I’ve used ZBrush at various points across studio projects in the past so this was building on a present skillset instead of developing a new one. I got three major things from the practice. The first is just a general efficiency increase, sculpting to rigged completion two character models in less time than it had previously taken me to do a single, and to the same if not better standard. Secondly, and somewhat related to the workflow issue I brought up with the max modelling workflow, is getting the correct divisions of the model, by dividing off different parts of the model (arms, legs, helmet, face, body) and having efficient unwraps, in order to get a good normal bake. With the exception of a couple of small errors around the hands, which can be easily fixed by a slight adjustment to the cage.
The third and most important point was learning alternative forms of retopology available. The guards were retopologised using the standard method I’ve used in the past, moving through a draw-quads workflow in 3DCoat to get an efficient simplification of the mesh, as I’ve shown before in the Sabriel and Metum projects. The alternative I tried when retopologising the undead model. Using the zremesher tool in ZBrush to quickly decimate the mesh for use in a real time scene, as I covered in my research post last trimester. Though I’ve done this before it was the first time it’s been for a model that had to be able to move. What I found upon trial was that if there’s clear edge loop flow then the results would be pretty much spot on to what you’d ordinarily want for a deforming character, with the exception of adding triangles to bends in limbs, but that’s then an easy fix in a program like Max. The issues arise when tackling something with a more complex joint, as exists for instance around the shoulder of the guard, which will create intersections on the joint, instead of a meeting of two-loops. Drawing on loops using the subsections of the tool will grant some semblance of what you could get manually. What I came to understand in the end though was that it can be a useful shortcut, definitely still in the case of statics as it will often to better than a lowpoly you could construct yourself, unless the object is insanely simple. If the model is to be rigged however unless you get the results you want within 5 minutes of trying it’s likely going to be faster just to go with the more standardised manual method.
Not a great deal to say here. Same Quixel workflow we’ve used on several projects now. We made sure we were using the same materials where they would crop up together in the scene. There were instances as there usually are on a project using the suite where more could have been done with the texture. Most of the group was still learning the suite on the go, so it’s likely just a matter practice and unfamiliarity, though time management did factor in on some level with texturing still being finished right up to the line.
There were also a few small instances where texture islands needed rotating that weren’t caught up until the compositing stage. Though again I feel its to do with experience with Quixel, as the workflow it and other specialised programs like substance require UV islands to be oriented correctly on the map to get the results you want.
I also made the dirt and floortile textures in substance, through a fairly simple stacking of the tiling presets available with the program. In future I’d like to explore substance as an alternative to Quixel, as it seems a very versatile and powerful tool, with more standalone options and greater direct integration options with the game engines I find myself frequently working with.
Oh, and 8k textures. NEVER. AGAIN.
Composition and Lighting
I had the pleasure of handling a lot of the latter stages in the Unreal 4 scene. Most of the actual arranging of the assets had already been done by Ed so this was mostly just the application of a few textures and some delicate tweaking to the light.
With the textures made in substance I set up a vertex-paint shader in the same fashion as I’d used before to do the blood and glowing green stuff in the gaslit lab scene, this time to paint dirt and grass into damaged sections of the road. I created a water shader using a couple of normalized wave-pattern noise maps to flow through the aqueducts and sit in the fountain, as well as a gravity-weighted water particle for the fountain to dispense. The lighting was a tad rushed, and really needed revisions after what the render revealed. The aim was to use a height fog and extended depth of field to create an ocean haze, given that the city sits upon a peninsula on an inland sea, and to an effect I managed to achieve that, but upon revisiting I realised it could have been more effective with a bit of toning down.
The fountain and aqueducts could also have benefited from a screen capture reflection to get some cooler tones happening around the spaces, and even just a blue point light in relation to the fountain. Previous experience I’ve had with lighting environments has been entirely interior, though, so it was a good lesson in blending light forms between exterior and interior spaces, particularly around the undead shot. The long and short of it is I need more practice, and didn’t really give Ed enough time to run his eyes over it before final render, as his own experiences lighting in the engine could only have improved it.
I also cobbled together some grass and low-poly buildings to fill background space and areas where the city was being taken back by nature, which I then applied using the object painter in Unreal 4. Due to scoping reasons which we put in place early we decided to keep the vegetation minimal, but after seeing what was done by the other teams were we to do the project from scratch I think we’d make much greater use of store assets or items from the demo levels in Unreal to fill out areas with more detail. Some additional moss texture painting and the like would stretch a long was as well.
It was a long process, with some speed bumps that could have been avoided with a bit more planning and a few more early considerations, but we got there in the end, and everyone learned something.