Butterflies

The first model I “Madeup” was a scene of blue butterflies. I used a parametric equation for the butterflies and populated the scene with many of them.

Hearts

The second model I “Madeup” was a variation on the “heart” parametric equation. I designed the loop for generating the curve, and did some revolutions, translation, rotations, and scaling to create the heart-based shapes.

Thought Process:

For this assignment, I initially began testing the application by running old examples to get a feel for the way the code runs.  I tested trying out a variety of options for generating shapes, but I eventually decided that I wanted a more systematic and logical model. I researched parametric equations and was able to understand how to implement them via loops and sine/cosine functions.  The parametric equations made sense to use in Madeup and allowed for a straightforward design and implementation. Without such equations, the logic of designing a model by random tweaking is quite difficult.

Challenges:

There was a slight learning curve with Madeup since I had used it personally. It can still be a challenge to understand how the parameters are used in functions. One challenge that I came across was trying to visualize the model for non-parametric models. As logical as the program is, creativity is needed to understand how the models will be rendered.  I overcame this challenge by playing with different functions and seeing what the result was.  Lastly, there was some issues with rendering the program for code that uses a lot of processing power. I had to cut back on code in order to save computational resources, so I think there is a need to understand the stress limits of what the program is designed for.

 Feature Requests:

1. Be able to save/export the code to a text file or a “.mdup” file.
2. Be able to render models using more than one color in a single program
3. Possibly be able to inspect the model for coordinates. For example, being able to toggle displaying a 3D grid with units.
4. Display more helpful messages if there is a syntax error, at least if it is not running at all.
5. Display statistics for the shapes that are used like faces and vertices.

Bugs:

1. Underscores are unable to be be parsed by the language. For example, I could not declare a variable with “x_1” or “y_2” since the program would not run.
2. At one time I got this error:# A fatal error has been detected by the Java Runtime Environment:# SIGSEGV (0xb) at pc=0x00007facede165f0, pid=16185, tid=140380725032704# JRE version: 6.0_27-b27# Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode linux-amd64 compressed oops)

   # Derivative: IcedTea6 1.12.6

   # Distribution: Ubuntu 12.04 LTS, package 6b27-1.12.6-1ubuntu0.12.04.4

   # Problematic frame:

   # V [libjvm.so+0x3ef5f0] DictionaryEntry::contains_protection_domain(oopDesc*) const+0x40

   # An error report file with more information is saved as:

   # /tmp/hs_err_pid16185.log

   # If you would like to submit a bug report, please include

   # instructions how to reproduce the bug and visit:

   # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/

   Aborted (core dumped)

3.  Another error I got was:

terminate called after throwing an instance of ‘std::bad_alloc’

what(): std::bad_alloc

Aborted (core dumped)

which I don’t know if this was a problem with the code I used or something in the Madeup program with using too much memory.

1. Rubiks Cube

2. Captain America Shield

3. Pyramids (with perspective)

4. Sapphire (textured and non-textured)

5. Desert Floor

6. Sun (non-textured, and textured)

For the sceen homework, my thought process was as follows:

1. Designing C++ Classes:  Since there was only one SceenRenderer, the class design was straightforward. There was a lot of reusable code to make my scene come together.
2. Research:   I did more investigation in how texture coordinates are used from .obj files and I also did some tutorials for Blender modeling for UV mapping.  The learning curve was sharp at first, but I did get a better handle on modeling and I wish I had more time to make more complex objects.
3. Analysis: Aside from understanding how the various matrix transformations are integrated with each object in the scene.
4. Debugging/Testing:   There was a lot of trial and error with trying to get the objects to render with their textures. In some ways I felt like my logic was in control, but other times I cannot explain why a texture would refuse to load for a shader program.  Testing the application involved lots of minor tweaks to try to get models in the right space.
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 learn!

Challenges:

1. UV Mapping: This was one of the most time consuming task since UV mapping with texture coordinates seemed way to hard to calculate by hand. Once I discovered that I could export the UV texture coordinates and they could be read with the ObjectUtilities class, my progress accelerated.  There was a weird bug with the reading of the .obj file that prevented texture coordinates from being parsed correctly. I had to modify the exported .obj file with // for the texture coordinates and that solved the issue. Thanks again to Dr. Johnson for taking some time to look at the code!

2. Shader Programs:  Initially, I was still lacking in understanding how the lighting system would work with texture coordinates, but since the vertex and fragment shaders are so reusable, I could make minor tweaks for many shader programs given the object.  I’ve had some issues with shader programs, too. I tried to render 3 gems, (a sapphire, ruby, and an emerald), but only the sapphire was rendered with the correct texture. The others refused to render with their textures. Even weirder, when I textured the sun seen above, the sapphire would lose its texture.  I spent a long time trying to debug this problem, but I couldn’t resolve it.  So, I was left with the minimum number of objects to texture for the assignment.

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.

(The images above were generated with different dimensions, RGB color channels, and variances.)

For the Gaussian Pox homework, my thought process was as follows:

1. Designing C++ Classes:  I had to carefully identify the necessary variables,methods, and logic, that would make the Image, Bump, and GaussianPox classes coordinate together.
2. Research: how to write to a PPM file, understanding the 2D Gaussian energy function, and how the pixels will be used in memory and accessing them. Taking notes…
3. Analysis:  In this step, I observed different outcomes from generating Gaussian Pox.  I needed to be able to break down the logic and see how each pixel will be affected through the pipeline of  functions and methods it goes through.
4. Debugging/Testing:  In this phase, I tested tweaking various user inputs and variables for generating Gaussian Pox (I have also provided a more I/O feature to the program for certain variables)
5. Documentation: Providing user-friendly comments to make sure each class and method steps were clearly organized and easy to understand.
6. Being Creative!

Challenges:

1. Gaussian Energy Function: This was a hurdle since it was difficult to understand how the energies will be combined with the RGB channels.  Testing and making observations on the data made this relationship clearer.
2. Writing to the PPM file: For several attempts, the Gaussian Pox on the image was clearly separated and the pixels did not have the expected intensities.   I overcame this obstacle by understanding more deeply about how the file is written and how the channels are affected by the bumps’ energies.