Lab 1 Files
First Open Source Contribution Project
My itch comes in several flavors: cluster computing, scientific computing, game development, and graphics algorithms. In a fashion, this /wiki/index.php/Project_List"> project list sums up my interests.
The work I have participated in our cluster computing group has been great opportunity for me to explore my interests in both cluster computing and scientific computation. The variety of challenges and new things to learn has kept my fondness for these itches growing.
I've started a game development group on campus after doing several semesters of independent research on game development. Right now, this itch takes the form of writing open source, cross platform games while organizing and leading a group of enthusiastic individuals. As a person with a wide range of interests, the many different aspects of game design and development keeps me very engaged.
My newest itch is that of photo realistic rendering algorithms, especially those dealing with the physical modeling of light. Right now, I'm learning as much as I can about using photon mapping to render light conditions that are hard with current rendering technologies like ray tracing. It's a rich problem set that has a lot of room to explore and create new techniques.
My favorite programming language is the one that brings the most benefit to the task at hand. I see programming languages as a means to an end; they are tools that bring a different set of both useful and detrimental attributes to a project. Basically this boils down to me being unable to decide which is better: my hammer or my screwdriver. If forced to answer this question in a concrete way, I would have to go with C/C++ because of my familiarity with them.
Bad coding style hurt my first attempt at learning the OpenGL API. Obfuscated and poorly commented sample code made learning the API a harrowing experience. Good coding style (and good amounts of code review and cleanup) was very useful personally when working on the Folding@Clusters project. The code, the various library/API calls, and the interaction between all the software involved were all complex and good coding style was a definite aid in sorting everything out.
I interpret clarity as the quality of software to be as easy to understand as possible for anyone at any point in the software's life. Simplicity is having the complexity of the project match as closely to set criteria as possible while meeting them. Generality is the quality of being able to handle a maximum of possible input cases and circumstances. Automation is the ability of various aspects of a software engineering project to function with as little human interaction as possible. The overlap between these four concepts is as large as the synergy between them. Having a good measure of each would make a project run much more smoothly.
What would the impact of licensing software engineers have on open source projects?
Do the ideologies underlying open source software keep the usage of it mitigated to marginal set of roles? Are these ideologies different enough from the majoral, commerical, corporate software mindset that the more market share OSS gets the more resistance there is to using it?
As I am currently managing an open source software project with the game development group, my proposed contributions to the graphics engine are as follows:
With Regards to Bugzilla
My server seems to be having some issue with the perl modules involved in installing bugzilla. I need to discuss using cs.earlham.edu for bugzilla wit an admin. This needs to happen soon for the project's sake; the forum and mailing list are not places to be bug tracking.
Fix Analysis
Writing a k-d tree implementation to work with the new project from Habitus Games was the goal of this foray into contributing to an open source project. This feature addition will be used to make nearest neighbor and range searches in 3d space more efficient. This will come into play primarily in viewing volume culling and collision detection.
Features include sorting each spatial partition of the tree via shell sort. This was chosen as a trade off between the complexity of coding versus performance. Another fun detail to note is that this data structure's swap is all pointer manipulation, which means a comparision is approximately as costly as a swap. This influenced the choice of using the Sedgewick h-series. Generally, the Pratt h-series is considered more efficient because of it has the lowest number of value exchanges of the commonly used h-series. I chose Sedgewick over Pratt because the number of number of lookups plus the number of exchanges is relatively low.
As this was adding a feature to an existing project, chances are that I produced a number of bugs. I plan on clearing up many of these possible bugs in the near future. Additionally, I will put this project into bugzilla within the next couple of days.
Note that some test and debugging code has been left in the k-d tree implementation code as there are still some bugs to correct.