Journal

First Week, 6/14-6/18:

Second Week, 6/21-6/25:

• The motion capture lab area consists of 12 Vicon infrared cameras positioned to face the area assigned for motion capture purposes. In addition to these cameras, the motion capture system is based on the Vicon 512, a professional motion capture system. These pieces of equipment are quite costly; Each camera costs around $12,000, and the Vicon 512 alone costs approximately $100,000!

• The motion capture area must be clear of objects or that give off reflected light, such as metal surfaces or even stools that give off reflected light on the seat surface. Many things have to be calibrated before the motion capture can actually take place: The area of motion capture must be calibrated for the system to take input, and the subject of motion capture must be calibrated into the system, first so that the system knows where the markers are on the subject, then another calibration takes place so the system can get a feel of how the subject's body parts move for better accuracy.

• The person used for motion capture is covered with 41 markers in specific regions of the body for better motion capture output. When the actual motion capture takes place, the subject for motion capture must be careful not to cover the markers on their body, otherwise the motion capture equipment will not obtain any data for specific parts of the body that are marked by the covered reflectors.

Third Week, 6/28-7/2:

This week the Motion Capture lab had asked me to help participate in a sample motion capture session. What's exciting about this opportunity is that they need me to assist as a test subject for different motion capture sequences. I had to put on a motion capture suit, which was actually a black tight-fitted athletic suit. The suit had to be skin tight because the motion capture system does better when you don't wear baggy clothes, and the general structure of your body is exposed to the system's cameras. Moshe, the motion capture specialist, assisted me with putting special mocap markers in certain places on the suit I was wearing. These velcro-like markers are covered with special tape that give off light, so that the infrared cameras would be able to absorb this light, thereby taking in the positions of each and every marker. I did a number of motion capture sequences, involving positioning my body to do general everyday actions (i.e. shooting a gun, pouring from a pitcher). I've provided two examples of my motion capture exercises below:

Note: These are Real Player Video Files. Click the bottom link if you need to get Realplayer:

To download the Realplayer for Linux, click here

Click on images for movie viewing:

Regarding my project, I have created a MEL (Maya Embedded Language) script involving two directional lights from specific cameras to reflect not general light, but two different textures. The initial examples I used were a crater-like texture on the left side, and a green cartoon shader texture on the right side. The smaller sphere (in the picture examples shown below) is supposed to solely reflect the texture that is cast at a specific region of the sphere that it is positioned at, however, the lights defined are not working perfectly. I might have to modify the positioning of the lights in the MEL script to achieve the desired restriction of the lights in their respective regions. Below are sample trial runs of my plugin, with the rendered examples on the left, and the snapshot of each rendered examples editing environment within Maya on the right, respectively.

Fourth Week, 7/5-7/9:

This week I had to make some major changes to the MEL script that I'm implementing for this plugin. I've met with Jessica and James (my advisors on the project), and they've told me that while I do have progress, the implementation is not what they wanted. What is needed is for the shading of a particular object to be surfaced based, instead of based on the direction of light. My initial work focus was actually based on the desired implementation, but being that I'm still learning Maya, I didn't think that it would be possible within a short period of time, being that Maya is so complex, however, this method is possible if one thinks of the objects that create a polygon.

Vertices, Faces, UVs, and Edges:

The components listed above are all that of a polygon's internal structure, and is the basis of any kind of manipulation of a polygonal object. For my algorithm, I have to concentrate on the faces of a sphere, and the shaders/textures applied to it at a particular point. I have added in a general attribute slider to the plugin, allowing translation of the smaller sphere to different sides of the larger sphere (via the x-axis) to show change in the surface shader/texture. Upon each translation about the x-axis, the algorithm checks each face of the smaller sphere, to determine the side of the sphere that each face is on. Depending on the side of a particular face, it will recieve coloring based on the side of the sphere it's on. This allows coloring of specific parts of the sphere with respect to a region.

At first, I thought that this was a remedial way of actually writing the algorithm, but have found that the results of this method could be quite rewarding, based upon the number of faces you define for the sphere created. The higher the subdivisions of a sphere, the more detail you can have for transitional shader change as the smaller sphere translates about the x-axis.

Fifth Week, 7/12-7/16:

Changing implementations of my previous work required me to learn how to use the capabilities of Maya and the C++ API combined. The number of functions and classes already included in Maya seem endless. In my previous implementation, I mainly used the graphical user interface of maya to implement many actions to make the desirable lighting and shading, but now I must use C++ to specify exactly what location and procedure I need to be performed on a particular polygonal face. I've also had to change my editing interface from the simple Windows based Notepad editor to a more advanced editor called Emacs via Cygwin, which is a Linux-based environment that is run under Windows. Right now I'm also using Microsoft Visual Studio 2003.NET to try out the Maya Plugin Wizard. This is supposed to make the compilations easier to perform under Maya, instead of having to use Emacs and manually integrate Maya into the Cygwin system and having to declare environment variables.

