Erweiterte Hilfsprogramme: Render-Node-Vorlage, Troubleshoot Machine, Simulate Local Path, API-Zugang

Super Renders Farm stellt vier erweiterte Hilfsprogramme für Studios bereit, die mehr als den standardmäßigen Web-Upload-Einreich-Download-Fluss benötigen: Render-Node-Vorlage (einen reproduzierbaren Software-Stack für die Worker definieren, die Ihren Job rendern), Troubleshoot Machine (eine RDP-zugängliche Debug-VM hochfahren, die der Render-Knoten-Umgebung entspricht), Simulate Local Path (absolute Pfade für Projekte erhalten, die Assets durch hartkodierten Pfad auflösen) und die API-Zugangsschnittstelle (derzeit eingeschränkt — lesen Sie §API-Zugang für die aktuelle programmatische Einreichungsgeschichte). Diese Seite ist das Referenzhandbuch für alle vier — wann welches verwendet wird, wie der zugrunde liegende Mechanismus auf unserer Farm funktioniert, die genauen Schritte zur Konfiguration oder Aufrufung jedes einzelnen und die Fehlermodi, die wir im Support am häufigsten sehen.

Wenn Sie neu auf der Farm sind und nach dem Standard-Upload-Fluss suchen, ist die der richtige Ausgangspunkt. Wenn Sie einen fehlgeschlagenen Job debuggen, deckt die Seite die häufigsten Fehlermuster ab. Die hier dokumentierten Hilfsprogramme sind für Fälle gedacht, in denen der Standardfluss nicht passt — typischerweise große Studios mit etablierten Pipelines, Projekte mit ungewöhnlichen Asset-Pfad-Anforderungen oder einmalige Debug-Sitzungen, bei denen Sie genau sehen müssen, was der Render-Worker sieht.

Welches Hilfsprogramm wann verwenden — Entscheidungsübersicht

Eine kurze Orientierung vor den Pro-Hilfsprogramm-Abschnitten:

| Wenn Sie Folgendes benötigen… | Verwenden Sie | |---|---| | Festlegen, welche DCC-Version, Plugin-Versionen und Plugin-Lizenzen auf den Ihrem Job zugewiesenen Workern ausgeführt werden | Render-Node-Vorlage | | Mit einer echten Render-Worker-Maschine via Microsoft Remote Desktop verbinden, eine Szene direkt reparieren und sie dann als echten Job einreichen | Troubleshoot Machine | | Ein Projekt rendern, das absolute Pfade verwendet (C:\projects\… oder D:\textures\…) und nicht auf relative Pfade umgestellt werden kann | Simulate Local Path | | Jobs programmatisch aus einem Skript oder Pipeline-Tool einreichen | API-Zugang (lesen Sie den Platzhalter — der aktuelle Pfad ist die Client App oder das DCC-Plugin) |

Sie können diese kombinieren. Eine Render-Node-Vorlage kann mit Simulate Local Path beim gleichen Job kombiniert werden. Die Troubleshoot Machine respektiert sowohl Ihre aktive Render-Node-Vorlage als auch jede Simulate Local Path-Konfiguration, sodass die Debug-Umgebung der Produktions-Render-Umgebung entspricht. Die vier Hilfsprogramme sind zum Kombinieren konzipiert.

Render-Node-Vorlage

Die Render-Node-Vorlage ist das leistungsfähigste der vier Hilfsprogramme und das langfristig etablierteste. Sie ermöglicht es Ihnen, die genaue Software-Umgebung festzulegen, die Ihre Render-Worker haben sollen, bevor sie Ihren Job aufnehmen: welche Version von 3ds Max, welchen V-Ray-Build, welche Plugins installiert und lizenziert sind, und alle benutzerdefinierten Konfigurationsdateien, die vor dem Rendern auf dem Worker vorhanden sein müssen. Einmal definiert, ist die Vorlage für Jobs wiederverwendbar — jede Einreichung, die Sie mit dieser Vorlage markieren, läuft gegen einen identischen Worker-Stack.

Welches Problem sie löst

Standardmäßig installiert Super Renders Farm einen kuratierten Software-Stack auf jedem Render-Worker — aktuelle DCC-Versionen und die am häufigsten verwendeten Renderer und Plugins, kalibriert für die Arbeitslasten, die wir am häufigsten sehen. Für 80 % der Jobs ist dies der richtige Standard; der Worker hat bereits die Software, die Ihre Szene benötigt. Aber es gibt zwei Situationen, in denen der Standard nicht ausreicht:

