Engineering II - Week 5

DOWNLOAD FILES 

This week we implemented movement capabilities to our graphics engine. This involved making a camera to move in 3 dimensional space, zooming in/out, left/right, up/down. On top of that, we added the same functionality to our “Game Objects”. Instead of sending individual pointers of clusters of data, the user now has the option to inherit a MonoBehaviour class I created to store and send components.

Controls: 

• Camera: WASD
• GameObject: Arrow Keys
• Space: replace shade
• Enter: hide mesh

Making Shader’s platform independent:

We used preprocessor macro function in a shaders.inc to substitute defined variables and functions. It could really just replace any text it finds within a shader, but I tried to keep my defines understandable for future shader development. 

Movement Prediction:

The game update and graphics update run asynchronously. Game update runs on our set frame rate, which is 15 fps, while the graphics update runs as fast as it can. This results in jerky movement of objects without extrapolation. We have a function UpdateSimulationBasedOnTime() in game update to apply velocities within our sRigidBody. We extrapolate within graphics frame using PredictFutureTransform() method after passing in our rigid body. 

“GameObjects”

I made a MonoBehaviour class, mimicking Unity’s implementation. This seemed like the most understandable solution for me since Unity is my default engine for most projects. For this implementation, I made a base class that all future game objects should inherit from. The benefit of this is being able to call methods without the user needing to know or implement themselves. They just need to override the existing methods. This also gave me the ability to use object oriented programming to its fullest and implement a component system. 

Right now, there are 3 components; rigid bodies, cameras, and draw lists. For this current build, camera is it’s own object so that it can freely move around the world. In the future, I plan to apply the same movements to children of MonoBehaviour. 

One thing I’m still thinking about is how I’m going to pass data into the graphics thread. Right now, the user still needs to manually call the submit functions in the graphics library, but I gave them a cozy place to do it within MonoBehaviour.

Memory Usage:

I ended up refactoring a bit of my implementation from last week. For some reason, I was doing string compares instead of passing a bool to check for a shader change. I also changed the clear buffer color struct to be passed into graphics with a pointer. 

Adding to our memory size, we are now storing 2 rigidbodies and camera information. 

Rigidbodies include:

• 4 Vector3 > 3 floats each > 48 bytes

• 1 Quaternion > 4 floats > 16 bytes
• 1 float > 4 bytes
• Total: 68 bytes

Camera:

• 4 floats (FOV, aspect ratio, z near plane, z far plane) > 16 bytes
• Contains a rigid body