An Entertainment Technology Project
Welcome to the Heavy Metal 2.0 project website. To find out about our client and find information about the project, go to the about page. To learn a little more about the people working on the project go to the team page. To look at images and videos for this project go to gallery. Below you can read through our weekly news letters to see what the team has been up to and the progress we are making.
Weekly Newsletters
Doing Some Math
Antonio Santos
When moving towards a real time simulation, there are some details that wehave to take care of in order to make it more realistic. For example, last week we managed to make dirt berms come up from the ground when our main character moved, as happens in real life when a bulldozer moves. But the problem
was that those berms spawned every time we moved, regardless of where we moved, forward backwards, left or right.
In the virtual world things like forward and backwards are not so trivial. Everything is related to a coordinate system with X Y and Z, and the world does not know if our MTL is moving forward or leftwards, it just knows its moving towards a certain point. But fortunately, the system also knows where the MTL is looking at. In math, those two things, the direction where we are moving and the place we are looking at, are vectors. Using basic math operations, we can easily know if those two vectors are pointing in the same direction, and problem solved, now the berms are only spawned when our character moves forward. In addition to that, dust also emerges while we move, and next step is setting up an adequate speed for the MTL.
Achieving Goals
Matt Champer
The past week I’ve been documenting our progress on the simulation since halves, adding a new document to our previous documentation on the particle simulation. It covers how we set up our proof-of-concept triggered event in UDK, which Antonio has taken and is now implementing the real-time solutions.
I’ve also added in a duplicate simulation using the CA6 materials and meshes. For the most part, it’s identical to the overburden simulation, but with new textures, shortened animations, and new meshes for the berm. I also switched out the particle emitters from the overburden to the CA6 particles that we developed some weeks back. The environment has also been updated so there is now a distant background.
Putting Everything Together
Samantha Collier
This week began with our soft opening presentation. We got a lot of good feedback on how to best use our
remaining time to polish up our work and package things.
With only a few short weeks left we have been focusing on improving are current progress. Now that we
have the basics of the simulation, we have begun to finesse it so that we can have a few different types of
materials to work with. This week I have been working on making new animations for rocks and making
berms that reflect the behavior of the different types of materials.
The rocks I am working on are part of a system so that we might have to worry so much about particles.
How it will work is it will be spawned, or appears, as the bucket collides with the ground and begins to
move dirt. This will help the appearance of the dirt or materials flowing into the bucket.
The other thing I have been work on with the berms is creating new berms that will work along with the
different material type presets.
Documentation & Hand-off
Sean Brice
As we approach the end of the semester, it’s time to start polishing our documentation and hand-off files for the client as well as anyone who does future development on this project. This documentation will include our process for the multiple tasks done in UDK, how to access our source files, and possible ways to implement our work into other viable game engines.
Our hand-off will include all of our documentation, source files, reference material we used, and our presentations from the semester. There will also be documentation explaining our folder structure. Our final package hand-off will contain the information for how to contact the responsible team members as well as the client contact.
Breakthrough
Fuming Guo
The biggest break through this week was working out the remote control of the MTL in the scene without setting any driver into it. To accomplish this goal, we solved two technical difficulties. The first one is to detect the key press by the client. In the Unreal Development Kit, the definition of key response is done by a INI format file called “DefaultInput.ini”, the file gives most of the input settings in the editor and the game. So, I first got some default key bindings in this file, and then remove them, lastly, change the definition into ours. So the old ones were overwritten.
The second break through is we could get the reference object to the objects in the map through UnrealScript and operate them. This problem is an old problem that we have faced to for many weeks. The UnrealSscript system provides an object call “Allactors”, which could make the developer be able to access every object in the map. So we use this to get the MTL by setting the specific category “UT_Vehicle_MTL”.
Antonio and I also finished transplanting my code into the main code. It took us about half an
hour and it works fine!
Towards a Real Time Experience
Antonio Santos
When we took the decision of moving to the Unreal Engine instead of using Unity, one of the best aspects that we took advantage of was the Unreal Editor. Within it we could make the demo of the simulation without the need of programming code, so we could start seeing how our work would look since the beginning. During the simulation we could trigger events like the materials moving on the bucket of the MTL or the stones being carried by it. Now using code programmed in UnrealScript, we can start playing with the simulation and see results in real time, having full control on the simulation.
We still need to keep working in this direction, but this week we managed to see the berms forming around the MTL while it moves in real time. Even though in the demo we are using right now to test it we cannot see the MTL yet, the mechanics of the berms showing up will work once we have the 3D model of the MTL inside our application.
Achieving Goals
Matt Champer
This week our team achieved the goal of completing a rough simulation for our soft presentations. The current completed simulation involves the MTL running through the slot. The MTL hits a mound of dirt, which is an indicator for where an operator can dig, and then a series of triggered events happen in which material builds up; demonstrating a proof of concept.
The full range of visuals involved are flying dust particles, berm buildup on the sides of the slot, 3D physics particles moving about and a 3D mesh that scales up on the Z axis in the bucket of the MTL. Our next step is to fully integrate the MTL as a dynamically controlled vehicle and to brainstorm ways to bring this simulation from a scripted series of events to a fully dynamic system.
Polishing Our Way to the Finish Line
Samantha Collier
We are coming to the end of our semester. During this time we will be focusing mostly on finishing any new features, documentation and ,of course, lots of polishing. Different members of the team have been working to get different aspects of the simulation they have been working on individually merged into one. Myself, I have been focusing more on polishing different art assets. One of thing I worked on earlier this week were animations for the MTL but now I have moved on to making new textures for the spillage simulation so that we can have a few different material simulations to keep from. Along with polishing already existing assets, I will be making new assets to help polish the simulation. What I am doing is making rocks with bones and animation to possibly replace the particle rocks in the current animation. These rocks will be spawned into the bucket when actively digging or gradating dirt. What we hope is that we can get the same look of the simulated rock but with less cost to the engine
Realism & Updating Documentation
Sean Brice
To further the realism level of our product, I implemented more rigging elements for the MTL, specifically to move the “teeth” of the treads. This rig had to be simple for rapid animation purposes and importing into Unreal, but still be powerful enough to provide a realistic feel. With this new addition, I had to add in a segment about how I implemented it.
With this new rig, I had to make some new animations that contained all of the rig’s elements. These animations will help to serve as a proof of concept and a visual guide for the real-time implementation.
The Process of Implementation
Fuming Guo
To build an MTL is not an easy job. Although UDK shares the same coordinate system with 3D Max, it has some tiny differences. Last week, Sean and I worked on building a correct mesh of the MTL so that it could be correctly displayed and interact in our application.
At the very beginning, the MTL fell down from the several meters high and collided with the terrain in a very
strange way. We first thought it might be the problem with the collision boxes, but we could not worked it out according to this. Then, Sean suggested that it might be the problem with the coordinate system. We used the mesh from the web tutorial (which works fine in that tutorial) and it does work fine, so we concluded that it must be the coordinate problem.
Also, the tutorial said ways of solving the problem using Maya and 3DS Max, 3DS Max is harder. We tried many times. Lastly, we could make the MTL collide with the terrain correctly but only a problem which is there is a bias in the Z axis between the mesh and the collision body. After hours of checking the parameters in both Vehicle_MTL scripts and UDK editor, we solved this problem.
I have also been working on building a animation tree in UDK editor, the function of animtree is to play animations according to the logic set up by the designer. An animtree for a vehicle could help it respond and play the right animation according to the circumstances affecting the vehicle.
Making Things Appear
For the simulation, our MTL will be able to move forward, pitch the bucket to ground level, and then it will start moving terrain. Part of this terrain will be loaded into the bucket, and other will be spilled through the sides of the bucket. All these things that seem natural in the real world, need some ‘magic tricks’ in our virtual world.
First of all, we will detect when the bucket is low enough to collide with the ground. Once that happens, using programming code we have figured out how to make the the terrain being moved into the bucket. This piece of dirt is something completely different to the dirt on the ground, but making it show in the right moment will make it look natural. The other trick is making the side spillages also appear in the right place and moment. This appearances need different code functions. First, the function that makes things appear on the virtual world. Second, a function that lets us know where the MTL is and where it is facing. And also a function to make the appearance smooth, controlling the transparency of the pile of dirt so it looks like it is being built piece by piece instead of just showing completely in one instant.
Achievement Unlocked
Matt Champer
This week, we managed to overcome our previous road-bump of getting the berm’s material to fade. After some tweaking, we discovered this isn’t exactly what we were wishing to achieve, as it doesn’t look as realistic as we had hoped. So we moved onto another option.
The new option involves scaling the berm in the Z direction, from a very low percentage, to 100% of it’s standard height. This has introduced a new obstacle to overcome, which is the jagged transition from tiling these berm meshes since they are built in a modular style. We are getting what looks like stairs or steps that inflate, instead of material build-up. We are currently brainstorming an efficient
method so that a rough demo can be finished by mid-next-week.
Rocks and Video
Samantha Collier
For most of the week I have been focusing on getting 2 videos made. These videos are just a few of the obligations the team has during the semester to document the project. The videos are used mostly as aids for other members of the ETC can get a quick understanding of what the project was.Visitors and future ETCers will be able to find these videos in a few different place, either on the ETC website, the bridge or on our website.
Moving Forward, Promo Work
Sean Brice
I’ve been spending the week working towards implementing the MTL as an user controlled asset in UDK. Sam finished the animations for the MTL, which I exported from 3D Max and imported into Unreal. There are 9 animations that we have, which serve our needs for this semester and provide a strong foundation for future team development. With the animations of the MTL inside of Unreal, we can head towards implement user control and furthering our current demo.
I’ve also been working on documentation for future teams in regards to how to rig the model for Unreal use and the export/import process. We also have promotional videos due soon, so I’ve been working Sam to provide media that will showcase what we’ve done this semester as well as inform guests and prospective students what our project is all about. from existing databases. The use of SACR technology could also potentially allow us to implement the colorized system that Caterpillar is currently using for their remote control systems by integrating colors using the locations of the in the MTL.
MTL Moving in UnrealScript
Fuming Guo
In Unreal Development Kits, most vehicles are physics based. For our MTL, it is the same way. The movement of the MTL should be physics based forces. After several hours research, I found some fun and the terrain. At the beginning, the forces could only affects the MTL at the time when it is in the air or when a person is in it. It does not move when it touch the ground. After that, I tried modified the physics body(it is just a box before) and add 4 tiny boxes as the touch pivots, the area of contact became smaller, the friction became smaller as well. So now the MTL could be moved in any time, even there is nobody in it.
I am searching some tutorials and resources to detect key inputs from the client. If this could be solved, it is possible to control the MTL moving in the scene.
ctions to give forces to the MTL. Specifically, the functions AddForce and AddTorque are the most essential. Besides, the physics body is also affected by friction between the body.
Camera and Action
Antonio Santos
In order to make a simulation that provides useful information for the operator who is doing the remote control, the Multi Terrain Loader has the main role. Right now the model and textures are finished, and it has a highly realistic look. The next steps for it to come alive are first of all its movements. An approach to be able to control the MTL on a common PC, would be using a keyboard and a mouse. This is a common approach taken by many video games, and allows to use both hands, one apart from the other to add comfort, and using very few buttons, so it is very simple. As also happens in many games, the keyboard could be used to control the movements of the MTL over the terrain, moving it forward, backward and making it turn left and right. Apart from this, the movements of the bucket could be controlled with the mouse, lifting it with the left click, moving it down with the right click and pitching it with the scroll.
Apart from the movement, the point of view is also very important to be aware of what happens around the MTL. An initial approach for this project will be having a 3rd person point of view, from the back of the MTL. With the mouse movement or other keyboard buttons such as Q and E, the camera could be rotated around the MTL, allowing the operator to see it from any angle. Depending on the operation to accomplish, different points of view are better in different cases.
More Road-bumps & Milestones
Matt Champer
This past week was a mix of success and more road-bumps. We had three things
to accomplish with our new approach to the simulation. The first was animated
materials, to give the impression that the dirt was moving around to the affect of
gravity within the bucket. The second was to scale-in (preferably on one axis) a
static mesh of dirt within the bucket, giving the illusion of material build-up. The
third was to fade in the berm growth along the slot that comes from the material
spillage out of the MTL’s bucket.
The first was very easy to accomplish, and we did with little to no problems.
The second took a bit of creative thinking, but was also rather easy to implement.
The third is where our road-bump comes in, and where the simulation is currently
be prevented from being fully fleshed-out. A lot of the old methods for doing so
are documented rather well on the web, but UDK has undergone several iterative
upgrades and patches since and these methods are now completely removed. My
goal by the end of the week is to find an appropriate work-around and to finish
the new simulation before the end of the week.
Building a Better Visualization
Samantha Collier
This week I have been working to get the new simulation ready. I have been working with Matt to make a
system to help operators have a better idea of the large amount of dirt they are moving. Not only do we
need to see how the materials look as it is left behind, but also what the materials in a pile look like,
either being added too or taken away from; as well has how to tell when are buck is full. This was brought
to our attention during our visit with Mike Taylor and Bob Shoop.
Also this week I have been working on animating the MTL so that it will move more realistic when it being
controlled by the operator. I am doing this by using the reference video we were giving earlier in this semester of the MTL here in Pittsburgh in action. Using the video for reference as been a big help in seeing
how the treads moves and the ways the MTL maneuvers around. Hopefully this aid will help use be able to
achieve a more realistically functioning MTL.
Rigging the MTL, SCAR Technology
Sean Brice
This week I’ve been busy creating and applying a rig for the Multi-Terrain Loader Model. For use in Unreal, the rig must be a single-tree hierarchy: every bone object must link back to a single core object. After I rigged it, I handed it off to Samantha for the animations that I will import into Unreal next week for testing and the start of user implementation.
As we are nearing the end of our semester, we need to start looking forward to where this project will go after we have finished. NREC (National Engineering Robotics Center) here at CMU has developed a system called SACR (Situational Awareness Through Colorized Ranging) that has the potential to further the project’s development. The use of the SACR technology would be beneficial as we might be able to use our models & textures as visual representations for the operator: as the sensors in the SACR system detect the material/terrain around the vehicle, it would call in our assets instead of using topographical data.
Vehicle System
Fuming Guo
My Unrealscript demo was finished by the weekend. It contains a demo map, which is done by the UDK Editor. I built the environment for this map, replaced “UTDeathMatch” with “GameInfo” for a non-fighting environment. I also built a custom class to display and test, the class contains a pawn object that could post the message on the screen. Also, I tested the way of calling Unreal run-time console commands through Unreal scripts. For example,toggle displaying octree in the map, etc.Now, this demo contains the following features:
1 – Individual running environment: the demo could be packed by Unreal FrontEnd tool and be published.
2 – Browsing feature: the gameinfo mode allows the end user to explore the map/scene in free flying mode, the free
controlling camera could go everywhere but also block the walls and obstacles.
3 – This framework is a base for adding more features in the future. UnrealScript is a programming language that is
highly modular. Every feature is fully individual and could be easily used by other modules and other modules could be added later.I have also started doing some study of vehicle building. I did the documentation for the artist to correctly model and rigging vehicles in 3D applications due to the different coordinate system in UDK.
Because of getting sick this week, my progress didn’t progress as ideal as hoped. Hope everything will be better next week
Road-bumps & Documentation
Road-bumps are inevitable, and the best way to get over them is to accept them and search for alternative methods or fixes. This week, we’ve hit one in which we have a very nice simulation, but the particles don’t seem to be able to stick to each other and cause a buildup like you would see with a mound of sand or gravel. Instead, they roll over each other like slow moving marbles. Sam and I immediately switched gears to attempt to find a solution.
Sam moved into developing an alternative to the buildup of the particles, but at the same time still uses the system I’ve developed to some degree; this is explained in further detail in her article. While Sam swithed gears into simulation tests, I swapped gears and moved into documentation on the current setup of the simulation demo. It covers the Kismet setup, along with any details on how we managed to simulate the dirt being pushed by the MTL. This will be available to the Entertainment Technology Center for any future projects, as well as to Caterpillar.
MTL in Unreal
This week I imported the Multi-Terrain Loader into the Unreal Development Kit. It was slated to be imported last week, but there were a few technical issues that had to be overcome. The MTL is made up of many parts and each piece originally had it’s own texture sheet, to allow for more realism in the textures. However, Unreal has a limit of about 10 materials per mesh, so I had to re-optimize the MTL to use 6 sheets instead of 12. With the new sheets, it would have to be re-textured to fit the new texture coordinates. Sam had already textured the MTL, so I used 3D Studio Max’s Render to Texture system to re-bake the created textures onto the new UV layouts.
Towards a Game-Like Simulation
Our main goal is exploring what game engines can offer to represent real life situations, in particular real life terrains where bulldozers operate. For that goal we are focusing our efforts in using one of the most popular game engines on the market, Unreal Engine 3. As it is one of the newest engines in the market, it offers a level of realism that allows operators to know what is exactly happening in the real world by seeing what is happening on the screen of their computers, the virtual world.
Part of the most popular game made with Unreal Engine, Unreal Tournament, apart from guns and shooting, are vehicles. Driving vehicles in the game is an essential part of it that has become more and more popular in every new version of Unreal Tournament. And now that we are using Unreal Engine, we can use the functionality that it offers to control vehicles. Many people are used to playing simulators and games, such as Unreal Tournament, where the players controls a complex machine in an easy way because of the advantages that video games and game controllers offer. In our simulation, controlling a Multi Terrain Loader will be as easy as driving a car with built-in rockets in Unreal Tournament.
Solutions
While we have been working to getting the simulation looking more polished, we have been faced with an assortment of problems. The main problem is getting the materials that are being simulated with particles to pile properly in UDK. We have been looking into a few different ways to fix this. One of the solutions I came up with is to use larger static meshes and planes with opacity alongside the particles. How this would work is that as the MTL is moving along, either grading the ground or pushing materials, a mesh would spawn along with it based on the placement of a bone. The particles that Matt has made would spawn with them and interact with the berm mesh. This would enable us to have the nice interactive look of the particles while not having to fight the engine to achieve the volume we want.
Another thing I have been working on is building assets and a way to set them up with the MTL to better the appearance of the simulation. I am doing this by constructing 3d meshes that will go into the bucket of the MLT when it collides with the ground or piles of materials. Since theses will be larger meshes that won’t be able to animate like the particles we have came up with an interesting way to still have the look of material flowing up into the bucket and out with animated textures. Not only will the load in the bucket have animated textures but we will go a step further by adding planes to the bucket with opacity on them and animated checks. There are three different planes that will be placed on the bucket. One over the front of the bucket and two to the sides. What this will do will help simulate a lite, looser looking soil and will also help the larger rock particles seem to move more naturally.
The latest thing I have started in is making static meshes that will be used to create collision triggers for picking up loads with the bucket. What we hope to do with these meshes is as they are triggered by the collision of the bucket, the mesh will either play an animation or swap with another mesh showing the change in the pile.
Finishing the Demo
My Unrealscript demo was finished by the weekend. It contains a demo map, which is done by the UDK Editor. I built the environment for this map, replaced “UTDeathMatch” with “GameInfo” for a non-fighting environment. I also built a custom class to display and test, the class contains a pawn object that could post the message on the screen. Also, I tested the way of calling Unreal run-time console commands through Unreal scripts. For example, toggle displaying octree in the map, etc.
Now, this demo contains the following features:
1 – Individual running environment: the demo could be packed by Unreal FrontEnd tool and be published.
2 – Browsing feature: the game info mode allows the end user to explore the map/scene in free flying mode, the free controlling camera could go everywhere but also block the walls and obstacles.
3 – This framework is a base for adding more features in the future. Unrea lScript is a programming language that is highly modular. Every feature is fully individual and could be easily used by other modules and other modules could be added later.
I have also started doing some study of vehicle building. I did the documentation for the artist to correctly model and rigging vehicles in 3D applications due to the different coordinate system in UDK.
Because of getting sick this week, my progress didn’t progress as ideal as hoped. Hope everything will be better next week.
Iterative Refinement
This week has been primarily spent on refinement for future development (i.e., cleaning up the simulation, removing older file versions, etc.) to decrease file sizes and keep things running smoothly. Sean and I also spent a good deal of time taking our achievement from last week of getting the bucket to push particles and evolving that into a more finalized result. Technically speaking, we took very basic entities and replaced those with what will be similar to the final deliverable, both for testing purposes and proof of concept.
We also spent some time cleaning our polishing our prototype simulation so that we have something visually appealing and understandable to look at for our halves presentation. An example of this is below.
Technical Hurdles & Halves
This week has been spent working to develop the material simulation while preparing for halves. I’ve been working with Matt closely, providing him with updated meshes that allow for proper collision detection on the bucket. There were a few issues we were running into was that the bucket was not catching all the particles and some would get stuck inside the actual mesh, or the bucket would move materials and they wouldn’t leave the bucket properly. I’ve also been preparing for the next stage of the project which is implementing the MTL in Unreal for user control.
I’ve also taken point on the presentation for halves. Since our project is under an N.D.A with Caterpillar, we have to make sure that we aren’t saying anything that isn’t public knowledge. For a presentation like this, proper media and pacing are important, so I’ve been going over that multiple times to make sure that we aren’t missing anything.
Unreal power
Our team is now focusing the efforts in Unreal engine. This is the game engine made by Epic, and the latest version is Unreal engine 3. Since its first version it has had a huge success in the game industry, with many AAA games released using it. The ones that made it popular were the Unreal Tournament series, developed by Epic. These are first person shooters with high end graphics and fast paced action, with many game modes.
However, Unreal engine can be used for any purpose, not only first person shooters, such as Magna Carta, Ragnarok Online 2 or Batman Arkham Asylum, as well as training simulators and other types of simulators. That makes Unreal a good choice, as it has a big support from the community, and it has evolved to be very realistic.
Programming-wise, Unreal also offers a great flexibility. Using the Unreal script language we can choose whether to use the code that Epic has used to make the Unreal Tournament 3 game, which would automatically add to the game the typical things from a first person shooter, such as a weapon, a crossbar to aim at enemies, life bar and ammunition count. It also allows to add players, change through game modes and chat very easily. But it also allows to use more basic functions not related to first person shooters, and customize the application as much as desired. During our learning process of Unreal, we will be able to decide which parts we can reuse from Unreal Tournament, and which ones create ourselves.
Rocks, Dirt and Milestones
This week I have focused on pushing ahead with finishing the MTL. Now that I am getting closer to reaching the milestone, while running into a few technical difficulties, I have time to start polishing the MTL so that it will be as close to the real thing as possible.
In between long texturing sessions and trying out lighting to see if the materials will appear proper in different resolutions, I have also been making material assets for the current demo that is in the works. Mostly I have been focusing on making more believable rocks. These models also need to be highly optimized to work with the simulations. Right now I have made a few different types of CA-6 and overburden ranging in an assortment of sizes. I did this for two reasons, 1. so that Matt has a few types to try 2. these materials naturally have varied materials.
Once I am finished with the MTL, I plan on making different types of piles of rock and dirt that we will start to work with, having the MTL hit and break the materials into smaller pieces using triggers as well as piles that the simulated rock will be replaced with to help with optimizing the scene.
Significant Breakthroughs
There are some breakthroughs over this week. First, the problem of compiling the custom built Unreal game was solved, we could now build our own game and package with Unreal Front end. This pushes the progress of our research. Besides, the error of loading our own map was eliminated as well, our own experimental project ran well.
And, I was also focusing on building Unreal project building. Most of the work are done by the UDK editor, the unreal script normally works for the game structure and instantly operate parameters and properties. I tried some functions provided by the UDK system, some of them works fine and some still have problems and need to be solved.
I tried to get rid of the default weapon and the 2D UI, the weapon is easy to be culled, the 2D parts could be eliminated in run time console command but could not be done by scripts, this is still being working.
Screen shot from our project
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.
Travel to Tucson
Antonio and I traveled to Tucson, AZ to visit one of Caterpillars construction sites, the Tucson Proving Grounds. This was an amazing and enlightening experience. We were able to see material (overburden) being moved around and took close footage of it spilling over out of the blade. We were also able to see the overburden up close to see the variety of rocks that overburden is composed of and get reference photos of that.
Being up close to the machines really gave us a sense of scale and just how much material these machines can move. We were also able to talk to 2 operators that were able to give us more insight into what a day on the site is like as well as the most important visualization information for them. We’d like to thank our gracious hosts from Caterpillar for this great experience.
Cloth and Physics
I started off this week finishing off particle set ups on the mtl. What I did next was parent an emitter to the animating mlt. Now when it moves along the terrain it leaves behind a trail of particles.
The next step to putting the demo together is using
psychics. I started off by first getting the basics working. I did this by placing rigid body modifiers on some shapes. To have physic on an object be more dynamic you also need to use a script. This allows you to determine the reaction of the object. After creating code in Java, I then applied it to the objects that were going to have forces acted on them. After I had basic shapes interacting with each other, I then applied what I learned to the rocks in the scene.
While working on particles and physics, I wanted to look into a suggestion that we could use cloth. The reasoning behind this is that cloth could ripple and tear. The end result of this would be something simulating a lot like dirt being pushed. I tried out the cloth by having it interact with objects in the scene. I also got some very interesting results when another object with rigid body was dropped onto the cloth.
Achieving Milestones
This week I managed to complete two simulation tests in the Unreal Development Kit. The results were both exciting and limited. The first test was using a particle system that contained a PhysX module. A PhysX module tells the particles to inhibit physics effects; these effects can vary from honey like substance to a more fluid effect such as water. The second test involved several objects that inhibited physics effects, and then were dropped into the scene just like real-life objects.
What happened, however, was that each simulation lagged the system heavily and brought the frame rate to about ~10 frames per second (standard is 30). The simulation performed close to our expectations and provided the answer we were looking for: can UDK provide a real-time simulation of the spillage? Our next steps will be to confirm whether or not either of these methods can still be used by tweaking and optimizing the current simulation.
First Instance of UDK Script
I started making the first demo project using UDK script. First, I set up the environment by following the video tutorial, everything works fine but the last build of this project, it crashed 2 seconds after the program started, this problem happened under the environment of UDK2011-1, visual studio 2010 and nfringe 1.26301. After that I tried different version of visual studio and nfringe, however the problem remains. Today, I tested again using UDK ver.2009-11 and the test doesn’t crash but the map I indicated couldn’t be found.
This problem is crucial, since it is the root of the whole program. It should be worked out to move on.
Programming in Unity
One of the game engines in which we are working is Unity 3D. It is an engine that
has become very popular recently because of its user-friendliness. It is easy to
start working in Unity as its visual interface is very powerful, not being restricted
to programmers. Just drag and dropping you can create a a highly detailed world
and tweak almost all their characteristics.
However there is more than a friendly user interface in Unity. The logic of the
world and the interaction of the characters (may those be human, vehicles or
monsters) must be programmed using a scripting language. This is what gives life
to the world. The languages admitted by Unity are Javascript, C# or Boo, and most
of the documentation is made with Javascript, probably because it is a seasoned
language and there are thousands of programmers familiarized with it. But for our
purposes we are using C#, which is a language much newer, with more potential
than Javascript, and better supported by the well known Microsoft Visual Studio.
C# could be seen as a mixture of two of the most successful programming languages,
C++ and Java.
UDK Research
For the past week, I’ve been researching higher-end features in the Unreal Development
Kit; such as Kismet, Unreal Matinee Editor, PhAT, Unreal Material
Editor, and the Fracture Tool. Kismet is Unreal’s scripting solution for the artist,
a visual interface where one plugs nodes into other nodes to form scripted events,
such as light switches. Unreal Matinee is completely housed inside Kismet as an
animation editor to animate different things, for example, an elevator or animated
materials. PhAT, or the Physics Asset Tool, is used for applying physics proper
ties to various objects while the Fracture Tool allows one to make objects crumble
to pieces when force, such as a gun shot, is applied to it. The Material Editor
is a visual graph node-system, in which it allows one to edit materials in real-time
with a visual preview.
For next week, I aim to develop some working prototypes in UDK to test some
of our theories and find whether they’d work for what we want in our simulation.
Applying Knowledge Learned
This week I have focused mostly on setting up a scene to
display examples. These examples will show the possible
routes we could take for simulation. The purpose of doing
this is to see what would look best and be compatible with
other aspects of our project. An example of this would be,
say what would work with the terrain deforming system
that was developed last semester. Or say, what could be
done in real time and still look good.
These demos will consist of collision, animated textures
and particles. These three things I have been looking into
for awhile now and wanted to display them in a more complete
manner. Other new demos I will be looking into were
suggested to use during quarters; with are cloth and water
simulation. The hope for these demos is that they will give
us clear illustrations of what would be possible by halves.
Preparing for the Next Few Week
This week has been full of preparation: both for the trip
next week to Tucson, AZ and getting ready to texture the
MTL. In preparation for visiting the Tuscon Proving
Grounds, I checked with Sam K to make sure they had everything
we would need for accurate measurements of material
changes (markers, flags, etc). In regards to the MTL,
I’ve finished the high poly model with the exception of the
cab, as I’m currently waiting on Caterpillar for how much
detail they want inside of the model. While I wait to hear
back, I will be texturing the rest of the MTL (the treads,
the bucket, etc). We had our client and representatives
from NREC come in to help discuss where our project is
going, which provided us with more theories and ideas on
how to proceed with the project’s development.
Next week I will spend time texturing the MTL before I go
to Tucson, and adding more features to the rig.