• Versions-Pinning. Ihr Studio hat sich auf 3ds Max 2024 + V-Ray 6.10.05 + einen bestimmten Forest Pack-Build standardisiert, und Sie können nicht riskieren, dass ein Worker eine neuere Zwischenversion aufnimmt, die Sampling- oder Rauschunterschiede über Frames der gleichen Animation hinweg einführt.
• Nischen-Plugins. Sie verwenden ein Plugin (oder eine Plugin-Version), das nicht im Standard-Farm-Stack enthalten ist — zum Beispiel eine weniger verbreitete Phoenix FD-Version, eine Pulze ZBrush-Bridge oder einen ungewöhnlichen Corona-Feature-Build.

Die Render-Node-Vorlage ermöglicht es Ihnen, den Stack explizit zu deklarieren. Die Farm leitet dann entweder Ihren Job zu Workern, die bereits der deklarierten Vorlage entsprechen, oder stellt neue Worker bereit, die vor der Job-Zuweisung übereinstimmen. In beiden Fällen ist die Versions-Pinning-Garantie end-to-end.

Wie sie auf unserer Farm funktioniert

Eine Render-Node-Vorlage ist ein benannter Konfigurationsdatensatz, der Ihrem Konto angehängt ist. Sie enthält:

• Das DCC und die Version — zum Beispiel 3ds Max 2024.2.2.
• Den Renderer und die Version — zum Beispiel V-Ray 6.10.05.
• Eine Plugin-Liste mit Versionen — zum Beispiel Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• Einen Lizenzkanal — welche Lizenzen (Chaos, Maxon, Otoy, AXYZ Design) dem Worker über unsere Umbrella-Lizenzierungs-Infrastruktur zur Verfügung stehen sollen. Die meisten Plugins sind standardmäßig abgedeckt; wenn Ihre Vorlage ein Plugin referenziert, das wir noch nicht hosten, markiert der Support es und Sie bringen Ihre eigene Lizenzdatei mit.
• Optionale Datei-Payloads — Konfigurationsdateien, Presets oder Shader-Bibliotheken, die vor dem Render-Start an einem bekannten Ort auf dem Worker platziert werden sollen.

Wenn Sie einen Job einreichen und ihn mit einer Vorlage markieren, vergleicht der Farm-Scheduler die Vorlage mit dem aktuellen Worker-Pool. Wenn übereinstimmende Worker inaktiv sind, wird der Job sofort verteilt. Wenn kein übereinstimmender Worker verfügbar ist, stellt der Scheduler einen neuen Worker gegen die Vorlage bereit — dies dauert typischerweise ein paar Minuten länger als ein Standard-Stack-Job, was der Hauptkompromiss ist.

Erstellen einer Render-Node-Vorlage

Der Vorlagen-Editor ist in Ihrem Konto-Dashboard unter „Render Node Templates" zugänglich (oder ähnlich — das genaue UI-Label kann sich zwischen Dashboard-Versionen ändern; wenn Sie den Eintrag nicht sehen, kontaktieren Sie den Support und wir machen ihn für Ihr Konto sichtbar).

Schritte:

1. Anmelden bei superrendersfarm.com und den Abschnitt Render-Node-Vorlagen in Ihrem Dashboard öffnen.
2. Neue Vorlage erstellen und ihr einen beschreibenden Namen geben — typischerweise einen Projektcode oder ein Studio-Standard-Label wie studio-archviz-2024-vray6. Der Name ist Ihrer; die Farm verwendet ihn nur für das Matching.
3. DCC und Version auswählen. Das Dropdown listet jede DCC-Version, die wir derzeit hosten. Wenn Ihre benötigte Version nicht aufgeführt ist, kann die Vorlage nicht ohne ein Support-Gespräch gegen sie erstellt werden — einige Legacy-Versionen sind veraltet.
4. Renderer und Version auswählen. Gleiche Einschränkung — das Dropdown spiegelt den aktuellen Farm-Stack wider.
5. Plugins einzeln hinzufügen. Für jedes Plugin: den Plugin-Namen aus dem Katalog auswählen, die Version wählen und den Lizenzkanal bestätigen. Plugins außerhalb unseres Katalogs erfordern ein Support-Gespräch, um hinzugefügt zu werden — typischerweise ein einmaliger Aufwand, wenn das Plugin gängig genug ist, dass wir die Lizenz hosten können.
6. Beliebige Datei-Payloads anhängen. Laden Sie die Konfigurations- oder Preset-Dateien hoch, die Sie auf dem Worker benötigen. Die Farm speichert diese zusammen mit der Vorlage und kopiert sie vor dem Render-Start in das Worker-Arbeitsverzeichnis.
7. Speichern und validieren. Das Dashboard führt einen Validierungsdurchgang gegen den aktuellen Worker-Pool durch und meldet entweder „übereinstimmende Worker verfügbar" (sofortige Verteilung beim ersten Job) oder „keine aktuellen Übereinstimmungen — Worker werden beim ersten Gebrauch bereitgestellt" (leichte Startumverzögerung beim ersten Job).

