Unreal and Unity, different engines, different targets
During the semester we have done a great research aiming to achieve the best quality and realism in our terrain simulation. Our main targets when deciding the proper engine were TrueVision 3D, Unity 3D and Unreal Engine. Even though TrueVision seemed promising because its terrain modification capabilities, its weaker physics engine made us leave it.
While researching Unity and Unreal, both looked really good, and both have been used to ship dozens of commercial games. Unity makes it very easy to start building a new game, not needing a great previous knowledge of game engine programming. Unreal also provides visual tools that allow people without programming skills do a good part of the game work.
But we have decided to turn the balance towards Unreal, and this is because in our project we are seeking the best realism, and Unreal has some advantage here. When looking at games developed using both engines, there are many more AAA and renowned games made using Unreal. This list includes Unreal Tournament 3, Mortal Kombat vs DC Universe, and Mirror’s Edge among others. Most of the games made using Unity are indie or not as big as triple A, being some known Star Wars: The Quest for R2-D2 or Tiger Woods PGA Tour online. This does not mean that one engine is better than other, but each one has a different target in the market as for today.
Finishing the MTL
As we get closer to halves, I’ve been finishing up the Multi-Terrain Loader textures. To add to the level of realism, I baked out ambient occlusion maps and normal maps. An ambient occlusion map is a shadow map: it takes the lighting information from the scene and takes it down into 1 texture that can help deepen shadows. A normal map is an RGB image that fakes depth and smoothness on a model even if the model is not that high in polygon count. With current game technology, use of these two maps help to really sell a model’s realism.
For the sake of time, I handed over the texturing of the MTL to Sam, while I rig it for importing into the Unreal Development Kit. Rigging a model is setting up a skeleton that allows it to be animated and moved inside a game engine. I’ve also been providing Matt with prototype meshes for testing inside the engine.
Texturing
Since last week some things have been shifting in the team. With my research into Unity 3d complete, I have started to pick up some slack in different areas. I am currently in charge of texturing the MTL. The team was lucky enough to have a very well documented achieve of photos for reference. From those images I have been able to pull important details to add more depth to the MTL while still using a good bit of my hand painting skills.
Another task I have picked up this week is helping Matt with his demo in UDK. I’m doing this by supplying him with any assets that he might need so that he can focus on making a more realistic particle system. Some of the things I have been doing have been making different types of rock models, dirt models and textures. A wide variety if important so that we have a lot of examples to play around with to get the right look and feel.
Simulation
This past week we achieved several hurdles and milestones on the simulation. The first of these was getting the fluid particle demo to have lit surfaces, instead of the null, black surface we were getting. Next, I managed to take the simulation a step further by having the bucket of the MTL actually scoop up the particles instead of just passing through them like a ghost.
Our next steps are to optimize the simulation so the machine does not bog down. We using what we are calling a “fluid drain actor” – that when once an invisible barrier touches leftover particles, it deletes them. We have this working with moderate success. We are also brainstorming ideas on ways to have the particles spawn realistically once the MTL hits earth.
UDK Script
This week I continued the works from last week. For Unreal scripts, I learned the more from the code sample from the package installation. I understood the structure of the unreal script file. Each file is a class/module inherited from a base class given by the UDK system. The system provides sealed classes for various purpose, namely, base object/weapon/actor/vehicle/pawl, etc. The 3rd party developers could inherit and expand these base code and make the new ones. However, the common functions like binary file reading and parsing files are quite different from the way we did in Microsoft Visual Studio.net, I haven’t got the functions to visit binary files so far. Due to the unique structure of this language, which is completely isolated from Visual Studio.net, we need to learn those in UDK way and it makes less sense.
For the animated texture, I made a demo for that, a small village around a pond, the animated texture is a floating stream on the pond. The demo looks nice and the texture works fine. This texture could also be used to simulate the floating dust in the MTL working place.
The village within a pond, the animated texture has already been applied.
Some strong stream floating on the pond.