Advanced utilities: Render Node Template, Troubleshoot Machine, Simulate Local Path, API access

Super Renders Farm exposes four advanced utilities for studios that need more than the default web upload-submit-download flow: Render Node Template (define a reproducible software stack for the workers that render your job), Troubleshoot Machine (spin up an RDP-accessible debug VM that matches the render-node environment), Simulate Local Path (preserve absolute paths for projects that resolve assets by hard-coded path), and the API access surface (currently limited — see §API access for the current programmatic submission story). This page is the reference manual for all four — when to use each, how the underlying mechanism works on our farm, the exact steps to configure or invoke each one, and the failure modes we see most often in support.

If you are new to the farm and looking for the default upload flow, the is the right starting point. If you are debugging a failed job, the page covers the most frequent error patterns. The utilities documented here are for cases where the default flow does not fit — typically large studios with established pipelines, projects with unusual asset-path requirements, or one-off debug sessions where you need to see exactly what the render worker sees.

When to use which utility — decision callout

A short orientation before the per-utility sections:

| If you need to… | Use | |---|---| | Lock down which DCC version, plugin versions, and plugin licences run on the workers assigned to your job | Render Node Template | | Connect to a real render worker via Microsoft Remote Desktop, fix a scene in place, then submit it as a real job | Troubleshoot Machine | | Render a project that uses absolute paths (C:\projects\… or D:\textures\…) and cannot be re-pathed to relative | Simulate Local Path | | Submit jobs programmatically from a script or pipeline tool | API access (see placeholder — the current path is the Client App or DCC plugin) |

You can combine these. A Render Node Template can be paired with Simulate Local Path on the same job. The Troubleshoot Machine respects both your active Render Node Template and any Simulate Local Path configuration, so the debug environment matches the production render environment. The four utilities are designed to compose.

Render Node Template

The Render Node Template is the most powerful of the four utilities and the longest-standing. It lets you specify the exact software environment your render workers should have before they pick up your job: which version of 3ds Max, which V-Ray build, which plugins are installed and licenced, and any custom configuration files that need to be in place on the worker before the render starts. Once defined, the template is reusable across jobs — every submission you tag with that template runs against an identical worker stack.

What problem it solves

By default, Super Renders Farm pre-installs a curated software stack on every render worker — recent DCC versions and the most common renderers and plugins, calibrated to the workloads we see most often. For 80% of jobs this is the right default; the worker already has the software your scene needs. But there are two situations where the default falls short:

• Version pinning. Your studio standardised on 3ds Max 2024 + V-Ray 6.10.05 + a specific Forest Pack build, and you cannot risk a worker picking up a newer point release that introduces sampling or noise differences across frames in the same animation.
• Niche plugins. You use a plugin (or a plugin version) that is not in the default farm stack — for example, a less common Phoenix FD release, a Pulze ZBrush bridge, or an unusual Corona feature build.

The Render Node Template lets you declare the stack explicitly. The farm then either routes your job to workers that already match the declared template, or provisions new workers to match before assigning the job. Either way, the version-pinning guarantee is end-to-end.

How it works on our farm

A Render Node Template is a named configuration record attached to your account. It contains:

• The DCC and version — for example 3ds Max 2024.2.2.
• The renderer and version — for example V-Ray 6.10.05.
• A plugin list with versions — for example Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• A licence channel — which licences (Chaos, Maxon, Otoy, AXYZ Design) should be available to the worker via our umbrella licensing infrastructure. Most plugins are covered out of the box; if your template references a plugin we do not yet host, support flags it and you bring your own licence file.
• Optional file payloads — config files, presets, or shader libraries that should be placed in a known location on the worker before render start.

When you submit a job and tag it with a template, the farm scheduler matches the template against the current worker pool. If matching workers are idle, the job dispatches immediately. If no matching worker is available, the scheduler provisions a fresh worker against the template — this typically takes a few minutes longer than a default-stack job, which is the main trade-off.

Creating a Render Node Template

The template editor is accessible from your account dashboard under "Render Node Templates" (or similar — the exact UI label can shift between dashboard releases; if you do not see the entry, contact support and we will surface it for your account).

