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!