When objects come into contact while at rest, we want to handle their interaction smoothly rather than creating sudden movements. Instead of directly modifying their velocities and rotations, we apply a pushing force that prevents objects from overlapping. This force gently separates the objects, maintaining a more stable and realistic physical simulation. 

And finally, to make our simulation more realistic, we incorporate friction. By computing the friction forces, we gradually decrease both the linear and angular velocities of the objects over time:

The performance challenge with ragdoll physics comes from the intensive collision detection calculations. Each ragdoll contains 18 nodes and requires multiple layers of collision checks: internal collisions between its own nodes, collisions with static objects in the scene, and potential collisions with other ragdolls. These calculations involve nested loops, which become computationally expensive and can prevent the system from maintaining 60 frames per second when multiple ragdolls are present.

However, the inefficiency stems from performing collision checks even when ragdolls are far apart and unlikely to collide. This is where an octree data structure provides an elegant solution. While not the most efficient spatial partitioning method, octrees are straightforward to understand and implement. They effectively divide the space to reduce unnecessary collision checks, allowing the system to handle a significantly larger number of ragdolls without compromising performance.

An octree organizes 3D space by recursively dividing it into eight equal-sized axis-aligned bounding boxes (AABB). Each of these subdivisions, or nodes, maintains a list of physics objects that fall within its boundaries. The placement of objects in the octree follows specific rules:

1. If a physics object fits completely within one of the eight subdivisions, it gets assigned to that child node.

2. If an object straddles multiple subdivisions, it gets stored in the parent node instead of being split across children.

3. Objects that are too large to fit in any single subdivision are stored in the parent node. If they're too large even for the parent, this process continues upward.

4. At the very top of the tree is the root node, which encompasses the entire space. Any objects that don't fully fit within any lower subdivisions are stored here.

Following this approach, we can construct octree structures recursively, placing physics objects into their appropriate subdivisions as we go deeper into each child. 

When physics objects move, we need to keep the octree structure up-to-date. While we could rebuild the entire tree each frame (which isn't computationally expensive), it's inefficient since most branches remain unchanged. Instead, we can optimize this process:

1. We maintain a list of objects that are in motion

2. For each moving object, we perform these steps every frame:

   • Remove it from the current octree's object list

   • Check if it still fits within its current octree node

   • If it doesn't fit, move it up to the parent node

   • Use the Insert() function to place it back in the correct position

The Insert() function works by:

• Examining each child of the current octree node

• If any child node completely contains the object, place it there

• If no child can fully contain it, keep it in the current node

This approach is more efficient as it only updates the parts of the tree that need to change, rather than rebuilding everything.

When objects are moved around, we need to check if each octree node should be kept after the update. Empty octree nodes (those without objects or child nodes) are inefficient since they cause unnecessary recursive calls. To handle this, we implement a timer system with specific conditions - if a node has no children, contains no objects, and its timer has expired, we remove it from the tree structure. 

The project uses an octree data structure primarily for collision detection between two types of objects: nodes (which are moving objects) and either fixed objects or other nodes. Since every collision must involve at least one node, we can organize collision detection by focusing on node interactions. Each node has specific functions to handle collisions with different types of shapes. 

Starting from the root octree node, the Update() function begins checking for intersections by calling GetIntersection(). This function recursively examines child nodes, with each octree node only comparing objects in its own space and its parent's space. By organizing objects spatially this way, distant objects (like those in top-right versus bottom-left regions) are never compared, which greatly improves performance. 

Once all child nodes have reported their collisions, the root octree compiles a comprehensive list of Collision Records. The root then iterates through this list to resolve each collision that was detected.