The Carnegie-Mellon Graphics Lab is amazing! Because of my passion for graphics, I've researched most of the popular graphics-based books in print, and surprisingly enough I've found most of my favorites in Jessica's lab. Titles that I never thought I would be able to glance through are now within my reach. During breaks I'll often glance through the library within the lab, and check out the titles, as well as software they have available to help with graphics modeling. They have titles based on many popular software companies (i.e. Macromedia, Adobe) and the most popular languages (i.e. C++, Java, JavaScript, ActionScript, HTML, etc). Plus, they have many books on advanced math, since this is the basis of the graphics realm.

Sixth Week, 7/19-7/23:

This week when I met Jessica, I had discussed with her my use of the C++ API. Jessica said that using the API wasn't specifically necessary, and that using strictly MEL script was fine for our implementation. I thought that using the API would give me more flexibility for this plugin, but after some modifications to my MEL script, I was getting desired results. Again using the idea of shading a sphere, each face on the smaller sphere was shaded according to which side of the bigger sphere it was on. For each face, if a face is positioned on the equator (which is determined by the color separation of the bigger sphere), if the number of the face's vertices on one side of the equator exceeds the number on the other side of the equator, the face is then shaded in the region that contains the majority of face vertices. The pictures below show the results obtained for this week. The only setback to this implementation was that certain faces weren't shaded because half of the vertices were on one side of the equator, and the other half were on the opposite side of the equator, and since the majority of vertices are not on a particular side of the equator in this case, the shading algorithm will not apply any specific shader to the face examined.

Seventh Week, 7/26-7/30:

This week when I met with both professors, Professor James Duesing let me know that the test implementation we were working on was only a step to the true configuration he wanted for the plugin. In my present implementation, the smaller sphere in the scene was shaded according to it's position with respect to the equator of the larger sphere (defined by the color separation on the larger sphere). However, the desired implementation was for an entire scene to be shaded according to the position of a plane, not a sphere object. In the previous implementation, the object to be shaded was moved, and it was shaded according to it's position aligned with another object that had no translation, but controlled the shading of the scene. However, the desired implementation requires the object that controls the shading of the scene to have movement, and the other objects in the scene to be still for analyzation. With every move of the object that controls the shading, the algorithm will shade the still objects according to the new position of that object. It seems to be the opposite of the previous implementation: Instead of the object that controls the shading being still, it is actually the object that does the movement in the scene, and shades at the same time. Professor Jessica Hodgins said that this should be just a code change of my present implementation, switching roles of the still object and the moving object. With this implementation however, a plane will be used as the controlled polygonal shading object, and different types of polygonal objects will be used for analyzation.

Eighth Week, 8/2-8/06:

After changing around the implementation, the results were quite satisfactory. I was requested to create a movie showing results of the plane moving about the scene, and shading the objects within the scene. Below is a movie showing the MEL script at work. The movie below shows an example of shading different objects in a scene, using two different shaders on one surface. It was requested that I use a photorealistic 3D shader, and also a non-photorealistic 2D shader, to show the difference of using both at the same time on one surface. I used a plugin called the TomCat Cartoon Shader Maya Plugin. This allows the creation of non-photorealistic shaders for use on Maya objects. As I stated in last week's entry, since I changed around the implementation by switching the roles of the still objects and the color controlling object (in this case the plane in a scene), certain faces on a polygonal object would still not be shaded because the face vertices would be split equally on both sides of the plane. Professor Jessica Hodgins had recommended that my next step would be to create a shader that would serve as a fill in area for the faces that were not shaded by the algorithm. This shader would average whatever shaders were used to shade different parts of the scene. This is my next focus for the future implementation.

Note: These are Real Player Video Files. Click the bottom link if you need to get Realplayer:

To download the Realplayer for Linux, click here

Click on images for movie viewing:

Tenth Week, 8/16-8/20:

This is the last week of my summer internship at Carnegie Mellon. This week I've made some updates to my MEL script. It turns out that in order to create a layered shader with other shaders as input to be layered, I had to duplicate the input shaders and use the duplicates instead of the originals as input to the layered shader, so that the original's input properties would not be altered. I created an interface that allowed the user to personalize the MEL script execution by giving as input the shaders used for the shading of the scene, the shader used as a filler for the boundary area, the name of the plane used to separate different parts of the scene, and the folder location they would like output to be placed.

I've provided a movie below that shows a previous test with final rendering with higher resolution:

Note: These are Real Player Video Files. Click the bottom link if you need to get Realplayer:

To download the Realplayer for Linux, click here

Click on images for movie viewing: