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.

Daily Progress

This is more of an update than a new post, but I am happy to report that I have made a lot of progress today. I feel very productive and am excited to go to class to learn about importing model fbx's into my project and converting them into binary;-) I plan on using this first for displaying my bounding spheres.

So, things that I have accomplished so far today:

• Fixed code to calculate transformations correctly. I now create temporary transformation matrices every update and have persistent model and modelView matrices in the base object of my primitive forms' class. This means that every update, none of the transformations are incremental, but rather the matrices are reset to identity and then the desired transformation is applied. I knew that my code was hacky before, but I didn't realize the deep repercussions it could have. Keenan even mentioned that it could lead to the object exploding or twisting on itself if you let transformations increment, such as constatly changing a saved rotation matrix. Happy that this is ironed out! Tranquility in my code garden.
• Created a sphere in Maya and saved it with tri's rather than quads. I asked Nick, a graphics guy, to do the Tri conversion for me. Then I saved it as a .fbx, ready for use in my next set of work!
• Fixed up bounding sphere creation code. Now that the transformations are working correctly, I can actually multiply the sphere center by it's LocalToWorld matrix to transform it just like the object, and the radius by the max. absolute scale to have it encompass the object. No more weird kinks, which leads to...
• Sphere to sphere collisions working! I tested these using printf's, visually, and in debug by checking the values.

All in all, good progress that I am very happy about.

A Light Shines Through the Weathered Boards

I had my meeting with Keenan this morning and am very happy with our discussion. He was exteremely helpful in looking at my code and explaining some of the physics to me. It turns out that the problems I am having aren't caused by what I suspected, but deeper, more foundational issues. This might sound like a discovery in the negative direction, but actually, it makes me more confident that I can make progress now. For me, understanding where the issue is is more important than fixing it by hacking and not knowing why it works now.

Anyway, the reason I decided to blog now rather than waiting until I worked today was because I want to jot down my "itinerary" of code stops that I have to make, in order to sort them all out in my head. So, here are the things that I need to fix/look at in priority order:

• Reformat base code in Primitive Object to create transformation matrices on the fly in the update, and move persistent matrices into the model itself. The primitive object should only store the attributes, like the degrees for rotation. Like Keenan said, these are "little notecards to yourself". Ensure that this is working properly before moving on to anything else.
• Create a low-poly sphere in Maya, and export it as an fbx as triangles (not quads).
• Taking tonight's upcoming lecture into account, work out how to import this fbx into my code and convert it to binary data to read in the model.
• Use this model of the sphere, or even just the verts (in this case, make a sphere model, like any of the other primitives), to draw the bounding sphere.
• Test sphere to sphere collisions now and get them working (use printf to test).
• Give the sphere the capability to toggle wireframe vs solid mode for visual collision check. 

So, I think that fixing the matrices is going to solve a lot of my issues, because I will then have a solid base with no hidden, hacky caveats.

Off to work on it then!

Pushing and Popping, Huffing and Puffing, All to No Effect

For the past several days, I have been working on fixing my sphere to sphere collisions. I kept on finding logical inconsistencies and tweaking my code, each time thinking "there's the rub! That should do it!" But, alas. Today, while debugging for the gazillionth hour and looking at my bounding spheres' centers, I noticed that they were inconsistent numerically with what they were supposed to be geometrically. I realized that I had been calculating the sphere's centers with respect to the local origin of the object rather than the world, so I fixed the problem and now the spheres' centers are correct. However, this did not fix the problem of c always being negative where


c =  distBetSpheres.dot(distBetSpheres) + sumOfRadii * sumOfRadii


GRRR!


To be honest, I also don't quite understand why I am squaring the sum of the radii. I understand how this is derived mathematically, as the orange collision book does a very good job of explaining this part, but I don't understand what this means graphically. I fully intend to ask Keenan tomorrow during our morning meeting.


It turns out that the radii squared are always significantly larger than the magnitude of the vector between the spheres squared, and I don't know why. This frustrates me to no end, especially considering that it's probably an issue that's really simple and that I am overlooking, and when pointed out to me, will make me feel like I do not belong in this field, yet again. Don't get me wrong, I love it. I just really don't want to end up shooting myself in the foot here. 


