1. Tornado Alley:

2. Parametric Shapes (based off these shapes: http://en.wikipedia.org/wiki/Parametric_equation#/media/File:Param_03.jpg)

Thought Process:

After reviewing the syntax and the going through the examples on the blog, I experimented with slight variations on the existing examples to get a feel for how Madeup worked under the hood. I played around with the tools provided, but I never really had a clear vision of what I wanted to make until I looked at some examples of parametric functions online. Once I found a few I liked, all I needed to do was break up the syntax and move my madeup cursor to each (x,y) position. Before I was uncertain how “moveto” differentiated itself from the translate function, but now I can see that Madeup offers a much deeper learning experienced than I initially bargained for.

Hurdles:

Many of the challenges I experienced working with Madeup involved some difficulty translating some of the more complex math equations into madeup friendly syntax. With my “Parametric Shapes” model above, I found it rather difficult to get the bracing to line up just right without messing up the x,y coordinate pairs. Overall, I learned that  you can never have too few parentheses. The other issue  came when I attempted to execute my models when I had named variables with an underscore (‘_’). It seemed that the compiler would come to a halt when it came across a variable with these characters and I had to remove them altogether to get results.  The last challenge, came from the uncertainty of how many shapes could madeup process at any given time. Sometimes I could render 2-3 shapes, but when I scaled them up or added more copies, I could only get the wire frame to appear.

Bugs:

1. This wasn’t so much the code behind madeup, but rather the graphical interface itself that had some technical hiccups. When I was playing around with the screen size I found that sometimes I would get a blank screen that would either flash or stay altogether.

2. I couldn’t tell if this was a result of me passing in the wrong parameter values but I managed to get a “core dumped” error message when running the bottom example. If it’s a parameter error, then maybe a helpful error message would do the trick.

Feature Requests:

1. I’m a fan of print  outs and custom debug messages. Would it be possible to include a print format option much like in C/C++? I had a difficult time printing multiple values on a single line at a time.
2. I think it would be nice to have the ability to save newly created shape functions so that users to reuse their favorites without digging around for the code to get them working again. Maybe, even have a custom “My Shapes” tab.
3. I don’t know how difficult it would be to allow for multiple colors on a single shape, but if their was some sort of “pixel color” option to control the rgb values at each point(s), I think it would help Madeup take it’s next creative leap.
4. I think having either a Madeup import/export option would be very cool. I’d like to see the shapes created in Madeup make their way into some of the OpenGL code we’ve been writing this semester.

Theme:

Since I was going to get knee-deep in blender, I wanted to create objects that were simple enough and unique enough to keep me interested in fine-tuning the littlest details. I decided on a making references to my favorite PlayStation One game: Crash Bandicoot (known for its many crates), and one of my favorite TV Shows: Doctor Who. Jupiter has no special significance other than its Jupiter and it’s been around for billions of years.

Thought Process:

When I started this assignment I spent the vast majority of my time learning how to use blender modeling tools, uv mapping, and creating custom objects. Once the objects were ready to be shipped off to the actual program I needed to think about how I would place them all in a single scene. One by one, I tweaked the transformations to either flip or rotate to account for the positioning blender provided after exporting the objects. When I finally had the objects I needed in place, I had some fun with multiplying some of the crates as well as as making objects fly around the  scene. The picture doesn’t do it justice, but in real-time the space floor, jupiter, the crystal, and the TARDIS are all rotating with their own custom transformations.

Hurdles:

The most challenging aspect of this assignment was settling on designs to create in blender that would be feasible to work with in the actual code. A few times I had to scrap some designs and start over with a simpler model in order to render them correctly in my scene. On top of this, when the objects I wanted were ready, trying to get the uv texture coordinates to unwrap nicely was another headache.  For trickier objects like the TARDIS, I ended up unwrapping it first, taking a screenshot of uv image in blender based on where each face expected to have a texture mapped to it, and then finally make the image in GIMP according to those outlines. The next hurdle was texture mapping in the code. At first I attempted to use the same texture variable and simply bind/unbind with different texture uploads but that ended up applying similar textures to multiple objects. The other longstanding issue was the inability to read texture coordinates from the .obj file which resulted in hard coding values until the issue was resolved by replacing “/”‘s with “//”‘s in each file.

Thought process:

After translating the pseudo-code, the first thing I needed to do was figure out the relationship between the positions and faces of the magnets. I started off drawing the vertices, calculating the positions of the corners, and then labeling them in a counterclockwise manner to account for the face indices. Once I shipped it off to the graphics card the next thing to do was to draw them. To draw both magnets I needed to first draw it’s components in reverse order starting with poles and then the magnet body. When I needed to account for flipping all I needed to do was negate the translation values. Once I had the magnets drawn, I needed to implement the mouse events that detected, moved, flipped, and interacted with the magnets.  To do so I needed to find a pattern between shifting each magnet based on the current click. In the end it came down to basic math with displacement and re-centering each magnet.

Hurdles:

At first I had tried to duplicate the amount of positions to represent each magnet, but when I managed to draw the individual components of a magnet I realized that I had extraneous position data that could be cleaned up. When I was adapting the pseudo-code I had a hard time translating some of the conditionals and the basic vector operations. My solution, although it adds a few lines of code, breaks the pseudo-code into smaller chunks for ease of use. As I was working with the struct, I was increasingly disliking the way I was referencing it and its values so I decided to switch it over to a pointer to a struct of magnets. While the syntax was cleaner, it was a little tricky initializing the values and updating the project. Another issue was my lack of understanding of how to convert back and forth between pixel coordinates and openGL’s expected coordinates. However, once I implemented orthographic projection, the logic behind interacting with the magnets “clicked” (pardon the pun).

Thought Process:

My thought process with this assignment was to first start figuring out how the indexing of the RGB channels worked and what a Gaussian Bump meant in this context. I then needed to figure out how to structure this in relation to the PPM file format. After writing the  Image class components and trying to grapple with the main method, I decided that to best represent a Gaussian Bump as its own object with bells and whistles to call its own. From here I was able to abstract away some of the overhead and I could write the remaining functionality to generate bumps, calculate energies, and so on. Once I was content, all I needed to do was clean up the code, define some helper methods, and make pretty colors by normalizing based on rows and columns.

Challenges:

One tricky part of this assignment came with managing the loops and indexing used to keep track of a particular pixel’s energy. Treating a 1-D array as a 2-D array and mapping energies and colors was a little difficult to wrap my head around, but it was the best design choice.   Another component that gave me some grief was the console interaction I added towards the end. At the time I was unaware that I was reusing some leftover macros which caused inconsistent memory access and/or PPM files with missing chunks from a Gaussian bump.