Die Vorlage ist nun für die Auswahl bei jeder nachfolgenden Job-Einreichung verfügbar.

Eine Vorlage bei der Einreichungszeit verwenden

Wenn Sie einen Render-Job einreichen — über Web-Upload, Client App oder DCC-Einreichungs-Plugin — enthält das Einreichungsformular ein Dropdown „Render-Node-Vorlage". Wählen Sie die von Ihnen erstellte Vorlage. Der Job erbt die gesamte Stack-Deklaration; Sie müssen DCC, Renderer oder Plugin-Versionen nicht im Einreichungsformular selbst erneut angeben.

Zwei betriebliche Hinweise:

• Vorlage + Express-Priorität kombinieren. Sie können einen Vorlagen-Job mit Express-Priorität einreichen. Der Scheduler versucht, einen inaktiven Worker zu finden, der beiden Einschränkungen entspricht; wenn keiner verfügbar ist, stellt er einen bereit. Express-Vorlagen-Jobs haben typischerweise ein etwas längeres Verteilungsfenster als Standard-Stack-Express-Jobs, aber der Preisunterschied ist derselbe.
• Vorlage + Simulate Local Path kombinieren. Wenn Ihr Projekt auch absolute Pfade erfordert, konfigurieren Sie Simulate Local Path bei der Einreichung wie gewohnt (lesen Sie §Simulate Local Path). Die Vorlage steuert die Software-Umgebung; Simulate Local Path steuert das Dateisystem-Layout. Sie sind orthogonale Belange.

Vorlagen bearbeiten und versionieren

Eine Vorlage ist veränderbar — Sie können die Versions-Pinning-Einstellung ändern, Plugins hinzufügen oder entfernen oder Datei-Payloads ersetzen. Aber die Bearbeitung einer Vorlage betrifft alle zukünftigen Jobs, die sie verwenden; bereits verteilte laufende Jobs fahren mit der Version der Vorlage fort, die sie zum Einreichungszeitpunkt erfasst haben.

Für Studios, die eine strenge Versionskontrolle über Vorlagen-Revisionen benötigen, ist ein übliches Muster das Klonen-dann-Bearbeiten: Wenn Sie Plugin-Versionen aktualisieren müssen, klonen Sie die vorhandene Vorlage zu studio-archviz-2024-vray6-r2, nehmen Sie dort die Änderungen vor und aktualisieren Sie die Einreichungs-Skripte Ihres Projekts, um auf die neue Vorlage zu verweisen. Die alte Vorlage bleibt für alle laufenden Projekte unberührt, die auf ihrem genauen Stack basieren.

Häufige Fehlermodi

• „Keine übereinstimmenden Worker — Bereitstellung dauert 5-10 Minuten." Dies ist kein Fehler, nur ein Hinweis. Der erste Vorlagen-Job nach einer Stack-Änderung stellt neue Worker bereit. Nachfolgende Jobs gegen dieselbe Vorlage werden sofort verteilt, weil die Worker bereits bereit sind.
• „Plugin-Lizenz für Vorlage nicht verfügbar." Das von Ihnen angegebene Plugin befindet sich nicht in unserem gehosteten Lizenzkatalog. Kontaktieren Sie den Support — für gängige Plugins fügen wir normalerweise gehostete Lizenzierung innerhalb weniger Werktage hinzu; für Nischen-Plugins können wir entweder die Lizenz einbinden oder Sie stellen eine Lizenzdatei mit Ihrer Einreichung bereit.
• „Renderer-Version wird nicht mehr unterstützt." Ältere DCC- oder Renderer-Versionen werden periodisch aus dem aktiven Stack zurückgezogen. Der Vorlagen-Editor meldet dies beim Speichern; die Lösung besteht darin, die Vorlage auf eine unterstützte Version zu aktualisieren oder zum Klonen-dann-Bearbeiten auf einen aktuellen Build zu wechseln.
• „Job verteilt, aber Worker-Stack entspricht nicht der Vorlage." Selten, aber es lohnt sich zu wissen. Wenn dies geschieht, schlägt der Job die Pre-Render-Plausibilitätsprüfung fehl, und die Farm reiht ihn automatisch auf einem bestätigten übereinstimmenden Worker erneut ein. Sie zahlen nicht für den fehlgeschlagenen Verteilungsversuch.

