Gravity, The Ground, and a Tripod Rain

This weekend has been jam-packed with programming and I've gotten a ton done. Today, I successfully completed my implementation of traversing the collision hierarchy and detecting collisions on all levels of the tree. Here is a video demoing this with three tripods and their respective bounding volumes (the bounding volume models are turned on now for testing and demonstration purposes. While they are difficult to see within the collision models, the tripod objects are green when not colliding and red when colliding, like their collision models).

Days and nights have flown by and I feel like the entire weekend has melded into one long time day but I am very happy with the results and will not let up with working on this and getting it done! Getting the collision hierarchy traversal for collision detection to work was by far the hardest thing in the project, if not all year, so far. I spent hours drawing out pictures, writing pseudo-code and debugging. In fact, I have a Steno pad full of variable addresses, diagrams, and my workings out. Yesterday was fueled by two bottles of 5 hour energy and a lot of determination. At around 1:30, my mind couldn't handle tracing through the logic anymore so I decided to go to bed. I still did not have collisions working correctly. I took screenshots to detail my progress though and what I had is chronicled in the images below:

Dynamic Traversal: Not Colliding

Dynamic Traversal: Level 0 Colliding

Dynamic Traversal: Side View - All Levels Colliding = Colliding Forms

Dynamic Traversal: Top View - All Levels Colliding = Colliding Forms

This looked great until I moved the objects even closer together, at which point no more collisions were registered. I began to run through my code again and rewrite it, but I was like a maniac at that point-- desperate and totally off. This morning though, I got up and went at it. With several hours spent in a marathon session of logic processing, I began to iron out the implementation and voila! I then proceeded to test more tripods as well as adding velocity to them (like in the video). Now, the plan that I have laid out is as follows, with the yellow highlighting representing what I have done already and the red what needs to be done:

1. Program in a ground plane with respective model 
2. Implement Gravity
3. Write function for collision detection between Collision Volumes and Ground
4. Implement Rigid Body Collision Handling between the Ground and Collision Volumes
5. Implement Rigid Body Collision Handling between Collision Volumes (The detection is already implemented) 

Tomorrow will be another day full of hard work, but I am determined to also make it one full of results! The train is now in supersonic mode.

The Hierarchy of all Hierarchies

Exhausted-- been programming my hierarchy since coming home from night class and having spent the previous night coding until 3am and then more during the day. Once I started to implement my collisions manually, I understood the way to do it. After speaking to Keenan about my current status, it was time to convert my implementation to be dynamic. Now, I am working on creating the right hierarchy using my PCSTree from last quarter's Engine class. I have to traverse it in a unique way and am finding myself writing more code in PCSTree to work more comfortable with CollisionVolumes. I'm stopping at this point because my brain is really tired and I can't think straight but will resume in the morning, hopefully refreshed.

From Big to Small and Everything in Between

I've been busy getting my collision hierarchy working and can happily report successes in that department! I'm really excited! Since getting my collision model to display as I mentioned in the previous post, I have added another sphere around the collision model and gotten rid of the object's original bounding sphere (which did not take the collision model into account). That main sphere is now the root of the hierarchy tree. If the main roots of two tripod's collide, I go on to test their individual legs. I now have the tests for level 0 and level 1 of the tree working, so when the tripod's collide, the colliding legs' spheres and root spheres turn red! What's left is the specific portions of the legs, represented by the baby spheres. The only downside to the work I've done so far is that it is not automated. I do not have my code set up so that I can just run through all of the spheres and check for collisions in a loop. Instead, I wrote all of the tests out. This works just fine and is even more readable but, it is also not the way to do when working with objects that have significantly more bounding spheres; especially in cases where they are self generated. I am going to complete my collision hierarchy code this way first and then if I have time, rework my code to be more dynamic. I'm excited to continue this tomorrow and complete my collision hierarchy!


Here are screenshots that I took earlier today when I had gotten the main spheres collisions working:

Mains Colliding

Mains Not Colliding

Collision Model in Place

Tonight, I am happy to announce that my collision model for the tripod is in place and accurately transformed parallel to the model. I was having a lot of trouble getting the collision model to work and have spent quite some time on this, including a recent 14+ hour non-stop programming spree. I had created the collision model in Maya by placing spheres manually in a hierarchy around the tripod. However, I could not load the model into my graphics engine. 

When I saved the model and exported the .fbx as a single mesh, the engine would only render one sphere, a single encompassing sphere that was glitchy. After much digging, I have come to the conclusion that this is because I am using Line Loops to draw wire-frame, and with multiple objects inside of objects (spheres inside of spheres) being combined into one mesh, my converter and engine are getting confused in their interpretation because the data isn't in the expected format. When I left the meshes alone, the converter would only process one sphere in the hierarchy, since the loop inside the converter is meant to process the first layer as the mesh which is standard. In other words, my collision model was not standard, especially with my need for it to maintain separateness and transparency (via mesh). 

I ended up solving this problem today by creating a header file with all of the collision model's sphere's centers and radii, which I had recorded earlier from Maya. I then created a collision volume class (which in this case is a sphere). I gave the form (tripod) 24 collision objects and set & updated them accordingly. I also needed to figure out scaling. This was a little tricky because the tripod model and sphere model were being scaled differently from the collision model's spheres, but I found the right factors and now have my collision model displaying in my Graphics engine, just like Maya. Below are some screenshots. The tripod can be seen inside of the spheres in blue. The sphere centered around the tripod is the original bounding sphere which is generated mathematically. 