In order to debug this better visually, I decided to represent the bounding spheres as wire glut spheres while the objects are not colliding, and solid spheres when they are. Also, I was beginning to doubt the legitimacy of the math in my function, namely the c being ridonkulous (I know it's not the c's fault, I reckon it has to do with 2 different scales between the radii and the world coordinate system, or something really obscure). In order to move the process of testing along, I wrote another, simpler function for detecting sphere collisions. This one does not return t for the time of collision, but just returns true or false. All that I do is check if the sum of the radii of the spheres is >= to the distance between their centers. I then set whether they are colliding accordingly. 


Two issues immediately cropped up. 

1. A collision is detected very early. Mathematically, it makes sense as the numbers work out. Graphically, it makes no sense as the spheres are nowhere near touching. This means that something about my radii or sphere center calculations is off. What though? If I fix it, it should also fix the function that returns t and then c won't be all wonky!
2. The glutSpheres for both my cube and pyramid were drawn on top of the pyramid. So, on the screen, I had a lonely little cube with no bounding sphere floating around, and a spinning green pyramid flying across the screen, hogging both bounding spheres. I encapsulated each sphere creation call in glPushMatrix() and glPopMatrix(). I tried calling glTranslatef. Nothing. I even passed ridiculously large values to glTranslatef and yet there it still was, a green pyramid, with two spheres floating around it. This leads me to conclude that the glColor* issue that I had mentioned in my previous post is related to this, that any gl* calls that I make have no effect. I wonder why this is happening. I suspect that it could have to do with the fact that they are somehow being overridden by my other actions, or because I haven't been using glPush and Pop so far, resorting to my own matrices. I don't know enough about OpenGL to know if it has any special idiosyncrasies that I might be missing, or neglecting to respect.  Nonetheless, it is a frustrating conundrum that I plan on resolving tomorrow at the Keenan meeting.

So now, I can report that even though my graphical results look much worse than before, I am actually mathematically closer to having the problem solved. At least I know the issues now.

Colors and Textures

Spent about 6-7 hours today trying to figure out why my glutWireSphere wouldn't draw in a color other than black. The ultimate goal behind changing the color of the sphere is to have the wire spheres (which represent the bounding spheres of the primitive objects inside them) be blue when they are moving around and not colliding, and turning green when they are colliding. In order to test the waters for how to change the color though, I first decided to manually set all of the spheres around cubes to be red. Initially, I expected it to be as simple as writing:


glColor3f(1.0f, 0.0f, 0.0f); 


before calling glutWireSphere. However, when that didn't work, I began to try all sorts of things. I had started out by placing the sphere code in the cube's draw function, which is where I was first binding the vao of the cube model to the cube object. I moved these calls outside, into the form manager. This did not yield any progress. I then tried wrapping the calls in glPushMatrix() and glPopMatrix(), glBegin(GL_LINES) and glEnd(), and combinations of both.