Troubleshoot Machine

Troubleshoot Machine ist das diagnostische Gegenstück zum Produktions-Render-Pfad. Anstatt einen echten Job einzureichen und darauf zu warten, dass er mit einer Fehlermeldung fehlschlägt, starten Sie eine Troubleshoot Machine — eine Windows-VM, die dem Render-Knoten-Software-Stack entspricht — und verbinden sich über Microsoft Remote Desktop Connection. Sie sehen genau das, was der Render-Worker sehen würde, können Ihre Szenendatei öffnen, identifizieren, was fehlschlägt, es direkt reparieren, die reparierte Szene zurück in Ihren Speicher speichern und dann einen echten Produktionsjob mit Zuversicht einreichen.

Welches Problem sie löst

Die meisten Render-Fehler fallen in zwei Kategorien: Szenen-Probleme (ein fehlendes Plugin, eine beschädigte Asset-Referenz, eine Renderer-Einstellung, die mit der Version auf dem Worker inkompatibel ist) und Umgebungs-Probleme (eine nicht verfügbare Lizenz, ein nicht ladendes Plugin, ein Pfad-Mismatch). Beide sind schwer fernzudiagnostizieren — das einzige Signal, das Sie von einem fehlgeschlagenen Produktionsjob erhalten, ist das Render-Log, das oft knapp ist.

Troubleshoot Machine verkürzt die Diagnose-Schleife. Anstatt einreichen → fehlschlagen → Log lesen → raten → erneut einreichen → fehlschlagen → raten → erneut einreichen, starten Sie eine Troubleshoot Machine, sehen den tatsächlichen Fehler in der GUI Ihres DCC, beheben ihn einmalig und reichen einen echten Job ein, der funktioniert.

Wie sie auf unserer Farm funktioniert

Wenn Sie eine Troubleshoot Machine anfordern, stellt die Farm eine neue Windows-VM bereit, die dem aktuellen Render-Knoten-Stack für das von Ihnen angegebene DCC entspricht (und jeder aktiven Render-Node-Vorlage, falls vorhanden). Die VM bindet Ihren SRF Spaces-Speicher als S:-Laufwerk ein — sodass die Projektdateien, die Sie bereits hochgeladen haben, genau so erscheinen, wie sie es auf einem Produktions-Render-Worker täten. Sie verbinden sich per RDP von Ihrer lokalen Workstation aus.

Die VM hat ein Zeitbudget — typischerweise in Minuten gemessen, gegen Ihre Render-Credits zu einem dokumentierten Satz abgerechnet (prüfen Sie das Dashboard für den aktuellen Satz; dieser ändert sich gelegentlich). Wenn Sie fertig sind, trennen Sie die Verbindung und reichen entweder einen Produktionsjob aus dem gleichen Projekt ein oder geben die VM frei.

Eine Troubleshoot Machine-Sitzung starten

Schritte:

1. Im Dashboard zu „Troubleshoot Machine" navigieren (oder dem entsprechenden Dashboard-Eintrag — die Benennung kann zwischen Versionen variieren).
2. Das DCC auswählen, das Ihrem Projekt entspricht. Die VM wird mit diesem DCC vorinstalliert bereitgestellt und entspricht Ihrer deklarierten Render-Node-Vorlage, falls vorhanden.
3. Das Zeitbudget bestätigen. Das Dashboard zeigt die Credit-Kosten pro Minute; Sie verpflichten sich zu einer maximalen Sitzungsdauer und können diese während der Sitzung bei Bedarf verlängern.
4. Auf die Bereitstellung warten. Dies dauert typischerweise ein paar Minuten — eine neue VM wird mit Ihrem Software-Stack vorbereitet.
5. RDP-Verbindungsdetails erhalten. Das Dashboard stellt einen Hostnamen, Benutzernamen und Passwort bereit (oder eine herunterladbare RDP-Datei). Unter Windows doppelklicken Sie auf die RDP-Datei, um die Verbindung herzustellen; unter macOS verwenden Sie Microsoft Remote Desktop aus dem App Store.
6. Verbinden. Sie befinden sich jetzt auf dem Worker. Das S:-Laufwerk enthält Ihre SRF Spaces-Projektdateien.

Die Sitzung nutzen