I am going to go back into Maya and place a large bounding sphere around the collision model itself tomorrow. Tomorrow is also hierarchy programming day where I will begin to write hierarchy collision code. Here is what I have in the meantime;-) 

Success at Last and the Age of Industry Again

The day before yesterday, I finally succeeded in fixing up my bounding sphere display issues! In my previous post, I had written about the problems that I was having with the spheres either not displaying around non-cube objects or altering the cube objects that they surrounded. They were tied together somehow but I did not know how at that point. 


Then, on Tuesday, I re-wrote a lot of my Form.cpp and BoundingSphere.cpp code, making Bounding Spheres more like forms in terms of their own matrices and transformation update functions. By adding in a transformation function, I was able to call it on the bounding spheres outside of the inner object's transformation update and consecutively instead. This really helped the situation because it prevented the order of operations (programmatic) mishap from happening. I speak more about the fix in the videos that I made to showcase the working collision spheres. 


The first video shows the improved cube collisions as they should be, and the second video demonstrates that the fix works thoroughly on other models as well (I used cylinders in this case). 

Now, it is time to move on to the collision hierarchy. I've been reading the orange collision book "Real Time Collision Detection", namely Chapter 6 which focuses on hierarchies and how to design them, select the best one, and so forth. I am going to adapt my own version in a concoction of the book's suggestions. Keenan recommended that I place small bounding spheres in the form of the underlying object model manually. This creates the collision model. I have already created this, and today will be working on converting it and using it in my Engine. 


Here is my plan for today and extending into the next two days (the goal is to get this done before the weekend):


Where the tree is represented as:

First code dealing with Elongated Rectangular Objects Surrounded by Bounding Spheres:
Hierarchy:
1. Test collision between parent Spheres Sa and Sb
     If CollisionSaSb = True
          2. Test Collision between A and B (Bounding Boxes inside)
               If CollisionAB = True
                    *Colliding Objects A and B*


Next code dealing with Tripod Objects with Sphere Based Collision Objects Surrounded by Bounding Spheres:

Hierarchy:

1. Test collision between parent Spheres Sa and Sb

     If CollisionSaSb = True

          2. Test Collision between Sa1 and Sb1...Sbn through San and Sb1...Sbn

               If Colliding = True for any San or Sbn

                    *Colliding Objects*

Although the book does not recommend manual placement of bounding objects for large scale models as this is inefficient and can lead to issues for groupings in creating a hierarchy, I can do this comfortably for my small spheres in the collision model since I already know that all of my objects will be using the same model for this project. This fact also helps in designing my tree traversal strategy. Here is a diagram I made to lay it all out, furthering the explanation of the above code idea. I haven't started implementing this yet-- that is what today's agenda is-- so I don't know how well it will work, but these are my thoughts and understanding so far.

Bounding Spheres When They Choose To Be

After much reformatting and deleting of my code, I significantly downsized my engine. You would think that this would make things simpler (which was certainly my intention) but alas, I still feel like I am stuck in the mires of a swamp. I can now display wire mesh bounding spheres around solid cubes. These spheres transform accurately with their inner objects, and upon collision, they correctly change color. However, two problems still remain which I am currently working on resolving:


1. When the bounding spheres change color (I do this by passing the shader a different light color when the spheres are colliding), the inner objects visually change color as well. I say "visually" because when I debugged the code, I noticed that the objects actual colors had not touched, but were displaying as the overriding bounding color. These two objects should be entirely separate in that respect but somehow, they are linked where one is overshadowing the other-- I need to figure out what the link is here.

Here is what the cube (untextured) in a bounding sphere looks like:

2. Another issue that arose is that the bounding spheres do not show up around other forms, like the cylinder. Instead, scaling of the form's bounding volume results in scaling of the cylinder, which is clearly not what I want. Again, there is an unwanted link in here somewhere and I am working now on determining where and what it is. I have a feeling that I will need to reformat the code yet again. One idea that I have though is that perhaps I am passing in a modified matrix that should have been set to an identity somewhere, and this is causing incremental changes. I just don't understand why this is affecting everything but the cubes though-- what makes them different?

Here is what I see when I apply the bounding sphere to a cylinder model (untextured):

These are the two main issues that I am facing right now. I have made good progress but want to iron this out before I can comfortably move on. This is what I will be working on tonight.

Bounding Volumes and Collisions

At this point, I have bounding spheres and bounding cubes being created correctly. I also implemented sphere to sphere collisions and box to box collisions successfully. However, a huge impediment to my progress is the fact that I still cannot draw an actual sphere to represent the bounding volume. 


In order to represent collisions now, I am printing out whether the objects are colliding to the console window, in addition to changing the color of the objects themselves. I pass a green light color to the shader if the objects are not colliding, and a red if they are. This is good for testing purposes, but I am still very unhappy with the lack of actual wire-frame and spheres. 


Despite the sphere problem though, I am going to work on creating a cube wire-frame today to represent the bounding boxes around objects, and then move on to really getting those spheres done. The fbx converter that I am writing for engine is now able to successfully extract the necessary model data from fbx's, but for some reason, I am still not able to draw the cube successfully. I will have it working right by the end of the week, and plan on using fbx's to draw my bounding volumes then if no solutions arise faster.I will post more on my progress later tonight.