During the span of 5 days I was able to explore the technical challenges when it comes to developing the logic for tools in response to a problem set by my lead regarding the issue of adding joint placements in vehicles for passengers control for rigging.
Before delving into the project I had to manually place and adjust the position of the joints in Maya using the built assets used on the Fast and Furious 9 show to implement for about 16 background vehicles that’s supposed to have passengers in them for sequences that aren’t necessarily hero shots (main close-up shots). But through this repetitive effort it allowed me to figure out a pattern and solution to the task at hand.
Requirements
As the rampant amount of work required for specific shows has drastically increased, there is a desire to provide a way to build multiple variants of vehicle rig quickly and efficiently. Currently in development, there is the rig generator tool that can run this process.
One of the areas that require development is for placing joints for background seated passengers’ geometry caches inside a vehicle asset. Joints will need to be positioned based on the passenger seat assets of the vehicle which the naming convention should remain consistent in order to find and place the joints in the correct seat.
Specification
Tool: Rig generator
Feature: Joint placements for corresponding passengers inside the vehicle compound – list of guidelines
The rig generator tool is mainly used to build the first pass to create a rig procedurally by specifying the asset, type, and variant in order to find and run the script correctly. The feature that I was tasked to create
By running the rig_generator command on the Maya script editor, roughly 4-5 joints are to be placed based on the position of the right and left front passenger, and back seat assets. This will also send a version of the asset through the farm which will connect all the components of the vehicle rig together and publish the asset on the asset management system.
Design a solution
Prior to building this system, I have undergone the process of placing joints manually using the proprietary rigging tool in DNEG, Pinocchio, for multiple cars which became a repetitive process. I had also discussed with my supervisor as to what each joint names will be classified. This will help with how we map out the seats and to flag to modelling when they name assets to ensure consistency in order for the tool to work with any asset.
I broke down the necessary logic that would become a starting point as to how I could tackle the problem with my supervisor from my previous experience as mentioned above. Here is the breakdown that I came up with:
- Find seats
- Create mapping for passenger names
- Create module list loop to create control module
- Using mapping to find out where to place joints
Develop the tool
DAY 1:
This day mainly focused on outlining the logic and defining the main functions. As well as setting up my development environment from the rig generator repository that I have cloned to a new branch I have created for this particular feature.
Because the cloned repository had so many compounds (rules and list of guidelines) and features that have been inputted by other developers it felt overwhelming at first. It was important to follow the standard procedures and conventions when writing code in the version control context where other developers will have to read and review it. Breaking down into sections allowed me to focus on one function at a time which made it much easier to process each step. It was also a great template and guide whilst being able to structure my code in a manner that fits the DNEG standard.
I began by writing a seat mapping dictionary and creating a list that looks for assets that have a suffix ‘*_seat_grp’ for separate back seats and ‘*_seats_grp’ for joined back seating. Additionally, I had to add a warning command by looping through the seat mapping dictionary in case it errors if there are no items on the list with the exact suffix names.
I was still not used to the development cycle which is a procedure that required saving the code at a local environment and packaged and then running a cycle command in order to update the code and view the changes through Maya since it was my first time running the cycle. A time-saving tip that my supervisor gave me was creating a linux shortcut command (uprg’- for rig generator) that will run the development cycle without having to copy and paste or type the command into the command line. I also had to make sure that I needed to update and call the class in order to built the changes that I have made.
DAY 2:
Most of what I did this day was going through the Pinocchio API and understanding how the control module joints are built once the seats have been found in the loop. I also made sure that the attributes are called correctly when creating a new rig session. This was a lot more challenging for me since I haven’t exposed myself much on the Pinocchio API, so some of the terminologies and processes took longer to understand.
One of the ways for me to really figure out what was happening was updating and cycling through my code and adding print comments to exactly determine what was being called in order to manipulate the result of the data that has been accumulated.
DAY 3:
In order to get the seats to set the positions of the joints I had to iterate through the seats lists that I had created. Because it gets really hard to read off from a long list of items along with its attributes, I used the “\n” around the print statement to separate the strings of code into a different lines so that it’s easier to figure out what are stored inside the variable being looped.
I have also been developing a logic to position and place the joints. This entailed having to experiment using the “exactWorldBoundingBox” function in Maya if the seat happens to be the rear passenger seat. For the individual seating such as the two front passenger seat (or for back seats that remain individual) I used the result of the position using the “objectCenter” Maya command and used a transform function to position the translate values to the corresponding center position.
A lot of trial and error took place when figuring out the bounding box function. I did a few simple mathematical approaches mainly using the bounding box data to determine the midpoint of the three segments for the left, right and mid passenger seats. This was mainly through taking away the minimum value to the maximum value that calculates the length, width and height of the bounding box. Allowing me to manipulate and get the joints roughly in the right place.
DAY 4:
My supervisor unfortunately was away for the earlier half of the day so I ended up asking a lot of questions to one of my colleagues who had also worked with the rig generator before. Even though they weren’t able to help me with the specific problem, being able to pick their brain helped me also get a better sense of understanding with how joints connect to the interface which required delving deeper into the Pinocchio API.
What was challenging was understanding the interface of how the rig sessions are created by code. So I did more investigating within the rig_generator repository as well as the Pinocchio repository. But what helped was actually going through the existing rig publishes that have successfully have been sent to the farm and built. This made me notice the similarities and patterns that instinctively helped me get close to getting the connections corrected.
DAY 5:
One of the areas that I needed to account for in order for the script was changing the mapping key to a list to account for different naming conventions and so I used a list comprehension conditional statement that I previously learnt from my supervisor.
I was able to work out the error in the syntax in the build function which can now reference the right node and the right object within the rig module type. The relief I felt when I got it to work was one of the most rewarding feeling.
Verification
I was able to execute the code with the asset that was available during the testing and cycling of the package that happened throughout the development of the code. The vehicle asset had the backseat as a single piece of geometry. And so when I got to test it onto other assets that had separate backseats it had an error.
Review and refinements
I’ve learnt so much on how to write a more standardised shareable code that can easily be read by other members of the team. The importance of the git development procedures where cloning a branch not only grants you full access to the repository and all that has been pushed through by other developers working on the tool. But the branch that you’ve cloned is saved locally which does not jeopardise the stability of the code.
Once I have access to the shows and other multiple assets I will test my tool and that it can run with other types of assets. I also plan to push and commit it to the rig generator repository to get feedback and ideas from other peers.
ericka's blog 