Nach der Verbindung ist Ihr Workflow derselbe wie wenn Sie am Render-Worker säßen:

• Öffnen Sie Ihre Szenendatei von S: aus. Das DCC startet in der durch Ihre Vorlage oder den Farm-Standard für das DCC festgelegten Version.
• Reproduzieren Sie den Fehler. Was auch immer in der Produktion fehlschlug — eine Render-Vorschau, ein Skriptfehler, eine Asset-Referenz — sollte hier reproduzierbar sein. Untersuchen Sie mit den eigenen Diagnose-Tools des DCC.
• Reparieren Sie die Szene. Verlinken Sie fehlende Assets erneut, ändern Sie Render-Einstellungen, reparieren Sie Plugin-Referenzen oder was auch immer die Diagnose erfordert.
• Zurück in S: speichern. Speichern Sie die reparierte Szene in S:\SuperRendersOutput\ oder einem anderen Ordner in Ihrem SRF Spaces. Die Speicherung ist persistent — wenn Sie die Troubleshoot Machine-Sitzung beenden, verbleibt die reparierte Szene in Ihrem Speicher.
• (Optional) Einen echten Job von innerhalb der VM einreichen. Das SuperRenders-Einreichungs-Plugin des DCC ist innerhalb der Troubleshoot Machine installiert; Sie können einen Produktions-Render-Job von innerhalb der VM einreichen, dann die Verbindung trennen und die Farm normal rendern lassen.

Wenn Sie fertig sind, trennen Sie die RDP-Verbindung und beenden Sie die Sitzung im Dashboard. Die VM wird zerstört; alle Dateien, die Sie in S: gespeichert haben, verbleiben in Ihren SRF Spaces.

Häufige Fehlermodi

• „Verbindung zu RDP nicht möglich — Verbindungszeit überschritten." Prüfen Sie, ob Ihr lokales Netzwerk oder VPN ausgehende RDP-Verbindungen (Port 3389) erlaubt. Einige Unternehmensnetzwerke blockieren RDP-Egress. Wenn dies der Fall ist, bitten Sie Ihr IT-Team, den Troubleshoot Machine-Hostnamen auf die Whitelist zu setzen.
• „RDP-Anmeldedaten abgelehnt." Laden Sie die RDP-Datei aus dem Dashboard erneut herunter — die Anmeldedaten sind sitzungsspezifisch und können ablaufen, wenn die Sitzung zu lange pausiert ist.
• „S:-Laufwerk ist leer oder fehlende Dateien." Das Laufwerk ist Ihrem SRF Spaces zugeordnet — wenn Dateien nicht erscheinen, war entweder der Upload in SRF Spaces noch nicht abgeschlossen, als die VM bereitgestellt wurde, oder Sie sehen in den falschen Ordner. Die Standard-Einbindung ist typischerweise S:\<konto-id>\.
• „Meine Korrektur funktionierte in der Troubleshoot Machine, aber der Produktionsjob schlägt immer noch fehl." Am häufigsten liegt dies daran, dass der Produktionsjob gegen eine andere Render-Node-Vorlage (oder Standard-Stack) eingereicht wurde als die Troubleshoot Machine-Sitzung verwendet hat. Überprüfen Sie, ob die Vorlagenauswahl bei der Produktionseinreichung mit der Troubleshoot Machine-Konfiguration übereinstimmt.

Simulate Local Path

Simulate Local Path ist das kleinste der vier Hilfsprogramme im Umfang, aber dasjenige, das die größte einzelne Kategorie von „wird nicht in der Cloud rendern"-Projekten löst. Einige DCC-Szenen lösen Assets durch hartkodierten absoluten Pfad auf — zum Beispiel C:\projects\studio\my-scene\textures\wood_01.tx — anstatt durch relativen Pfad. Wenn diese Szene auf eine render farm hochgeladen wird, kann der Renderer die Texturen nicht finden, weil der absolute Pfad auf dem Worker nicht existiert. Simulate Local Path lässt den absoluten Pfad existieren.

Welches Problem sie löst

Die einfache Lösung für diese Problemkategorie besteht darin, die Szene vor der Einreichung umzupfaden — jeden Asset-Verweis von absolut auf relativ umzustellen — aber für einige Workflows ist dies nicht praktikabel:

