Dev-Log V

HOW WE OPTIMIZE FORESTS IN UNSPOKIN

For an Artist, the end of an production seems very similar each time. It is all about optimization. When we pitched our game idea it was always set in a lush environment with dense forests and a vibrant and alive landscape.

Screenshot 11 - Paintover
By Katherine Elliott

It was one of the goals we were determined to achieve as a student project. Achieving a certain atmosphere and mood is quite a type of design I was used to in game development as most of the projects I have done involved some sort of realism to it. But this time it was all about art style, composition and framing.

Most of our promotional art done by our Art Director had a thick forest surrounding the scene. Through dense woods and natural environments seem to be the bane of game art optimization due to the amount of trees, bushes, grass and ground cover needed to achieve that. The Witcher 3 did that splendidly but did run into some frame rate issues (http://www.pcgamer.com/the-witcher-3-performance-tips-and-crash-advice/) when it was released.

1402005463-the-witcher-3-wild-hunt-1
The Witcher 3

However CD Projekt Red did a superb job in optimizing it. I was researching in how they did it and if there were any tips I could learn. The sad truth was that is lies all within their proprietary engine and having the engineers a phone call away if something needed to tweaked.

I had to look deeply into how I could make Unity run with thick forests and vistas. However I managed to run into three problems that I was the architect of. These were:

  1. Thinking automatic tools will get you all the way
  2. Not adhering to the theme
  3. Not understanding population rules for games

 

1: The SpeedTree curse

I had convinced my group early on in production that SpeedTree was the way to go in creating these immense forests. On paper it really is The industry standard across the board from Games to Film and TV. Their Games credit list includes titles like The Witcher 3, Middle Earth: Shadow of Mordor and Destiny (http://speedtree.22slides.com/games). The problem we encountered seem to be very Unity specific. After many hours researching the Unity forums it seemed that several had the same problems with SpeedTree in Unity and batching. When we ran the Frame Debugger in the scene we saw that it draws every LOD level at the same time and every LOD level has submeshes that needs to drawn. So one tree could end up creating 8-10 draw calls. Times that with the amount of trees we had in the scene did not equal a good frame rate. And the obvious choice, in consideration of the schedule, was to recreate the trees in Maya. Luckily we could use the SpeedTree model as a base.

speedtreeMaya.PNG
Left: SpeedTree, Right: Maya

The trunks would now batch together which was a real reduction in draw calls. But the canopies was not batching. With help from Andrew Carvalho and Stefano from Scend we saw that it was the shader itself that was not letting the trees batch. However the SpeedTree shader in Unity is made for making leaves look good and it really does a good job at that. So we were torn between frame rate or looks.

 

2: Population for the theme

The theme of our game is a dying world. Trees are being cut down and nature itself is slowly regressing and perishing. I had been populating trees to make it the world idyllic and magical.

Deadworld.PNG
Too lush and idyllic

After a critique session at Ubisoft, Douglas Gregory told us that there is a disconnect  with the world. There are no tree stubs or fallen trees in the world. It does not come across as a dying land.

dead.PNG
Slightly more dead

And I wholeheartedly believe that a world and landscape that adheres to a mood and atmosphere is stronger than a magical and fairy tale setting without any grounding. This bring s me to problem number three.

 

3: Trees and how the grow.

Growing up in a land full of trees and mountains I feel I am very familiar with how a forest behaves. But as in many parts of game development, the real world might not work as a piece of entertainment. I wanted the audience to look at the forest and say that looks like a real one. But the sad truth was that 95% of them won’t notice. Luckily Armand from Scend stumbled upon an article over at 80.lv (https://80.lv/articles/tips-on-creating-a-perfect-forest/) regarding forest population rules in games. And two big things I could take away from that was that not every tree need a canopy and the importance of dead and fallen trees and stumps. Implementing these rules helped a lot where we could elude the idea of a thick and large forest with trunks that did not have any leaves on them. On top of that we added dead and fallen trees to give it a static life. Since we cannot take every population rules from real life and implement them we take the important ones. It is enough to reference them once or twice and it gives the sense of a forest.

trunks
Blue highlights are trunks without leaves

What now?

An example of the effects after these problems were fixed was that we increased our frames from 22-25 frames in a dense area to 55-60 frames. Most of these fixes are not very technical and as what goes under the hood is often a different ballpark for an artist. That is not to say that an artist should have a general knowledge in how a game renders its visuals.

The landscape also adheres a lot more to the mood and atmosphere which is what we want in the end.

Dev-Log IV

MOTION CAPTURE AND THE CLEAN UP INVOLVED

An overview over how we used motion capture for Unspokin

The preparation

As in all areas of games or entertainment production, planning is always key. In August the team went to Screen Industries Research and Training Centre (SIRT) to test their motion capture system. Although we had an idea of what we were going to shoot we had not blocked out anything. Luckily Spencer over at SIRT is very experienced with mocap and had a lot of great input which taught us a lot.

img_20170121_152927

 

We drafted our long list of takes that were going to be needed. Our adviser Max had some good input from what he had experienced with mocap. One thing was to have more takes planned than there were time for. Basically shoot everything you can think off after the core takes are done.

So before this session we decided to block out every animation that we would need for our game. We were very lucky to have Allison Elliott with us whom is an actress. She came to the studio and we went through the takes. Being an actress she had a lot of good ideas regarding how the character would actually behave, compared to what we had imagined.

The process

SIRT are currently running an OptiTrack system. The results are amazingly clean which makes the process after really easy.

CzuuWBaVIAA3n1_.jpg

A typical shoot consist usually of the talent, a director, and the technician(s). Some shoots which involves cutscenes and large amount of acting can also have a sound team and a camera team. Some mocap is taking place on sound stages so they can use the sound as well. And others have virtual cameras so the director can direct with a live camera feedback in the engine or in the animation. SIRT can do both which is such a huge resource for Sheridan.

ellen-mocap.jpg

Some of the takes involved us using props. There is one take where the character needed to push something over. So we actually put a box for the character to push over, while Katherine added the needed resistance to it. It turned out really well. We did the same with leading Killian. Katherine would hold a rope up high and have Allison drag Katherine. Katherine would also add the desired resistance, and it really looked like the character was dragging something heavy. We also used boxes and platforms for doing jumps, climbing and cinematics. I can only imagine what we could do if we were to build some sets. The possibilities are limitless.  

The cleanup

When we were done with the shoot we packed up and the thanked the actress for helping us. It was then time to look through the takes we had. One of the more time consuming tasks is to look through the takes and find which one is the best one to take through the clean up process. For most shots we had more than three takes. The interesting part is that you think that the last take is the best one, but when I was looking through them all I often ended up selecting one that was among the first takes. I now see the importance of shooting them several times, because each time you find qualities in each take that is unique.

After the I have selected the takes to use, I start the cleanup process inside of Motive which is OptiTrack proprietary software. At this point we are just working with the tracking points. No skeleton has been built yet. Since the stage is so well calibrated and the ran by experienced technicians the results usually doesn’t require a lot of clean up. Usually the algorithms within Motive is good enough to clean up 99% of the takes. The remaining 1% is mostly me assigning the right labels and smoothing out any artifacts. At this point one can put on some mellow tunes and just keep at it.

After this stage it is onto Motionbuilder where I start working with the rig. I make sure that all the takes are facing the right way. That looping takes loops correctly. Motionbuilder has so many tools already for doing that process as painless as possible. After they are cut up and prepared I can attach them onto Cairenn’s rig and export them to unity where it will be integrated with the controller.

Many traditional animators think that mocap is cheating. But it is important to remember that there is a lot of animation knowledge needed to do a proper cleanup process, not to mention the need for rigging knowledge as well. I think it settles somewhere in the middle between traditional keyframe and a make-nice button. They can greatly benefit from each other.  

Sheridan Insider’s Article

Dev-Log III

LEVEL PACING AND STRUCTURE

How breaking down a level into minute-to-minute gameplay helped create a solid blueprint for the level design

 

The pacing

There are many principles that were important for me to address with the current state of the level design. Pacing, flow, beats, narrative, composition. I found myself being cast into Unity and started to sculpt terrain creating areas of interest. Quickly I was torn between world design and level design.

I had a great vision of what the player should feel and be exposed to, but I did not encounter for any gameplay yet. We did not have any of the mechanics ready to use yet so it was all on the whiteboard. The design back then had puzzles as main areas where the fun would be. I quickly realized that there is nothing else than walking between these puzzles. I was trying to justify it by adding environmental storytelling and make the walking interesting that way. However I was now blending personal opinion with my professional and I was holding onto something mainly due to a vision I had in my mind. I had forgotten to adhere to the common player who do not necessarily share my own taste. Fil, our programmer told me that my responsibility was to make sure “the trust meter went up and down constantly”.

13-loading

That was our gameplay. These words shed new light on how I should approach this. Puzzles weren’t the main areas where the fun would reside, it was the walking between them. I later found an article from Filip Coulianos at Gamasutra where he compared X-Men Origins: Wolverine and Batman: Arkham Asylum and justifying why the latter were a better game than the former by solely looking at the pacing of each game.

He had broken it down to four categories:

Roaming – Level traversal with some challenges that does not necessarily halters gameplay (the challenge isn’t too hard, no need to stop to think about how to solve this) and that the player is progressing along the path towards an objective for an example.

Challenge – Very similar to roaming, however it may require the player to stop, or try to find a pattern, solve a small mystery, avoidance etc.

Puzzle – Highest form of challenge

Cinematic – Cutscenes.

Filip Coulianos plotted the game’s pacing into blocks of 1 minute worth of gameplay to illustrate how the game was laid out. When I was plotting my old level design into a similar graph I found that I had a lot of the roaming between points and puzzles were not spaced out evenly. Instead of heading straight into greyboxing I started to plot the entire level out as a script, while keeping in mind to adjust the problems I had with the previous design. At the end I had a full overview of what will happen in our level, down to the minute. Which is a superb blueprint to make sure that pacing and flow is at the level you want.

imag0157imag0156imag0155imag0154

From here on it was easier to start to greybox, as I knew I had a plan to what need to happen where. I knew that the player can walk x amount of meters for 30 seconds, and I could technically divide my level up into 30 second pieces.

I had previously greyboxed the first puzzle in this level for a sprint week earlier this semester. But I quickly realized how much that area did not fit with the other greyboxed areas. This was mainly due to the flow of the areas that were made under the new pacing diagram. These areas had much more breathing room. Luckily it was only one puzzle that had been made using the old way. I quickly adapted that area along with the others and it felt a lot better.

oldtreeslamnewtreeslam

One of the new dangers we created were the Soundblast. It is a blast wave of sound that erupts after a given time. And the player must avoid being caught in the blast radius.

This mechanic can easily be combined with other mechanics to ramp up the challenge. I was heavily inspired by Insides work on timing, and that was something I wanted to recreate. In the Soundblast puzzle I wanted the player to feel that they are barely making to each cover. I started out by having the covers close together so you can make it with seconds to spare. However further up the road I increased the distance between each cover gradually so the player feels they are barely making it. But I made sure the have the next cover in front of them and the trigger box being a bit longer. With the camera angle it makes it look they are getting behind cover moments before the blast wave it. But the truth is that you could actually be 1 meter away from the cover in the Z direction and still be safe.

blast

But the Soundblast happens so fast that the player might not be bothered to stay behind to test it. Also the distance offset from the cover is minimal so it should break immersion.   

Dev-Log II

ART DIORAMA “BEHIND THE SCENES”

PHOTOGRAMMETRY

 

 

For our prototype, the art team decided to do an art diorama as a proof of concept that the art style developed by the Art Director would actually work. As the Lead Environment Artist, the diorama was a perfect opportunity for me to test out photogrammetry. As mentioned previously, the game world would rely heavily on lush and rich natural environments. It is one thing to heavily populate a scene, but if it does not follow an ecosystem, it is hard to make it believable.

 

Preparation

 

It is important prepare for a shoot. We decided that each asset had to be tileable, and could be reused throughout the level. This meant that we would not shoot any one-offs (fallen tree broken in a pattern, rocks with attachments) which would require to placed in a certain manner. It is important to give the artist that freedom. Another important aspect we did was to look at references from Ireland, and broke down the nature to what it is.

Examples are, moss covered rocks, tight tree growth, moss covered trunks, lots of ground cover. When we do a breakdown likes this, it adds to time saved when we are at location, and know exactly what we need to shoot.

 

The shoot

 

At the shoot we were able to work efficiently due to the preparation work. However, the nature/parks in this immediate area did not offer a lot of usable assets. First of all, many of the parks are influenced by the close by lake, so the growth of the trees differs from trees higher up in land.

Also the climate in the GTA is drier than Ireland, which affects the ecosystem. This is why it is important to also research the location you are going to make sure that it has the assets you need. Time is expensive.

 

The cleanup

 

Once I had returned to the studio, I started to process the raw footage. It is important to properly name and structure your data, as the raw footage load is huge. I tried to use a color checker to make sure I had accurate colors, but it did not yield the desired result, due to not using an official color checker chart.

I used Agisoft Photoscan to process the footage. You start off with feeding the sequence of pictures from a specific asset.

agiRock.JPG

Photoscan then calculates the information within each picture (color, depth) and compares them to the others to create a point cloud that represents the asset digitally.

agilowpcagihighpcagihighpc_cu

 

From this point cloud I can generate a mesh and the texture from the footage.

agimeshagitexture

One major important thing is the 70% overlap rule. Each picture overlaps the previous one, making sure you do not loose any detail and every possible angle is covered. For 75% of my assets, the overlap was less than 70% and the result were several holes in the mesh, or most of the mesh missing completely.

endlap

Then I export the mesh and texture to Maya.

 

In Maya I have now a pretty high-poly mesh that is not ready for any game engine (Not even Frostbite). The topology of the mesh is all decimated, so do a quick retopology within Maya. I bring this retopologized low-poly mesh into Zbrush, where I project the detail of the hgh-poly scan onto the low-poly. The low-poly is still not low-poly enough for a game engine, but it at least has a usable topology. I then run a Zremesher on that mesh, with “protected” areas where I want to save the detail. This low-poly mesh is now game ready (2000K for final trunk with branches). Back in Maya, I extend the trunk the desired length.  

 

The texturing can also be tricky, because you have to project the texture from the high-poly mesh onto the freshly unwrapped low-poly. The texture you get from Photoscan looks like a blown up grenade, so it is not usable, nor efficient at all. I use Xnormal to project the diffuse, and generate normal, object normal and AO. Since the high-poly mesh is not extended like the low-poly, some areas on the low-poly mesh will be left black. I fixed this by moving the low-poly down in the scene, and reproject, and then stitch that texture together in Photoshop.

 

Speaking of Photoshop. Now as I have my maps, I can start to work on the albedo. The texture that comes from Photoscan is a diffuse map containing shadow information. Since Unity is using a PBR workflow, the hard directional shadows, and most of the soft ambient shadows has to be removed. Utilizing a brilliant technique from DICE and their work on Battlefront, I apply a black and white filter in Photoshop on the object normal map, and add that as a soft light over the diffuse, and it removes the hard shadowing. It requires some manual tweaking depending on the complexity of the mesh, so additional maps like thickness, and curvature can help to remove these shadows as well.

Swipe.gif

 

Final result

 

Comparing the trunks created in SpeedTree natively and the ones I scanned are pretty clear. There are certain details within nature that are really hard to recreate. You often do not realize that these very details exist before you see them in in nature. From the trees and rocks, once can also export tileable textures that can be added to a library for later use. Rocks also have a complexity that only an experienced eye, used to nature can really capture. Like what Megascans do, you can export your asset with the ground, which can give you “free” detail, and it makes the asset seem more grounded. Overall a great and interesting technology.        

Dev-Log I

5horsemen_logo_black

The 5 Horsemen is open for business!

Me and the rest of my comrades in the stable have set out to create a beautiful and rich game as our final project as an end of four amazing years at Sheridan. We are aiming to create a game that will capture the player with fantastic visuals, dazzling audio and exquisite camera and controls. My role is the CG Lead, namely the chieftain of everything that is 3D. I also have the pleasure to be the level designer in a team surrounded by amazing talent.

 

Our little game

You are Cairenn. Equipped with your ancient horn, you and your bear companion Killian you are on a quest to find your lost father.

poster.png

Our game is a vertical slice of an adventurous puzzle game where you will experience a collaborative relationship between you and your AI companion. The puzzles would require you to work together and they would feature unique attributes that would either only fit with your bear or the player. We are also making sure that the player is never taken out of the flow due to very heavy cognitive puzzles. Another aspect of our game was the sense of adventure. Many games tag themselves as adventure games but often lack the feeling of journey through the world. We would make sure to to create an experience that would be rock solid and bullet proof, invoke emotions and feelings with the player, a sense of awe even if the experience stopped half way.

 

The puzzles

screenshot-3

Brothers: A tale of two sons is a great inspiration for us. It features several straightforward puzzles that never takes the player out flow. They are intuitive for the player but still enjoyable to solve. The puzzles could eventually be a bit similar to each other and slow so we would like to break the levels up to minor puzzles and major puzzles.

TutorialLevelBeatmap.png

The reason for this is that the player would have moments of challenge and mastery and it would not be a linear experience where you go from A to B. The major puzzles could be a boss battle, a major system to solve or a series of riddles that lead you to an important item in the game. If the major puzzle is placed at the end of the level, the preceding challenges could act as a build up. Or if the major puzzle is in the middle, the end could serve as a moment of reflection and admiration of your skills, which would build up under the sense of adventure.

 

The World of Turra

The game takes place on the island world of Turra. It is greatly inspired by Ireland and Scotland due to our hymn to the Celtic culture. The nature in Ireland features such lush and rich forests, fields and flora.

To recreate this in the game is very important to us as the landscape itself invokes a certain set of emotions. We must understand what in the landscape invokes this. Looking at the ecology (placement) of every piece in an Irish forest we can break it down to see what items are definitely needed in the game. Many of these elements are often very challenging to recreate in 3D. Don’t get me wrong, it is absolutely possible for a very skilled 3D artist. But one must know the behavior of nature to capture it correctly. A character artist must know anatomy to accurately recreate a human, an environment artist must know why birches bend and grow shorter on a windswept mountain. This is why I have pioneered the use of photogrammetry to capture this.

botetourt1.jpg

Photogrammetry is the is the technique where you take pictures from several angles of an asset, run it through a software that can create a point cloud. This point cloud will then be used to generate an actual 3D asset. This program also give you a texture. The fantastic thing about this is that the texture fits the “anatomy” of the rock, and we get the correct behavior of the rock. Applying this technique to rocks, trees, foliage and ground cover, we will be able to recreate the personality that is Irish nature.

 

Turra

moodboard_level01

Turra is a world combined of several smaller islands. The main part of the gameplay takes part on the main island, whom is the biggest. Since these islands are suspended in the air, access to each island will be done by suspension bridges. It features a solitary mountain in the middle. This acts as a great landmark for the player in order to get their bearing. The story takes the player up into the mountains eventually. From the start the player always know where they are going and can see the mountain getting closer and closer. But when they are getting higher up the mountain they can eventually see where they came from, and their adventure so far in retrospect. They can see the suspension bridge that brought them onto the main island, previous major puzzles, and eventually the more rocky terrain that brought them into the mountain. This is an important factor in order to invoke that feeling of adventure, and we hope that player will have a sort of “wow” moment realizing that they have traveled a great distance in our imaginary world.