OBB Implementation

With the basis of the ray casting and colliders working, it is crucial for the game to have box colliders. My goal this week is to implement box colliders to be integrated and fully working with the rest of the systems. At first glance, box to box collision should be simple. But I realized that is not the case due to the fact that we are using OBBs for collision and not AABBs. In order to test for OBB box to box collision, I utilized the separating axis test. And to find the correct axis to test, I transformed one of the box’s matrix into the local space of the other to optimize the process.

The next challenge was to get the capsule to box working. I struggled with the implementation of the collision. With a sphere to box collision, I check the axis of the extent of the box with the radius of the sphere to determine if an overlap exists. If so, there is a collision. With a capsule, it was a bit more difficult. A capsule has orientation and rotation, whereas in a sphere these qualities do not matter in terms of a collision. It occurred to me that a capsule is basically a collection of spheres aligned linearly. Therefore, in order to check for the capsule to box collision, I would simply check “all” the spheres that make up the capsule.

Lastly, I implement the ray-cast to function with the boxes and capsules. The ray-cast logic for capsule functions similarly to the box to capsule collision. It iterates through “all” the spheres that make up the capsule. The difference with ray-casting logic comes from the fact that I need to find/return the first point that the ray hits. To account for this, I collect a list of collision points that the ray has hit, and it checks and finds the one that is closest to the starting point of the ray.

Ray-cast Beginning

This week, I was finally able to get the capsule to capsule collision working 100%. The next main focus for me this week was ray-casting. Ray-casting is crucial as the teleport system and build system both rely on its functionality. The fundamental concepts and math for detecting a ray collision with a sphere are simple enough. However, the issue is determining how the ray-cast will be interacting with the rest of the systems.

The first issue was how to interact with spatial partitioning. As it stands, objects are partitioned away in order to optimize collision detection; the physics system then requests all items inside each partition to check collision within each partitioned space. But with ray casting, the ray needs be able to access every object in its path to check for a collision as it passes. In order to account for this, I made a function that would return objects within a partition. But the next issue comes with which space/bucket should I be requesting? The ray needs to check collision against every bucket in its path, however, it would be unnecessary to continue the check should the ray collide with something. Thus, to solve this, I decide to utilize an incremental approach. I increment from the starting point of the ray by a set amount, then request for the objects currently within my space and test for collision until a collision occurs or if it reaches a maximum casting distance.

Spatial Partition Needed

As mentioned last week, the goal this time around was to fully get the capsule to capsule collision working. While I have made headway with the system, there are still issues with the system. I was able to properly detect the collision. However, there is an edge case where the collision is not detected when two long/tall capsules positioned near perpendicularly with each other is intersecting about the midpoint of each other. The issue has been noted, but in most situations, this case should not happen. Thus, we have decided to put this on hold until it becomes an absolute necessity to account for this edge case.

Additional to the capsule collision, we have been working to incorporate a spatial partitioning system to optimize the collision checks. Austin was working on the partitioning, while I was working with physics system. Upon first integration, we had originally planned to have the physics system pass in a component to the partition and it would return a list of other components within the same partitioned space. However, we realized that this causes duplicate checks, i.e. component A checks against component B, and component B would also check against component A. Therefore, we have changed the function to return all the components in all the partitioned space and have the physics systems loop through each “bucket” and test the objects inside.

This somewhat eliminated the duplicate issue. However, an edge case still exists where if an object occupies more than one bucket and another object happens to occupy the same multiple buckets, the same two objects will be tested for each bucket that they both occupy since we are testing contents within the buckets. We have noted the issue and will have to decide on a course of action for the following weeks.

Capsule Struggle

 

The focus for the week was to have a working prototype to test the basic functionality of our game engine. The goal was to have objects in the scene and utilize controls to “shoot” a sphere and collide with the other objects. I was hoping to get the capsule collision working. Unfortunately, I was not able to fully implement capsule to capsule collision. In efforts to get a working prototype, I decided to at least apply capsule to sphere collision. There were issues in cases of capsule colliders that no collision was detected.

Starting from the top, I traced down to see whether the correct collision calculation function was called. Then, I investigated the math calculation for the collision. After spending some time debugging the issue, I was able to uncover a crucial flaw. Since colliders are shared, the unique information that changes the collider comes from the object’s transform matrix. I was performing the calculation on the collider with its position at the origin and never translated them to the object’s position. Thus, it never collided with other colliders. Once that issue was corrected, the sphere to capsule collision was working as intended.

Physics System Needs

 

This week we begin working on the physics system. The physics system should be a simple system that allows for changing the position of the objects and detecting a collision. I have implemented rigid body to utilize velocity and acceleration. As for collision, in order to optimize the collision system, we have decided to implement standard colliders for objects that can have multiple instances. For example, all enemy objects will point to a standard capsule collider with data on the size of the collider and apply their own unique information in order to “move” the collider for calculation.

We have three basic colliders: sphere, capsule, and box. Since most of our game objects are expected to have capsule colliders, we have decided to tackle that first. Unfortunately, we were unable to get the calculations on the capsule to capsule collision correctly. Thus, we fall back to using sphere colliders and got it running until we can further research on how to properly calculate capsule collision.

Project Start

 

Throughout the week we begin working on the basic structure of our engine. Austin, Carter, and I were focusing on the VR portion of the engine. I was able to extract the basic initialization function from OpenVR’s API and startup the VR headset. However, the issue comes when we are trying to render to the headset. While we were able to render a specific texture/image onto the HMD (head-mounted display), we were unable to get our test object to render correctly in the scene, indicating there was a problem with our projection/view matrices.

Debugging and locating the issue was a bit of a process. With VR, debugging was tedious; the limited amount of hardware did not help the situation. We used an example project as the base model to sample our coding/math calculations off of. Thinking that there was a mistake with the math, I revisited the math functions used in our engine; however, the functions were tested to work correctly. Thus, the problem was not with the calculation but steps we took and how we interpret the data.

After some research, we realized that OpenVR operates and returns data in a right-handed column-major format. While we knew that the data we received comes in column major and our engine utilizes row major, we did not account for the fact that data from OpenVR are calculated under a right-handed system, whereas our engine uses a left-handed system.

Once I was able to figure out the proper conversion of a matrix from right-handed to left-handed and create the proper projection matrix, we were able to see the base cube object in the headset. A few adjustments are still needed to display accurately but we made decent progress towards of our engine.