Post-Production – Start (where everything breaks)

I checked my footage through and put together a cut of the project using my previz as reference for timings, I gave some shots a bit of leeway though as it its much easier to take away too much composited material than suddenly add some. I then converted each shot into DPX’s, including reference shots, and organised them all into a structure using the following format: Sxx_xx.####.dpx

This means everything will have the scene number and shot number labelled for easy tracking.

As I had already completed a successful test of the CG, I expected everything to be smooth sailing from here. My test shot was purposely more unstable to make sure that the more controlled shots would still be trackable, and everything appeared to be working, however something I did come across was when running the Maya project on the render farm, textures did not load correctly, locally it was fine, so I spent my time planning the production first, but knew I would have to come back to this issue. However, I didn’t anticipate that this would be a lesser worry.

When I loaded shot 5 of scene 1 into SynthEyes, I encountered numerous tracking markers. Despite performing clean-up and removing the window through rotoscoping, the shot still reported an error of 0.53, which fell well within the range of a good track, if not a great one. With the camera lens data set to 24mm, I anticipated no further issues. However, I would later discover that my strict adherence to a specific lens type for improved tracking would prove to be a frustrating setback.

However, since the numbers indicated that my track was accurate, I imported it into Nuke and then exported it to Maya to position the robots and scale them correctly using my reference images.

By utilizing the matte and chrome balls, I could verify that the HDRI was correctly rotated and functioning as intended in terms of directional lighting. It appeared to be working flawlessly, and everything seemed to be proceeding according to the plan until I submitted the scene to the render farm, which then uncovered some issues.

Contrary to how it was looking when rendered locally, the robots were without colour. Although as they seemed to have the correct reflectivity, the material was being applied, which suggested to me there was an issue with texture images specifically.

But before I could come up with a solution to that, I noticed another issue, the robots appeared to be sliding in the scene, and not a small amount.

I tried fixing this via a 2D transformation by measuring the difference between the movement of the feet of the robot and the tracking markers in the live action scene. This, however, proved to be futile as what could work for one robot, didn’t work for the other, and whilst I could improve things, it wasn’t enough to meet the quality I was after.

I persevered through several additional solves, encountering the same issue regardless of the error value in SynthEyes. I examined the camera exports in Maya to check for any problems but couldn’t determine the cause of the issue. Frustrated, I decided to set it aside for the time being and address the problem of the robot textures not appearing when rendered through the farm.

Upon reviewing the render farm logs, I identified that the issue was related to the material’s texture file path. If the texture was not located within the designated Maya project, it caused a problem. This may seem obvious, but because the .fbx files of the robots were in the correct location, I assumed the textures were being referenced correctly. However, due to the original creators’ setup of the robots, I still needed to reestablish the pathway for the render farm to recognize the textures as “local” to the project.

With that solved, I also had an epiphany on what was causing the sliding issues in the SynthEyes track. It confused me why there was such trouble considering, on paper, this was a super easy track, lots of detail, fairly slow movement, even the lens was constant as it was a prime. And that’s what made me think, I have had shots like this before and it has worked, but I haven’t known the lens type, if that’s the only difference, then maybe that’s the issue here.

And it was, because even in the Nuke tracker, if I just set the lens type to an estimate rather than known, the track was perfect. An odd issue that took too long to resolve, but means I know how to handle all future 3D solves that run into the issue of this same sliding whilst having a low error.