Several interacting issues. 1. There was a discrepancy in Arnold behavior across versions. Certain builds interpreted light-set relationships differently, sometimes including lights in layers even without explicit connections. 2. Linux and Windows builds did not behave identically under the same scene conditions. 3. Enabling “Merge AOVs” introduced additional inconsistencies in how outputs were written and combined during batch rendering. So what looked like a lighting problem was actually a multi-layered interaction between software versioning, render-layer evaluation, and output handling.

Behind EVERY render, a SUPPORT TEAM that NEVER lets go!

Q: This sounds like it required more than standard troubleshooting.

Yes - Engineering went beyond support. We stabilized the environment to match the studio’s Maya & Arnold versions, then documented a safe production configuration. The workaround for the AOV issue meant the studio's output was now split across many individual EXR files per frame rather than a single merged multi-part EXR, which is what their compositing pipeline expected. Asking them to reconfigure their entire compositing setup wasn't a real solution. So our team wrote a Python utility that gathers all the AOV files for a given frame and combines them back into a layered EXR. We packaged it with a pre-configured Python runtime, documented the usage, and shared it directly with the studio.

Q: If you had to summarize what differentiates GridMarkets in one idea?

Fernando: Responsiveness and ownership. When something breaks, they don’t step back, they step in. Hakim: We see ourselves as part of the production process.

Jun 12
5 min read

An industry conversation with Hakim Karim, CEO & Co-founder of GridMarkets, and Fernando Viñuales, Commercial Director of Trigital Infográfica S.L. and former co-founder of SummusRender S.L.

When artists and studios think about cloud rendering, they usually focus on processing power, scalability, and turnaround times. What often remains invisible is the support and engineering effort required to keep complex productions moving when technical challenges arise.

In visual effects and animation, rendering problems are rarely simple. They can involve software versions, render engines, operating systems, plugins, color management, render layers, asset paths, and custom pipeline configurations. Solving them often requires more than infrastructure, it requires expertise!

For studios working on tight deadlines, rendering is not infrastructure, it is the final gate before delivery. When something fails, the expectation is not documentation or escalation tickets, but resolution.

To discuss how GridMarkets approaches customer support and technical problem-solving, we spoke with Hakim, CEO of GridMarkets, and Fernando, Commercial Director of Trigital, a long-time GridMarkets partner who regularly works with studios using the platform.

What followed was a detailed look into support, engineering, and a Maya production case that pushed both teams into deep technical territory.

The Partnership

“Render Support is part of production”

Interviewer: Fernando, you’ve introduced many studios to GridMarkets. What do they usually expect? What surprised them?

Fernando: Most studios initially see GridMarkets as a compute provider. That’s the entry point: faster renders, secure & scalable infrastructure, predictable pricing, etc. But what consistently surprises them is the support layer.

When something breaks in production, they don’t get a scripted response or an AI-powered chatbot, you get a human response within minutes, and more importantly, you get someone who actually understands the pipeline. They have engineers who understand Maya, Arnold, render layers, AOVs, and production pipelines. And more importantly, they get people who stay with the problem until it is solved. That changes the relationship completely.

Interviewer: Hakim, is that intentional?

Hakim: Completely.

We don’t treat support as an ancillary function. The same engineers who build the DCC-specific plugins are the ones involved in solving production issues.

Because in this industry, you cannot separate infrastructure from production reality. If a frame fails at 2am on a weekend, it is still a production problem. Everyone here feels the weight of a failed frame. It's not abstract.

Our responsibility is simple: Help the studio finish the shot.

"The people answering tickets are the same people who built the DCC-specific plugins. When a client hits a wall, we can reach into the system and do something about it."

Hakim, CEO, GridMarkets

A real Maya render production issue

Interviewer: Fernando, you recently worked with a studio on a complex Maya project. What went wrong?

Fernando: This was not a simple test case. It was a full production scene for a movie with complex render layers, custom light rigs grouped in sets, shadow-catcher workflows, AOV pipelines, and scenes that had been built over months.