Steps:

1. Sign in to superrendersfarm.com and open the Render Node Templates section of your dashboard.
2. Create a new template and give it a descriptive name — typically a project code or a studio standard label like studio-archviz-2024-vray6. The name is yours; the farm only uses it for matching.
3. Pick the DCC and version. The dropdown lists every DCC version we currently host. If your required version is not listed, the template cannot be created against it without a support conversation — some legacy versions are deprecated.
4. Pick the renderer and version. Same constraint — the dropdown reflects the current farm stack.
5. Add plugins one at a time. For each plugin: select the plugin name from the catalogue, choose the version, and confirm the licence channel. Plugins outside our catalogue require a support conversation to add — typically a one-time effort if the plugin is mainstream enough that we can host the licence.
6. Attach any file payloads. Upload the config or preset files you need on the worker. The farm stores these alongside the template and copies them to the worker working directory before render start.
7. Save and validate. The dashboard runs a validation pass against the current worker pool and reports either "matching workers available" (immediate dispatch on first job) or "no current matches — workers will be provisioned on first use" (slight startup delay on first job).

The template is now available for selection on any subsequent job submission.

Using a template at submission time

When you submit a render job — via web upload, Client App, or DCC submission plugin — the submission form includes a "Render Node Template" dropdown. Select the template you created. The job inherits the entire stack declaration; you do not need to re-specify the DCC, renderer, or plugin versions on the submission form itself.

Two operational notes:

• Template + Express priority compose. You can submit a templated job with Express priority. The scheduler tries to find an idle worker that matches both constraints; if none is available, it provisions one. Express templated jobs typically have a slightly longer dispatch window than default-stack Express jobs, but the price difference is the same.
• Template + Simulate Local Path compose. If your project also requires absolute paths, configure Simulate Local Path on the submission as normal (see §Simulate Local Path). The template controls software environment; Simulate Local Path controls filesystem layout. They are orthogonal concerns.

Editing and versioning templates

A template is mutable — you can edit the version pinning, add or remove plugins, or replace file payloads. But editing a template affects all future jobs that use it; in-flight jobs already dispatched continue with the version of the template they captured at submission time.

For studios that need strict version control across template revisions, a common pattern is to clone-then-edit: when you need to update plugin versions, clone the existing template to studio-archviz-2024-vray6-r2, make the changes there, and update your project's submission scripts to point at the new template. The old template remains untouched for any in-progress projects that depend on its exact stack.

Common failure modes

• "No matching workers — provisioning takes 5-10 minutes." This is not an error, just a notice. The first templated job after a stack change provisions fresh workers. Subsequent jobs against the same template dispatch immediately because the workers are already warm.
• "Plugin licence unavailable for template." The plugin you specified is not on our hosted licence catalogue. Contact support — for mainstream plugins we typically add hosted licensing within a few business days; for niche plugins we can either onboard the licence or you provide a licence file with your submission.
• "Renderer version no longer supported." Older DCC or renderer versions get retired from the active stack periodically. The template editor surfaces this on save; the fix is to update the template to a supported version or clone-then-edit to a current build.
• "Job dispatched but worker stack does not match template." Rare, but worth knowing. If this happens, the job fails the pre-render sanity check and the farm requeues it on a confirmed-matching worker automatically. You do not pay for the failed dispatch attempt.

Troubleshoot Machine

Troubleshoot Machine is the diagnostic counterpart to the production render path. Instead of submitting a real job and waiting for it to fail with an error message, you spin up a Troubleshoot Machine — a Windows VM that matches the render-node software stack — and connect to it via Microsoft Remote Desktop Connection. You see exactly what the render worker would see, can open your scene file, identify what is failing, fix it in place, save the fixed scene back to your storage, and then submit a real production job with confidence.

What problem it solves

Most render failures fall into two buckets: scene-level issues (a missing plugin, a corrupted asset reference, a renderer setting incompatible with the version on the worker) and environment-level issues (a licence not available, a plugin not loading, a path mismatch). Both are hard to diagnose remotely — the only signal you get from a failed production job is the render log, which is often terse.