At this point, I was quite frustrated and decided to see if it was a driver or machine problem that I was experiencing. I sent my project to my friend Jeff, and asked him to run it to see if he also saw black spheres. Surprisingly (because I didn't really expect to be right about this), he reported that the spheres were the same color (texture really) as the cubes that they encompassed. To test this theory further, he changed the call to glutWireSphere to be glutSolidSphere, and indeed, the screenshot he sent me displayed a swirly ball of sandy-stone color.


This was now doubly frustrating, because not only was the glColor* not having the desired effect, but I also couldn't test other ideas since I was still only seeing black. I have yet to figure out what about my machine makes it different, but I am very determined to do so.


I began to scour online forums, graphics sites, and all of my textbooks to see why my call to glColor* was being ignored. I even went so far as to change the glColor3f call to 4f, and then 3ub, thinking that maybe I was crazy and missing something very obvious. None of this helped. However, I did come across some interesting new information, which although it didn't solve my problem, taught me some useful facts.


First of all, it appears that when lighting is used, calls to glColor* will have no effect unless glEnable(GL_MATERIAL_COLOR) is called. Now, I am still unclear as to by lighting, they mean the specific call of glEnable(GL_LIGHTING) or just having lighting in general. I am still very new with lighting details, and never really learned about lighting beyond a very basic overview of types in a Graphics class, so forgive me if this is obvious. However, I checked my entire solution and did not find any calls to glEnable(GL_LIGHTING), so as a result, I still don't know if this applies in my case. Either way, I tried it to make sure, and, it did not help.


I then read that blending will happen if glColor* is called after a texture is bound. As one person explained it on a forum, OpenGL is a state machine of sorts, and once you put it in one state, it will not change until you tell it to do so. This is the case with all programming really. We programmers bitch all the time about the program not doing what we want, but we're the ones telling it to do the wrong thing, or not telling it to do the right thing. Any who, back on track. So, apparently, the blending is what was occurring as far as I could deduce from the screenshot that Jeff sent me. Calling glColor* would blend with the texture, or "tint" it to be the selected color in other words. In order to prevent this, I tried calling glDisable(GL_TEXTURE_2D) and glEnableTexture(GL_TEXTURE_2D, 0). The latter is being passed a null parameter for the texture id in order to clear the buffer, so to speak. Neither of these seemed to have any effect, not alone and not in combination.


At this point, I was once again at my wit's end-- a phrase I seem to be using commonly nowadays when I'm programming. I emailed Keenan and told him about my problem, and he suggested that it might be a shader issue-- something that I had not considered at all until then. For some reason, I had thought the shader and the  calls to the glColor* for glutWireSphere to be entirely separate from each other. After emailing Keenan though, he assured me that we would discuss the shader further next week to get it working, and that in the meantime, I could print to console when the objects were colliding. 


This brings me to another "discovery" that I made today, or rather, a realization. Looking at my sphereToSphere collision code, I realized that the velocity vectors v0 and v1 for each object that I was passing, were completely wrong. Rather than representing the object's actual velocities, I was passing in their translations. This is ridonkulous, and not what I had intended but after programming for a long time that night, I must have had a brain fart. I now know that I need to go back into my code and create actual velocity vectors for each object. Right now, the two objects that I have on screen do not even have any linear velocity, just rotational, because they are turning about their own axes. Overall, this means that even without colors and print statements, I already know that my sphereToSphere collision calculations are wrong because they are based on some ridiculousness that needs to be fixed to non-ridiculousness.


That is all that I have to update right. Hopefully, I will have some great progress to post about tomorrow!

Bounding my Frustrations with Spheres

It's been quite a while since my last entry, but I have been very busy at work on my engine. Soon after posting my first few entries, I got stuck. I didn't have a clear and detailed plan, just large general milestones. Having never taken on a project of this caliber before, I didn't know where to start. Having modularized several code examples from the SuperBible, I did not know where to go from there. After speaking to Keenan, I learned that it was much better to use Vertex Buffer Objects rather than GLBatches. However, I still did not understand how to implement them just from reading the book, and my progress dwindled to a standstill. I didn't even make any videos by this point because I kept deleting the code that I had written because I was happy with it. Nothing felt like an achievement because it wasn't "amazing", even though I knew that I was learning a lot even in making small examples.


Then, as we began to work on a Graphics System in my Engine class, I began to understand how a Graphics system should be structured. Little by little, I began to tweak my system. It was lucky that I could work on my projects in parallel for both Engine and my Independent Study, because it allowed me to really focus on the system and understand the details better. At this point, I was rushing to get more and more implemented in an increasingly shorter amount of time. I didn't think that videos and blogging were a priority in the precious time I had left. 


Looking back on it now, I realize that taking 15 minutes out of my day wouldn't have harmed anything, but probably only helped to straighten out my thoughts and chronicle my difficulties. I suppose that now, I am coming to terms with the fact that progress isn't only about success. If it were, then it wouldn't be progress because there would be no journey up as everything would come on the first shot. Instead, progress is at its best when challenges are overcome. That is why I am going to focus on chronicling my process now, to see how much I have achieved and grown by the time Spring quarter ends.


By the end of the Winter quarter, I was still behind in terms of my original milestones for the Indie Study, but my system was coming along-- it just took me a little longer than I expected to get there. Then again, that is the story of my life- underestimating how much time things will take. From now on, I am going to make a significant effort to work on things more consistently and thoroughly throughout, rather than at medium speed with high interval bursts.


So right now, it is Spring Break, and my goal is to have sphere to sphere and cube to cube collisions implemented by the time it is over (3/28). This leaves me with a little less than 5 days. I know that I can do this. Although I really got stuck this week and was at my wit's end, after speaking to Keenan, I realized that he was right. I do need to calm down and recognize that I already learned this stuff, and though I may not have applied all of it before, I am prepared to do so. 


After reading a ton of material on bounding volumes over the past several days, I finally got my bounding spheres to work last night. I used an older function that I had written in Physics class for creating a bounding sphere, and integrated this into my current code. Following this, I implemented frustum culling. At first, I was really confused about how to do this, but then Keenan reminded me about the camera lecture that we had where he had discussed point distance to plane determination, and this was really helpful. A lot of things came back to me when I watched this lecture. I realized that I already know and understand a lot of this, but I can't always pull it out of my head since there is so much. That is another skill that I need to improve upon: knowing when to apply what knowledge. 


I also implemented the drawing of glut wire spheres with the parameters of the forms' bounding spheres so that I can actually see the bounding volumes in debug mode. This is really helpful for determining what is happening, and is necessary for my collision tests. For the collisions, I plan to have the wire volumes to be green when they are not colliding, and turn blue when they are to indicate the collision. This also really cheered me up because I got to see my progress, literally. So far, I have the bounding spheres implemented for my cubes and pyramids.


Goals for Today/Tonight:

• Re-read orange collision book chapter 5 to refresh intersection tests
• Create progress video to show wire bounding spheres and discuss frustum culling
• Post video on the Wiki
• Give the sphere to sphere collision implementation a go

Coding and Recoding

For the past week, I have been struggling to get a grip on this project. Honestly, my biggest challenge right now is figuring out what exactly I need to do, and if I am doing it right. The past few days, I kept finding myself going back and forth, writing some code and realizing that it was not the structure that I wanted. It's really frustrating, putting in so much work and hours of energy every day, only to realize that I need to re write that code in some way to better suit my newfound purposes. I suppose that all is not lost though. On the bright side of this nerve-wrecking week, I am learning about what I need a lot more as my code evolves and my diagrams keep changing.


I've never worked on a project independently. I mean, I've done independent studies before, where all of the curriculum was spelled out for me with specific deadlines and precise instructions, and I've worked on projects by myself on a much smaller scale. I'm not used to this much freedom-- it scares me. I always wonder if I'm on the right track, if my ideas are stupid, if I should keep going with what I'm doing or stop and change track, or if I do change, I wonder if I shouldn't have done that. I keep doubting myself, and hounding myself, eating myself alive with worry. I really need to get over this and just get confident but I'm so stressed out thinking about the fact that it's already midterms and I'm not even halfway done. I know I can do this. I know that I'm more than capable. The biggest thing in my way is my own uncertainty. 


So, here's an update on what I've actually been doing for the past week:


I initially took a piece of Sample code from the 4th edition of the OpenGL Superbible titled "ccube.cpp", which draws a color mapped cube, and created a function called createCube() which encapsulated the OpenGL calls to create a cube into one space. In order to set the cube's vertices, rather than declaring 24 separate floats, I ported in my own Math library and set the vertices as vectors. Getting the setup to work took a full day alone. There were so many errors and linker problems, and I finally figured it out and could work on creating that cube function. 


I then realized that I would probably want to allow for various parameters beyond a default cube, such as vertices of a cube, and/or colors, so I added several more variations of the createCube() function. After doing this, I got stuck. I didn't know where to go from here. I decided that it might be smart to create the same sort of structure for triangles and spheres. However, there was a problem yet again. Creating a triangle and sphere required using the GLBatch class, which is not how I had implemented the createCube functions. Looking at the book's examples, I learned that calls on the batch object were necessary at various points in the code, not something that could be neatly enclosed in one function like I had done for the cube. This is when I came to the realization that I needed to adopt a different approach, and it has led me to the point where I am now.


On the train today, I mapped out a high level overview of what my code structure should look like. I left a lot of room for alterations, but I feel like this is a much better approach. Now, I am off to implement it. More to come soon.

The Beginning: A Box

So here I am, week 3 of school, work in full swing, and beginning my graduate research project. I must admit, the task at hand is more than a little bit daunting, but I will just take it one step at a time and hopefully exceed my own expectations by the time quarter's end comes around. 


My goal is to recreate the "falling chair demo" as shown here:
http://www.youtube.com/watch?v=tT81VPk_ukU 


only with different objects (I prefer sheep).  A paper was written by the creators of the demo, titled "BD-Tree: Output Sensitive Collision Detection for Reduced Deformable Models" (Doug L. James and Dinesh K. Pai, 2004).


My entire project is going to be based on this paper, with no previous code to work from. I'm going to start out with my own basic graphics engine and a gray-box demo that will eventually evolve into raining sheep! 


For those who are wondering what makes this collision demo so different from any other game or simulation collisions, typical bounding volumes aren't used. In fact, to put it simply, the chairs are filled with tiny little spheres that collide with one another, and this serves as the micro to macro collision testing that allows the chairs to "interact" so realistically. James and Pai really had a novel idea when they implemented this. Even though the demo exists already, recreating it with only one developer and having only the paper for reference to the actual project is going to be quite challenging.


I've been reading the OpenGL Superbible to prepare, as I'm a complete n00b when it comes to OpenGL. Besides having used it at a very high level in a game programming class last quarter (on top of an existing game engine), I have no experience with it at all. On the bright side, I do have some experience with the math behind graphics and physics under my belt. 


So, let's see how this goes. From 0 to rocket-sauce. 


Day 1: coding up some falling boxes... or, a falling box.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Later this day:


Well, I spent the next 2 hours after writing this reading and re-reading the paper by James and Pai. The first run through, I was baffled. Half of the jargon and mathematical symbols used in the first 4 pages are completely unfamiliar to me. After dedicating time to each specific segment though, I started to get a better grasp of the material. Obviously, I still have to keep reminding myself that the two people who wrote this are Professors in big universities, with numerous Ph'D's and extensive backgrounds in mathematics and graphics. The first "self-aware" conclusion that I came to was: do not try to become a mathematical scholar, graphics expert, and physicist all in one day. In fact, don't try to become them at all, unless that is your goal in life. Just learn what you need and apply it, one step at a time.


After making my own notes on the paper, I looked back on them and got this rush of "What if this is entirely gibberish and I really understand nothing at all? I'm going to be embarrassed to show this to Keenan", but after considering that for a second, I realized that if that is the case, at least I'll be told I'm wrong and know not to carry on in the same way. When you have nowhere to go but forward, you go forward. Now then, here is a condensed version of what I took from my reading:

The Wrapping Approach to Bounding Spheres and Building BD-Trees:

• You start out with a model. Say, a star. You then take the following 2 steps to create the BD-Tree (Bounding Deformation Tree) for that model:

1. "Build a hierarchy of the underlying geometry" (James, Pai, 2004). 

• To be honest, this is still somewhat confusing and something that I want to discuss with Keenan. The authors mention Quinlan's approach, which I will look into, so that I can at least imagine what the idea is here. 

1. "Build bounding spheres for the nodes" (James, Pai, 2004).

• This means that you start out with a "loose fitting" bounding sphere that contains a set of polygons with associated vertex points. We then generate descendant spheres that get progressively smaller and tighter to specific areas of the object's geometry. Unlike with the layering approach, where the hierarchy of bounding spheres is based on centering the spheres perfectly inside of their predecessors, the wrapping approach is truer to the shape of the underlying object, and much more localized. Here is an image taken directly from the paper by James and Pai that really helped me to understand this better:

Now, going back to what I mentioned all the way at the beginning of my post earlier today, I see that I was slightly wrong, or rather, incomplete with regards to my explanation as to what makes this a novel idea and different approach. It's not that general bounding spheres aren't used. Instead, they are used in combination with increasingly smaller bounding spheres, and all of these together are not necessarily positioned in a centralized manner. 

Now that I'm feeling slightly more competent when it comes to this, I am off to really program. More to come soon!