Date: 12/1/16
Today we were taught that when modelling games, particularly mobile games, it is better to create assets that are modular and assemble them in the game engine of choice. There seem to be a few reasons why game artists and developers model in a modular method. Firstly, it saves on time. The ability to duplicate assets like walls, ceilings etc makes it incredibly quick to assemble a basic environment. The second, and arguably more important reason for modelling in modules is that game engines, like unity, render the field of view in packages of assets, called batches. Only the batches that are directly in front of the main camera (in a first-person game anyway) are rendered, saving on performance. The bigger the batch, the more costly it is, as there are aspects of the room being rendered that are not directly visible by the camera. So modelling in a modular manner is just better general practice for a games artist.
Simon then presented a couple of games that he worked on, and showed us examples of when it is possible to model using modules, and when it is not. Seeing the finished product in Maya was really cool, as we got a glimpse of what our projects will hopefully look like at the end of this project. We were then given a couple of modular assets, and were given the task of assembling them in whatever way we saw fit.
We briefly touched on UV mapping, but that will be primarily covered on a later date.
Simon then showed us the basic corridor that he has modelled running in Unity. We will be given this scene on a later date, but it was introduced to us today to give us a sense of scale, and to understand the mechanics of the game engine before we start modelling for it.
After class I then went on to work on my own project. It was suggested after my presentation that I create a sort of shopping list of assets that I will need to model, so I did that, creating a (long) list of assets that I will need to model for my 1970s hotel room, corridor and exterior. I then, in sketch form, started to roughly block out the proportions of my room. I created a rough floor plan, and then went into Maya to roughly block out where the main assets of the room will be placed. This technique of blocking out the rough forms in Maya is incredibly useful, as you get a sense for what the room will actually look like. I ended up tweaking the proportions of the room a fair bit.
Finally, I looked at a video on the GDC Vault entitled “Horizon & Beyond: A Look into Tomb Raider’s Tools”. This video was incredibly interesting, and was particularly relevant to the stage that I am currently at in the course. The speaker, Jason Yao, discussed how the scenes for the Tomb Raider reboot were modelled in maya, and all follow a modular workflow (very like the one we explored today!). They assemble their assets and modules in an engine developed in house called Horizon, but the functions and tools are incredibly similar to those of Unity, albeit more advanced and specialised for their workflow.
Summary:
Today was a really interesting day, as we saw for the first time a game running in Unity engine. We discussed modular modelling, and how modular elements can be assembled quickly to increase an artists working speed, but it is also much easier for the engine as it doesn’t have to render the entire scene at once, just the modules that are visible at that time.
I also watched a talk by Jason Yao of Crystal Dynamics on the GDC vault that was relevant to what we learned in class. He discussed the process for modelling and assembling modular elements in their engine Horizon, which mimicked the work we did in class today.
George O'Keeffe | Game Artist 