Troubleshoot Machine collapses the diagnostic loop. Instead of submit → fail → read log → guess → resubmit → fail → guess → resubmit, you spin up a Troubleshoot Machine, see the actual error in your DCC's GUI, fix it once, and submit a real job that works.

How it works on our farm

When you request a Troubleshoot Machine, the farm provisions a fresh Windows VM matching the current render-node stack for the DCC you specify (and any active Render Node Template, if you have one). The VM mounts your SRF Spaces storage as the S: drive — so the project files you have already uploaded appear exactly as they would on a production render worker. You connect via RDP from your local workstation.

The VM has a time budget — typically measured in minutes, billed against your render credits at a documented rate (check the dashboard for the current rate; this changes occasionally). When you are finished, you disconnect and either submit a production job from the same project or release the VM.

Starting a Troubleshoot Machine session

Steps:

1. From the dashboard, navigate to "Troubleshoot Machine" (or the equivalent dashboard entry — naming can vary between releases).
2. Select the DCC that matches your project. The VM will be provisioned with that DCC pre-installed and matching your declared Render Node Template if any.
3. Confirm the time budget. The dashboard shows the credit cost per minute; you commit to a maximum session length and can extend it during the session if needed.
4. Wait for provisioning. This typically takes a few minutes — a fresh VM is being prepared with your software stack.
5. Receive RDP connection details. The dashboard provides a hostname, username, and password (or a downloadable RDP file). On Windows, double-click the RDP file to connect; on macOS, use Microsoft Remote Desktop from the App Store.
6. Connect. You are now on the worker. The S: drive contains your SRF Spaces project files.

Using the session

Once connected, your workflow is the same as if you were sitting at the render worker:

• Open your scene file from S:. The DCC launches in the version specified by your template or the farm default for that DCC.
• Reproduce the failure. Whatever was failing in production — a render preview, a script error, an asset reference — should reproduce here. Investigate using the DCC's own diagnostic tools.
• Fix the scene. Re-link missing assets, change render settings, repair plugin references, or whatever the diagnosis requires.
• Save back to S:. Save the fixed scene to S:\SuperRendersOutput\ or another folder in your SRF Spaces. The save is persistent — when you end the Troubleshoot Machine session, the fixed scene remains in your storage.
• (Optional) Submit a real job from inside the VM. The DCC's SuperRenders submission plugin is installed inside the Troubleshoot Machine; you can submit a production render job from inside the VM, then disconnect and let the farm render normally.

When you are finished, disconnect from RDP and end the session from the dashboard. The VM is destroyed; any files you saved to S: remain in your SRF Spaces.

Common failure modes

• "Cannot connect to RDP — connection timed out." Check that your local network or VPN allows outbound RDP (port 3389). Some corporate networks block RDP egress. If this is the case, ask your IT team to whitelist the Troubleshoot Machine hostname.
• "RDP credentials rejected." Re-download the RDP file from the dashboard — the credentials are session-specific and can expire if the session is paused too long.
• "S: drive is empty or missing files." The drive maps to your SRF Spaces — if files do not appear, either the upload to SRF Spaces was not yet complete when the VM provisioned, or you are looking at the wrong folder. The default mount is S:\<account-id>\ typically.
• "My fix worked in Troubleshoot Machine but the production job still fails." Most often this is because the production job was submitted against a different Render Node Template (or default stack) than the Troubleshoot Machine session used. Verify the template selection on the production submission matches the Troubleshoot Machine configuration.

Simulate Local Path

Simulate Local Path is the smallest of the four utilities in scope but the one that resolves the largest single category of "won't render in the cloud" projects. Some DCC scenes resolve assets by hard-coded absolute path — C:\projects\studio\my-scene\textures\wood_01.tx, for example — rather than by relative path. When that scene uploads to a render farm, the renderer cannot find the textures because the absolute path does not exist on the worker. Simulate Local Path makes the absolute path exist.

What problem it solves

The straightforward solution to this category of problem is to re-path the scene before submission — switch every asset reference from absolute to relative — but for some workflows this is not practical:

• Anima scenes (AXYZ Design's animated-people plugin) write absolute paths to character cache files at scene save time; manual re-pathing breaks the cache binding.
• Corona Image Editor 4K-cache rendering writes absolute paths that the renderer expects to find again at the same path on render time.
• Substance / Substance Painter export workflows can embed absolute paths to texture sources.
• Alembic asset references sometimes write absolute paths depending on the DCC's export settings.
• Old archive projects where re-pathing every asset reference is impractical, and the studio just wants the project to render as-is.

For these cases, Simulate Local Path tells the farm: when this job runs, recreate the absolute path on the worker so the renderer finds its assets where the scene expects them.

How it works on our farm

When you upload a project with Simulate Local Path enabled, the SuperRenders Client App (or web upload, with the right setting) preserves the original absolute path structure in the upload. On the render worker, the farm creates the corresponding directory tree at the same absolute path before render start — so if your scene file references D:\studio-2024\project-x\textures\wood.tx, the worker has a real D:\studio-2024\project-x\textures\wood.tx at render time and the scene resolves correctly.

The mechanism is most reliable when paired with the SuperRenders Client App's "Auto keep local path" option, which preserves the absolute path automatically on upload. For web upload, you set the path structure manually in the SRF Spaces folder structure before uploading the files.

Configuring Simulate Local Path

There are two paths into this feature:

Via the SuperRenders Client App (recommended):

1. In the Client App, before adding files to an upload, open the upload settings.
2. Enable "Auto keep local path" (the exact label may shift slightly between Client App versions — look for the path-preservation checkbox).
3. Add your project files. The Client App reads the absolute path of each file as it is added and preserves it in the upload tree.
4. Confirm the path tree in the upload preview. You should see the full absolute path structure mirrored under your SRF Spaces.
5. Upload normally. The path structure transfers along with the files.
6. At submission time, enable "Simulate Local Path" on the job — the dashboard or Client App submission form has a checkbox or dropdown for this. The farm will recreate the absolute path on the worker.

Via web upload (manual):

1. In SRF Spaces (the web file browser inside your account dashboard), use the "Create Folder" button to recreate the absolute path structure manually. For example, if your project references D:\studio-2024\project-x\, create a folder D: (literally, as the folder name), then a subfolder studio-2024, then project-x, and so on.
2. Upload your files into the recreated path tree. Each file ends up at the matching absolute path inside SRF Spaces.
3. At submission time, enable "Simulate Local Path" on the job. The farm will read the path structure from SRF Spaces and replicate it on the worker.

The web upload path is more manual but works correctly when configured. The Client App is faster and less error-prone for studios doing this regularly.

Operational notes

• Drive letters. On the render worker, the simulated drive (e.g. D: if your project uses D:\…) is a logical mount, not a physical drive. The mount is created at job start and torn down at job end; it is not persistent.
• Path length limits. Windows has historical path-length limits (around 260 characters for legacy applications). If your absolute paths are very long, some DCCs may fail to load files even after Simulate Local Path is configured. The fix is either to shorten paths at the project level or to enable long-path support in your DCC, which most current versions support.
• Cross-DCC composition. Simulate Local Path can be combined with a Render Node Template and with Troubleshoot Machine — the simulated path tree appears identically across all three contexts.

Common failure modes

• "Asset still missing after enabling Simulate Local Path." The most common cause is that the upload did not actually preserve the path. Open SRF Spaces in the web dashboard and confirm the absolute path structure exists there. If it does not, re-upload with "Auto keep local path" enabled in the Client App.
• "Render starts but the wrong texture loads." Sometimes a scene has multiple assets with the same filename in different paths; if the path simulation is incomplete, the renderer can fall back to a different file with the same name. Verify the full path structure is preserved in SRF Spaces.
• "Renderer reports access denied at the simulated path." This usually means the path involves a Windows-reserved directory name (con, aux, prn, etc.) that cannot be created as a regular folder. Re-path the project to avoid the reserved name.

API access

Programmatic access to Super Renders Farm submission is on the roadmap. A public REST API for job submission, status polling, and output retrieval is being designed; at this time, no public API endpoints are available for direct integration.

For current programmatic submission needs, the supported paths are:

• The SuperRenders Client App — the desktop Client App () can be driven from scripts on Windows and macOS via its command-line surface (where available) or by file-drop automation on the upload directory. For studios with established pipeline-automation tools, the Client App is the current best-practice integration point.
• The DCC submission plugin — the per-DCC plugin (3ds Max, Maya, Cinema 4D) integrates with the DCC's own scripting environment (MAXScript, Python, etc.) and can be driven from pipeline scripts that already run inside the DCC.

When the public API ships, this section will be replaced with the full API reference (authentication, endpoints, rate limits, SDK examples). For studios that are blocked on a public API for their pipeline integration, contact support to share the use case — the roadmap is informed by real pipeline requirements.

Cross-references

• — default upload-submit-download flow without these utilities
• — desktop application install and use
• — browser-based submission flow
• — large-project transfer pattern
• — how render credits are billed, including Troubleshoot Machine session pricing
• — cross-DCC troubleshooting reference
• — comparison of upload methods
• , , — per-DCC submission setup that pairs with these utilities

FAQ

Q: Do I need a Render Node Template for every job? A: No. Most jobs run cleanly on the farm's default software stack — the most common DCC and renderer versions with the most common plugins. A Render Node Template is for cases where you need version pinning across a long-running project, or where you use a plugin not in the default catalogue. If you are not sure whether you need one, the default stack is almost always the right starting choice.

Q: How much does a Troubleshoot Machine session cost? A: Troubleshoot Machine sessions are billed against your render credits at a per-minute rate shown on the dashboard at session-start time. The rate changes occasionally as we update the underlying VM infrastructure; the dashboard is always authoritative. For a typical 30-minute diagnostic session, expect a small fraction of a single full render job's cost.

Q: Can I use Simulate Local Path if my project is on macOS or Linux? A: The worker render-environment is Windows, so absolute paths are simulated as Windows paths (D:\… form). If your project is authored on macOS or Linux with absolute paths in /Users/… or /home/… form, the path simulation can still work — the farm creates a logical Windows mount that matches the path string the scene expects — but in practice mac/Linux-authored projects usually use relative paths and do not need this utility.

Q: Does Render Node Template add to the render time? A: The first job submitted against a new template can take a few minutes longer to dispatch while the farm provisions matching workers. Subsequent jobs against the same template dispatch at default-stack speed because the matching workers are already warm. Net per-job time once the template is active is the same as default-stack.

Q: Can I edit a Render Node Template while a job is in flight? A: Yes, but the in-flight job continues with the template version it captured at submission time. The edit affects future submissions only. For projects that need stricter version control, clone the template to a new name and update your submission scripts to point at the new clone rather than editing the existing template.

Q: My DCC version is not in the Render Node Template dropdown. What now? A: Contact support and share the version you need. For mainstream DCCs we typically host current versions plus a few back-versions; very old versions may have been retired from the active stack. We can usually onboard a back-version with a few days' lead time, or guide you to the closest supported version that matches your scene compatibility.

Q: Is there a public API I can use to submit jobs from my pipeline? A: Not yet. A public REST API is on the roadmap. Today, the recommended programmatic-submission path is either the SuperRenders Client App (driven from scripts) or the per-DCC submission plugin (driven from the DCC's native scripting environment). If your pipeline-automation use case is blocked on a public API specifically, contact support — the roadmap is informed by real pipeline requirements, and your input helps prioritise.

Q: Can I run a Troubleshoot Machine against a Render Node Template? A: Yes — and this is the recommended pattern when you are debugging a templated job. The Troubleshoot Machine session reads your active Render Node Template at provisioning time and provisions the VM with the matching software stack. You see exactly what the production worker would see, including the templated plugin versions.

---

<!-- Q3 noindex resolution: api-authentication folded into this doc as §API access placeholder; doc remains INDEXED (noindex:false). Master to ratify carve-out reversal at review — see frontmatter comment + review report. -->