They moved to GridMarkets because their local farm was hitting its limits. But migrating a mature pipeline to any new environment is never friction-free, even when the environment is excellent.

Interviewer: What were the first signs that something wasn't quite right?

Fernando: The renders were coming back with lighting that looked nothing like what the artists were seeing locally. Sets of lights that should have been invisible in certain layers were appearing anyway. The background layer had greenish lights bleeding through. The liquid layer had background lights leaking in. The team was understandably alarmed as these weren't cosmetic issues; they were fundamental composition errors.

Interviewer: Hakim, what happened on your side when when that kind of issue arrives?

Hakim: First, we assume nothing.

The most common mistake in render support is assuming the cause too early. So we rebuild the customer's environment to reproduce the problem.

In this case, we pulled the scene, matched the specific software stack, and began rendering across both Windows, that the customer was using, and Linux, that we run. We even tested with different Arnold versions and render-layers.

Very quickly, we saw that the issue was not singular. It was a combination of factors.

Interviewer: What did you find?

Hakim: Several interacting issues.

There was a discrepancy in Arnold behavior across versions. Certain builds interpreted light-set relationships differently, sometimes including lights in layers even without explicit connections.
Linux and Windows builds did not behave identically under the same scene conditions.
Enabling “Merge AOVs” introduced additional inconsistencies in how outputs were written and combined during batch rendering.

So what looked like a lighting problem was actually a multi-layered interaction between software versioning, render-layer evaluation, and output handling.

Interviewer: This sounds like it required more than standard troubleshooting.

Hakim: Yes - Engineering went beyond support.

We stabilized the environment to match the studio’s Maya & Arnold versions, then documented a safe production configuration.

The workaround for the AOV issue meant the studio's output was now split across many individual EXR files per frame rather than a single merged multi-part EXR, which is what their compositing pipeline expected. Asking them to reconfigure their entire compositing setup wasn't a real solution. So our team wrote a Python utility that gathers all the AOV files for a given frame and combines them back into a layered EXR. We packaged it with a pre-configured Python runtime, documented the usage, and shared it directly with the studio.

Fernando: That's what differentiates GridMarkets from a commodity compute provider. Any farm can give you compute hours. Very few will write you a bespoke tool because your pipeline expects merged EXRs and theirs doesn't. The studio team was genuinely moved by that. These are artists, not infrastructure engineers. Having someone meet them entirely on their turf meant everything.

Hakim: That is what support means to us.

Interviewer: Fernando, how did the studio react?

Fernando: Honestly, they were relieved, but also surprised.

What stood out wasn’t just that there was a solution. It was that GridMarkets stayed involved until the entire pipeline worked again: rendering, output and compositing. It felt like having an external TD team that doesn’t leave when things get complicated. When you encounter that level of care during a crisis, you don't want to go back to a farm that just processes your job and sends you an invoice.

The relationship that develops, that trust, is worth more than any render cost saving.

Fernando, Commercial Director, Trigital

GridMarkets' tailored support to ensure results are as expected

What's next

Interviewer: Looking ahead, what’s next for Maya on GridMarkets?

Hakim: One of the biggest developments in our roadmap is an improved Maya GUI submission plugin. Today, submission already works through our GUI plugin and Envoy, but we want to make it significantly more intuitive & fast, especially for studios where the person submitting isn't necessarily the TD.

The goal is simple - you finish your shot, you submit, and it just works.

No path issues, no missing assets, no configuration friction.

It is currently in development and planned for release in the next quarter.

Closing thoughts

Interviewer: If you had to summarize what differentiates GridMarkets in one idea?

Fernando: Responsiveness and ownership. When something breaks, they don’t step back, they step in.

Hakim: We see ourselves as part of the production process.

When a studio is under deadline, there is no separation between “support” and “engineering.” There is only the question: does the shot get delivered on time or not.