• Anima-Szenen (AXYZ Designs Plugin für animierte Personen) schreiben beim Szene-Speichern absolute Pfade zu Charakter-Cache-Dateien; manuelles Umpathen beschädigt die Cache-Bindung.
• Corona Image Editor 4K-Cache-Rendering schreibt absolute Pfade, die der Renderer erwartet, zur Render-Zeit wieder am gleichen Pfad zu finden.
• Substance / Substance Painter-Export-Workflows können absolute Pfade zu Texturquellen einbetten.
• Alembic-Asset-Referenzen schreiben manchmal absolute Pfade je nach den DCC-Exporteinstellungen.
• Alte Archivprojekte, bei denen das Umpathen jeder Asset-Referenz unpraktisch ist, und das Studio das Projekt einfach so rendern möchte, wie es ist.

Für diese Fälle teilt Simulate Local Path der Farm mit: Wenn dieser Job läuft, den absoluten Pfad auf dem Worker neu erstellen, damit der Renderer seine Assets dort findet, wo die Szene sie erwartet.

Wie sie auf unserer Farm funktioniert

Wenn Sie ein Projekt mit aktiviertem Simulate Local Path hochladen, bewahrt die SuperRenders Client App (oder der Web-Upload, mit der richtigen Einstellung) die ursprüngliche absolute Pfadstruktur beim Upload. Auf dem Render-Worker erstellt die Farm den entsprechenden Verzeichnisbaum am gleichen absoluten Pfad vor dem Render-Start — wenn Ihre Szenendatei also D:\studio-2024\project-x\textures\wood.tx referenziert, hat der Worker zur Render-Zeit ein echtes D:\studio-2024\project-x\textures\wood.tx und die Szene löst korrekt auf.

Der Mechanismus ist am zuverlässigsten, wenn er mit der Option „Auto keep local path" der SuperRenders Client App kombiniert wird, die den absoluten Pfad beim Upload automatisch bewahrt. Beim Web-Upload setzen Sie die Pfadstruktur manuell in der SRF Spaces-Ordnerstruktur, bevor Sie die Dateien hochladen.

Simulate Local Path konfigurieren

Es gibt zwei Wege in diese Funktion:

Über die SuperRenders Client App (empfohlen):

1. Öffnen Sie in der Client App die Upload-Einstellungen, bevor Sie Dateien zu einem Upload hinzufügen.
2. „Auto keep local path" aktivieren (das genaue Label kann sich zwischen Client App-Versionen leicht ändern — suchen Sie nach dem Pfad-Erhaltungs-Kontrollkästchen).
3. Ihre Projektdateien hinzufügen. Die Client App liest den absoluten Pfad jeder Datei beim Hinzufügen und bewahrt ihn im Upload-Baum.
4. Den Pfadbaum in der Upload-Vorschau bestätigen. Sie sollten die vollständige absolute Pfadstruktur gespiegelt unter Ihrem SRF Spaces sehen.
5. Normal hochladen. Die Pfadstruktur wird zusammen mit den Dateien übertragen.
6. Beim Einreichen „Simulate Local Path" aktivieren — das Dashboard oder Client App-Einreichungsformular hat dafür ein Kontrollkästchen oder Dropdown. Die Farm wird den absoluten Pfad auf dem Worker neu erstellen.

Über den Web-Upload (manuell):

1. Verwenden Sie in SRF Spaces (dem Web-Dateibrowser in Ihrem Konto-Dashboard) die Schaltfläche „Ordner erstellen", um die absolute Pfadstruktur manuell neu zu erstellen. Wenn Ihr Projekt zum Beispiel D:\studio-2024\project-x\ referenziert, erstellen Sie einen Ordner D: (buchstäblich als Ordnername), dann einen Unterordner studio-2024, dann project-x und so weiter.
2. Ihre Dateien in den neu erstellten Pfadbaum hochladen. Jede Datei landet an dem übereinstimmenden absoluten Pfad innerhalb von SRF Spaces.
3. Beim Einreichen „Simulate Local Path" aktivieren beim Job. Die Farm liest die Pfadstruktur aus SRF Spaces und repliziert sie auf dem Worker.

Der Web-Upload-Pfad ist manueller, funktioniert aber korrekt, wenn er konfiguriert ist. Die Client App ist für Studios, die dies regelmäßig tun, schneller und weniger fehleranfällig.

Betriebliche Hinweise

