Game Engines - Roboy Phyre Engine 5

     For our game using Phyre, we are working with the Bullet physics library. Going over the various samples for setting up and managing physics worlds, we were able to implement dynamic layouts and all dynamic set ups. 

    We found through trial and error how everything needs to be set up, managed, and handled. Given the design concepts in mind, we understand how we should set up different groups for physics bodies as the project grows larger. Going over samples closely and monitoring source code was essential, since the documentation does not give a much useful description.

    Working with the physics engine, and attempting to handle everything dynamically, we found what exactly was needed for each step of set up. First, we need to associate the current media asset’s mesh with the Physics rigid body.

    Using the Collada exporter when handling our models, we can easily get the mesh instance of our object file from the converted and runtime ready media file from the asset processor. This is the only dependency for initializing the physics components, as the mesh of the rigid body is defined in Maya.

           

Going over the final ending code, each step is broken down to various concepts that make sense in their implementations:

     Initialize Material from source media

     Initialize Mesh from source media

     Initialize Model from source media

     Initialize RigidBody from source media

     Instantiate PhysicsModel to destination cluster

     Instantiate PhysicsRigidBody to destination cluster

     Copy RigidBody media to PhysicsRigidBody

     Set Rigid Body defaults

     Add Rigid Body to Physics Model

     Add Physics Model to World

  

Firstly, as stated before, we simply gather all the information found in the exported media file. The Collada Maya exporter and the Phyre asset processor handle everything regarding making the physics and mesh information readable by the engine, so we don’t need to worry about that. At this point, we are managing generic Cluster types, but as we continue to make iterators of the class types we need, we slowly cast to the types needed for adding physics rigid body to our world.

            Next is to dynamically create a physics component for the cluster loaded in, so we instantiate the needed components on the destination cluster, and begin to fill the values after. After creating the new rigid body to be added, we simply copy the data we need over and set the variables that will be taken care of by the engine.

            In bullet, the basics are that rigid bodies make up a physics model, and there are multiple physics models added to the world that help separate them into groups.

So when creating everything dynamically, we need to:

• Create Rigid Body(s)
• Add categorized bodies to Physics models
• Add each physics model to the one instance of the physics world

Following this model, we have a bunch of rigid bodies that are grouped in physics models that we can define. For example, let’s say we had a function that did something special to each car in the scene every frame. 

It wouldn't make sense to loop through and handle physics on objects like buildings and towers, since this specific function just needs to get the positions of certain cars, or handle a specific physics functions on cars specifically. With this model, we would set up a different Physics model with each car as their own rigid body and handle them separately this way.

    It was also helpful to discover multiple debugging tools found in bullet, such as drawing a line from point to point (useful for testing ray casting), and the more useful wireframe draw, where we could easily see if dynamic rigid bodies were being created properly. Only the depth buffer is cleared, as the wireframe is drawn overtop of all the geometry, as well as changing colours when colliding and errors are present for more helpful debugging, and fortunately worked simply by pasting a few lines of code.