Research and Tech


May 05th 2022-

And the streak for more Python Script continues. I probably want to dive more into Technical Art if I can, so I will be putting out more Python Scripts if possible. This time, I created a basic tween controller for animation, using the basic tween command in Maya. I didn’t know that Maya has an auto-tween command. The more you know I suppose!


May 04th 2022-

Another Python Script being created. This time I created a basic Procedural Gear Creator that allows to modify the teeth of the Gear. Its simple but, definitely can use more edits in components(length, radius.. etc.) Here is a quick Video Demonstration –


March 21st 2022-

Something new to try this week. I have been dabbling in C++ and learning OpenGL. I was able to build a simple OpenGL renderer with a simple window viewport. I am currently using the old way to import 3D models(Using a JSON library) instead of going the more modern approach of Assimp. I probably will re-write this after getting up to date on the other GL mechanics.

Here is a quick demonstration of the window. It currently imports 3D Models with its Base Color, Specular and Normal Maps and the window has inbuilt area lighting. The window also has the option for navigation: Using the WASD keys for movement along with camera rotation using the mouse.


March 14th 2022-

He-yo! So I am one of the biggest fans of the Dark Souls/Fromsoftware franchise and I just love those games to the death. Once again as I was scouring on the internet for new things to dabble in, I was introduced to the Pygame! Pygame is a game library for Python that allows game creation within Python. It is limited in the sense, that it cant really create projects that you would see using Unreal/Unity but its super handy in making 2D sprite games. So after dabbling and learning the library, I was able to create the basic engine in Python that made a game which shares a lot of similarities with the Dark Souls franchise. Here is a quick playthrough of it:

The sprites/characters/animations is from Pixel Boy and I basically used Photoshop to customize the sprites to work within the engine. Its a super simple engine: it basically runs the code, calls the sprites upon interaction and updates the Game UI accordingly. Some of the features that are currently in the game include-

  1. Five different weapons and two different magic spells. Two different styles of combat
  2. Four different types of enemies, including a special boss class enemy.
  3. Varied Regions on the map for more immersiveness
  4. Upgrade system that focuses on different attributes. You are basically given the option to create your own build.

Moving ahead, I definitely want to make a timer which basically forces the player to kill all the enemies on the map within the time limit. This is because the game is currently still in its infancy period and is currently a development period of testing various possibilities. The ultimate end goal would be to create a thematic game of an initial story that leads to a quest within the first area of the game, and then fighting the boss of the first area. A la Dark Souls style!


Jan 28th, 2022-

Its been two years since I first got an exposure of MEL and Python Development within Maya. A lot of technical work is involved within rigging and its repetitive/mechanical procedure. I wanted to dive into some MEL scripting and basically scourged the net for some good examples of pure MEL scripts. I found some headway on joint splitting scripts and ways to achieve it. The standard way in Maya is to simply use the ‘Joint tool’ and insert a joint in between two joints that is selected. The problem is that you cannot automate the amount of joints you want to insert or the position of the joints you insert. So again, you are basically allowing human inefficiency to creep in. I was able to learn some MEL scripting and using an old script from 2005 as headway, I was able to dabble into some MEL and write a Joint Split script. It has four basic functions-

1)Above is a simple two joint setup that is being split by one joint.

2) The same function as above, but with a possibility of creating independent joints. Especially useful if you are creating free joints.

3) You can also create multiple split joints.

4) And you can also adjust the position of the split joints. This is useful as well when you want custom joint locations in a more artistic capability or even as a support joint. The default position of the split joints is equally split depending on the number of split joints.

So overall a cool script to work with. I probably will want to re-do though with a more PyMel approach. MEL while being useful, certainly has its limitations and having a more OOP language like Python would make things easier, especially with creating proxy locators for the split joints. Well until next time then…


January 05th, 2022-

To me, one of the most interesting fields of Computer Graphics Research is rendering. I guess I just am fascinated by the way pixels are calculated to create beautiful images whether in simple 2D work or high-end VFX works. Coming from a love for mathematics, I guess the mathematical theorems associated with rendering have always captured my attention with their complexity yet simple execution. This is among other reasons as to why I wanted to focus on rendering during a research internship I had at the Drexel Undergraduate Graphics Lab.

While I have always appreciated the realism that modern rendering techniques bring, as an anime and non-traditional artist, I have always been drawn towards rendering solutions are non-photorealistic and real-time rendering was a field that I was deeply interested by.  Traditionally, real-time rendering has been the standard go-to solution for games, due to the nature of game engines requiring so. However, real-time rendering has been increasing in demand due to its potential for the pre-visualization aspect of the pipeline. It also seems that the possibilities of non-photorealism increases with the path of real-time rendering. Perhaps it is the fact that real-time rendering is not 100% accurate itself and is thus easier to manipulate to create non-photorealistic illustrations. I personally observed this phenomenon by looking at two new major developments that came into the industry around the year 2019: As an intern at a VFX studio, I was involved in the CG departments procedure of implementing the Unreal Engine 4 into their pre-visualization pipeline. It was here where I first saw the blistering speed of real-time rendering over the usual modes of rendering at the studio. At the same time, Blender released its EEVEE renderer which is in my opinion, one of the most forefront render solutions for NPR projects.

Thus, I decided to conduct a basic investigation into the speed of real-time renderers versus the more common renderers that we usually see in the industry, on attributes of rendering such as SSS, Volumetric and etc. I used three renderers for this investigation- Cycles, EEVEE and Arnold. In retrospect, I probably would also include a hybrid renderer such as VRAY. Regardless, the results were interesting and are displayed in the investigation image above. For a more clearer version, here is the official PDF version-

I was fortunate to finish this scientific poster and be able to present my findings at three research conferences last year-

  1. Harvard Undergraduate Research Conference(February 2021)
  2. National Conference for Undergraduate Research(March 2021)
  3. Drexel Week of Excellence: Undergraduate Research(May 2021)

For the future scope of this research, I definitely would want to be able to condense my findings into a more official format as a paper, while also condensing other forms of rendering techniques and parameters.