• Laufwerksbuchstaben. Auf dem Render-Worker ist das simulierte Laufwerk (z. B. D:, wenn Ihr Projekt D:\… verwendet) eine logische Einbindung, kein physisches Laufwerk. Die Einbindung wird beim Job-Start erstellt und beim Job-Ende abgebaut; sie ist nicht persistent.
• Pfadlängenlimits. Windows hat historische Pfadlängenlimits (ca. 260 Zeichen für Legacy-Anwendungen). Wenn Ihre absoluten Pfade sehr lang sind, können einige DCCs Dateien möglicherweise nicht laden, auch nachdem Simulate Local Path konfiguriert ist. Die Lösung besteht entweder darin, Pfade auf Projektebene zu verkürzen oder die Langpfad-Unterstützung in Ihrem DCC zu aktivieren, was die meisten aktuellen Versionen unterstützen.
• DCC-übergreifende Komposition. Simulate Local Path kann mit einer Render-Node-Vorlage und mit der Troubleshoot Machine kombiniert werden — der simulierte Pfadbaum erscheint in allen drei Kontexten identisch.

Häufige Fehlermodi

• „Asset noch immer fehlend nach Aktivierung von Simulate Local Path." Die häufigste Ursache ist, dass der Upload den Pfad tatsächlich nicht bewahrt hat. Öffnen Sie SRF Spaces im Web-Dashboard und bestätigen Sie, dass die absolute Pfadstruktur dort vorhanden ist. Wenn nicht, laden Sie erneut hoch mit aktiviertem „Auto keep local path" in der Client App.
• „Render startet, aber falsche Textur wird geladen." Manchmal hat eine Szene mehrere Assets mit demselben Dateinamen in verschiedenen Pfaden; wenn die Pfadsimulation unvollständig ist, kann der Renderer auf eine andere Datei mit demselben Namen zurückfallen. Verifizieren Sie, dass die vollständige Pfadstruktur in SRF Spaces bewahrt ist.
• „Renderer meldet Zugriff verweigert am simulierten Pfad." Dies bedeutet normalerweise, dass der Pfad einen Windows-reservierten Verzeichnisnamen enthält (con, aux, prn usw.), der nicht als regulärer Ordner erstellt werden kann. Pfaden Sie das Projekt um, um den reservierten Namen zu vermeiden.

API-Zugang

Programmatischer Zugang zu Super Renders Farm-Einreichungen steht auf der Roadmap. Eine öffentliche REST-API für Job-Einreichung, Status-Abfrage und Ausgabe-Abfrage wird entwickelt; zum jetzigen Zeitpunkt sind keine öffentlichen API-Endpunkte für direkte Integration verfügbar.

Für aktuelle programmatische Einreichungsanforderungen sind die unterstützten Pfade:

• Die SuperRenders Client App — die Desktop-Client App () kann auf Windows und macOS über ihre Kommandozeilenoberfläche (wo verfügbar) oder durch Dateiablage-Automatisierung im Upload-Verzeichnis von Skripten aus gesteuert werden. Für Studios mit etablierten Pipeline-Automatisierungs-Tools ist die Client App der aktuelle Best-Practice-Integrationspunkt.
• Das DCC-Einreichungs-Plugin — das Pro-DCC-Plugin (3ds Max, Maya, Cinema 4D) integriert sich in die eigene Skriptumgebung des DCC (MAXScript, Python usw.) und kann von Pipeline-Skripten gesteuert werden, die bereits innerhalb des DCC laufen.

Wenn die öffentliche API ausgeliefert wird, wird dieser Abschnitt durch die vollständige API-Referenz ersetzt (Authentifizierung, Endpunkte, Rate-Limits, SDK-Beispiele). Für Studios, die für ihre Pipeline-Integration auf eine öffentliche API angewiesen sind, kontaktieren Sie den Support, um den Anwendungsfall zu teilen — die Roadmap wird durch echte Pipeline-Anforderungen informiert.

Querverweise

• — Standard-Upload-Einreich-Download-Fluss ohne diese Hilfsprogramme
• — Desktop-Anwendung installieren und verwenden
• — Browser-basierter Einreichungsfluss
• — Großprojekt-Übertragungsmuster
• — wie Render-Credits abgerechnet werden, einschließlich Troubleshoot Machine-Sitzungspreise
• — DCC-übergreifende Fehlerbehebungsreferenz
• — Vergleich der Upload-Methoden
• , , — Pro-DCC-Einreichungs-Setup, das mit diesen Hilfsprogrammen kombiniert wird

FAQ

Q: Benötige ich für jeden Job eine Render-Node-Vorlage? A: Nein. Die meisten Jobs laufen auf dem Standard-Software-Stack der Farm sauber — die häufigsten DCC- und Renderer-Versionen mit den häufigsten Plugins. Eine Render-Node-Vorlage ist für Fälle gedacht, in denen Sie Versions-Pinning über ein langfristiges Projekt benötigen, oder wo Sie ein Plugin verwenden, das nicht im Standard-Katalog ist. Wenn Sie sich nicht sicher sind, ob Sie eine benötigen, ist der Standard-Stack fast immer der richtige Ausgangspunkt.

