Doing Some Math
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.
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
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
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.
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!