teaching machines

FISHERR – Magnets

March 18, 2015 by . Filed under cs455, postmortems, spring 2015.

fisherr_magnet2fisherr_magnet3fisherr_magnet4fisherr_magnet5

For the magnet’s homework, my thought process was as follows:

  1. Designing C++ Classes:  The two classes included a MagnetRenderer and a Magnet.cpp file to provide the struct implementation and methods.  I needed to break down the Magnet pseudocode and translate to C++.  For the renderer class, I needed to design how the OnDraw method would render two distinct magnets with mouse interaction.
  2. Research:   Since this was using OpenGL, I needed to do more research to understand how the geometry would be reused and how the magnets in the world should be rendered based on the translations and scaling matrices.
  3. Analysis:  I observed the various effects and expected results of two magnets on the screen. The pseudocode for the magnet worked well but I needed to write out the expected values on paper to ensure I understood the process and logic.
  4. Debugging/Testing:   In this step, I spent the most of my time re-evaluating the psudeocode and output for the magnet’s interaction. It wasn’t until I got a better feel for the projection matrix did everything fall into place for the simulation.  Adding lots of “#ifdef DEBUG” preprocessor calls made testing a little more simpler.
  5. Documentation: Providing user-friendly comments to make sure each class and method steps were clearly organized and easy to understand.
  6. Ask questions and Turn in before spring break!

Challenges:

1. Magnet Struct: I am used to writing pure C++ classes, but I decided to use a struct to model my magnet. I had some issues with construction and  pointers and not modifying values.  I overcame this by doing some further review of structs and debugging their values when needed.

2. OnDraw(): Initially, I was very confused about how the shader program will render more than one object (and with different colors) . I thought I could use more than one shader program and link that to the method, but knowing that I had to use one vertex array object, it made it difficult.  I overcame this issue, but asking questions and “drawing” out how one rectangle can be simply modified for the whole program via matrices, uniforms, and attributes. I now appreciate the power of saving/reusing geometry to populate the world.

3. World Coordinates: The final challenge was understanding how to map the pixel coordinates and the default world coordinates together. This caused me to go way off track and get bogged down by converting between the two. But with a orthographic projection  matrix, the world coordinates and magnet implementation made more sense as a whole.

4. Vector3: The Vector3 Class that I had designed earlier this semester was giving me issues with any sort of operator (+,-,*,/). I’m not sure why, but the same methods in a Vector4 seemed to work just fine. I will have to look into this to ensure that Vector3 works as expected for its functions. So for some situations, I had to do the arithmetic operations in a longer /alternative way.