Q: Wie viel kostet eine Troubleshoot Machine-Sitzung? A: Troubleshoot Machine-Sitzungen werden gegen Ihre Render-Credits zu einem Pro-Minuten-Satz abgerechnet, der zum Sitzungsstart im Dashboard angezeigt wird. Der Satz ändert sich gelegentlich, wenn wir die zugrunde liegende VM-Infrastruktur aktualisieren; das Dashboard ist immer maßgebend. Für eine typische 30-minütige Diagnose-Sitzung erwarten Sie einen kleinen Bruchteil der Kosten eines einzigen vollständigen Render-Jobs.

Q: Kann ich Simulate Local Path verwenden, wenn mein Projekt auf macOS oder Linux ist? A: Die Worker-Render-Umgebung ist Windows, daher werden absolute Pfade als Windows-Pfade simuliert (D:\…-Form). Wenn Ihr Projekt auf macOS oder Linux mit absoluten Pfaden in /Users/…- oder /home/…-Form erstellt wurde, kann die Pfadsimulation immer noch funktionieren — die Farm erstellt eine logische Windows-Einbindung, die der vom Skript erwarteten Pfadzeichenfolge entspricht — aber in der Praxis verwenden Mac/Linux-erstellte Projekte normalerweise relative Pfade und benötigen dieses Hilfsprogramm nicht.

Q: Fügt die Render-Node-Vorlage zur Render-Zeit hinzu? A: Der erste Job, der gegen eine neue Vorlage eingereicht wird, kann ein paar Minuten länger dauern, bis er verteilt wird, während die Farm übereinstimmende Worker bereitstellt. Nachfolgende Jobs gegen dieselbe Vorlage werden mit Standard-Stack-Geschwindigkeit verteilt, weil die übereinstimmenden Worker bereits bereit sind. Die Netto-Pro-Job-Zeit, sobald die Vorlage aktiv ist, ist dieselbe wie beim Standard-Stack.

Q: Kann ich eine Render-Node-Vorlage bearbeiten, während ein Job läuft? A: Ja, aber der laufende Job setzt mit der Vorlagenversion fort, die er zum Einreichungszeitpunkt erfasst hat. Die Bearbeitung betrifft nur zukünftige Einreichungen. Für Projekte, die eine strengere Versionskontrolle benötigen, klonen Sie die Vorlage auf einen neuen Namen und aktualisieren Sie Ihre Einreichungs-Skripte, um auf den neuen Klon zu verweisen, anstatt die vorhandene Vorlage zu bearbeiten.

Q: Meine DCC-Version ist nicht im Render-Node-Vorlagen-Dropdown aufgeführt. Was nun? A: Kontaktieren Sie den Support und teilen Sie die benötigte Version mit. Für gängige DCCs hosten wir typischerweise aktuelle Versionen plus einige ältere Versionen; sehr alte Versionen können aus dem aktiven Stack zurückgezogen worden sein. Wir können normalerweise eine ältere Version mit einigen Tagen Vorlaufzeit einbinden oder Sie zur nächsten unterstützten Version führen, die Ihrer Szenenkompatibilität entspricht.

Q: Gibt es eine öffentliche API, mit der ich Jobs aus meiner Pipeline einreichen kann? A: Noch nicht. Eine öffentliche REST-API steht auf der Roadmap. Heute ist der empfohlene programmatische Einreichungspfad entweder die SuperRenders Client App (über Skripte gesteuert) oder das Pro-DCC-Einreichungs-Plugin (über die native Skriptumgebung des DCC gesteuert). Wenn Ihr Pipeline-Automatisierungs-Anwendungsfall speziell auf eine öffentliche API angewiesen ist, kontaktieren Sie den Support — die Roadmap wird durch echte Pipeline-Anforderungen informiert, und Ihr Beitrag hilft bei der Priorisierung.

Q: Kann ich eine Troubleshoot Machine gegen eine Render-Node-Vorlage ausführen? A: Ja — und dies ist das empfohlene Muster beim Debuggen eines Vorlagen-Jobs. Die Troubleshoot Machine-Sitzung liest Ihre aktive Render-Node-Vorlage zum Bereitstellungszeitpunkt und stellt die VM mit dem übereinstimmenden Software-Stack bereit. Sie sehen genau das, was der Produktions-Worker sehen würde, einschließlich der Vorlagen-Plugin-Versionen.

---