Utilitaires avancés : Render Node Template, Troubleshoot Machine, Simulate Local Path, accès API

Super Renders Farm propose quatre utilitaires avancés destinés aux studios qui ont besoin de plus que le flux standard d'envoi par upload : Render Node Template (définissez un environnement logiciel reproductible pour les workers qui traitent votre rendu), Troubleshoot Machine (démarrez une VM de débogage accessible via RDP qui correspond à l'environnement du nœud de rendu), Simulate Local Path (conservez les chemins absolus pour les projets qui référencent leurs ressources par chemin codé en dur) et l'accès API (surface actuellement limitée — consultez §Accès API pour l'état actuel de la soumission programmatique). Cette page est le manuel de référence des quatre utilitaires : quand les utiliser, comment le mécanisme sous-jacent fonctionne sur notre render farm, les étapes précises pour configurer ou invoquer chacun, et les modes d'échec les plus fréquemment rencontrés en support.

Si vous débutez sur la render farm et cherchez le flux d'upload par défaut, le est le bon point de départ. Si vous déboguez un rendu échoué, la page couvre les erreurs les plus fréquentes. Les utilitaires documentés ici concernent les cas où le flux par défaut ne convient pas — typiquement les grands studios avec des pipelines établis, les projets aux exigences inhabituelles de chemins de ressources, ou les sessions de débogage ponctuelles où vous avez besoin de voir exactement ce que voit le worker de rendu.

Quel utilitaire utiliser — tableau de décision

Une courte orientation avant les sections par utilitaire :

| Si vous avez besoin de… | Utilisez | |---|---| | Verrouiller la version du DCC, des plugins et des licences sur les workers assignés à votre rendu | Render Node Template | | Vous connecter à un vrai worker de rendu via Microsoft Remote Desktop, corriger une scène sur place, puis la soumettre comme rendu réel | Troubleshoot Machine | | Rendre un projet qui utilise des chemins absolus (C:\projects\… ou D:\textures\…) et ne peut pas être re-patché en relatif | Simulate Local Path | | Soumettre des rendus de façon programmatique depuis un script ou un outil de pipeline | Accès API (voir note — le chemin actuel est le Client App ou le plugin DCC) |

Vous pouvez combiner ces utilitaires. Un Render Node Template peut être associé à Simulate Local Path sur le même rendu. La Troubleshoot Machine respecte à la fois votre Render Node Template actif et toute configuration Simulate Local Path, de sorte que l'environnement de débogage correspond à l'environnement de rendu en production. Les quatre utilitaires sont conçus pour se composer.

Render Node Template

Le Render Node Template est le plus puissant des quatre utilitaires et le plus anciennement disponible. Il vous permet de spécifier l'environnement logiciel exact que doivent avoir vos workers de rendu avant de traiter votre rendu : quelle version de 3ds Max, quelle build de V-Ray, quels plugins sont installés et licenciés, et tous les fichiers de configuration personnalisés qui doivent être en place sur le worker avant le démarrage du rendu. Une fois défini, le template est réutilisable d'un rendu à l'autre — chaque soumission taguée avec ce template s'exécute sur un environnement de worker identique.

Le problème qu'il résout

Par défaut, Super Renders Farm pré-installe un environnement logiciel sélectionné sur chaque worker de rendu — des versions récentes de DCC et les renderers et plugins les plus courants, calibrés sur les charges de travail que nous voyons le plus fréquemment. Pour 80 % des rendus, c'est le bon choix par défaut ; le worker dispose déjà du logiciel requis par votre scène. Mais deux situations font défaut à la configuration par défaut :

• Verrouillage de version. Votre studio s'est standardisé sur 3ds Max 2024 + V-Ray 6.10.05 + une build spécifique de Forest Pack, et vous ne pouvez pas risquer qu'un worker utilise une version point plus récente introduisant des différences d'échantillonnage ou de bruit entre les images d'une même animation.
• Plugins de niche. Vous utilisez un plugin (ou une version de plugin) qui ne figure pas dans l'environnement de la render farm par défaut — par exemple une build Phoenix FD moins courante, un pont Pulze ZBrush, ou une build Corona particulière.

Le Render Node Template vous permet de déclarer explicitement l'environnement. La render farm achemine alors votre rendu vers des workers qui correspondent déjà au template déclaré, ou provisionne de nouveaux workers pour correspondre avant d'assigner le rendu. Dans les deux cas, la garantie de verrouillage de version est bout en bout.

Fonctionnement sur notre render farm

Un Render Node Template est un enregistrement de configuration nommé, attaché à votre compte. Il contient :

• Le DCC et sa version — par exemple 3ds Max 2024.2.2.
• Le renderer et sa version — par exemple V-Ray 6.10.05.
• Une liste de plugins avec versions — par exemple Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• Un canal de licence — quelles licences (Chaos, Maxon, Otoy, AXYZ Design) doivent être disponibles sur le worker via notre infrastructure de licences mutualisée. La plupart des plugins sont couverts d'emblée ; si votre template référence un plugin que nous n'hébergeons pas encore, le support le signale et vous apportez votre propre fichier de licence.
• Des payloads de fichiers optionnels — fichiers de configuration, presets ou bibliothèques de shaders à placer à un emplacement connu sur le worker avant le démarrage du rendu.

Lorsque vous soumettez un rendu et le taguez avec un template, le scheduler de la render farm met en correspondance le template avec le pool de workers actuel. Si des workers correspondants sont disponibles, le rendu est dispatché immédiatement. Si aucun worker correspondant n'est disponible, le scheduler provisionne un worker neuf selon le template — ce qui prend généralement quelques minutes de plus qu'un rendu sur environnement par défaut, ce qui est le principal compromis.

Créer un Render Node Template

L'éditeur de template est accessible depuis votre tableau de bord sous « Render Node Templates » (ou similaire — le libellé exact peut changer entre les versions du tableau de bord ; si vous ne voyez pas l'entrée, contactez le support qui la rendra visible pour votre compte).

Étapes :

1. Connectez-vous à superrendersfarm.com et ouvrez la section Render Node Templates de votre tableau de bord.
2. Créez un nouveau template et donnez-lui un nom descriptif — typiquement un code projet ou un libellé standard du studio comme studio-archviz-2024-vray6. Le nom est libre ; la render farm ne l'utilise que pour la mise en correspondance.
3. Sélectionnez le DCC et sa version. La liste déroulante recense toutes les versions de DCC que nous hébergeons actuellement. Si votre version requise n'y figure pas, le template ne peut pas être créé sans une conversation avec le support — certaines versions legacy sont abandonnées.
4. Sélectionnez le renderer et sa version. Même contrainte — la liste reflète le stack actuel de la render farm.
5. Ajoutez les plugins un par un. Pour chaque plugin : sélectionnez-le dans le catalogue, choisissez la version, et confirmez le canal de licence. Les plugins hors catalogue nécessitent une conversation avec le support pour être ajoutés — en général un effort ponctuel si le plugin est suffisamment courant pour que nous puissions héberger la licence.
6. Joignez d'éventuels payloads de fichiers. Chargez les fichiers de configuration ou de preset dont vous avez besoin sur le worker. La render farm les stocke avec le template et les copie dans le répertoire de travail du worker avant le démarrage du rendu.
7. Enregistrez et validez. Le tableau de bord effectue une passe de validation contre le pool de workers actuel et indique soit « workers correspondants disponibles » (dispatch immédiat dès le premier rendu), soit « aucune correspondance — des workers seront provisionnés à la première utilisation » (léger délai de démarrage pour le premier rendu).

Le template est désormais disponible pour sélection lors de toute soumission ultérieure.

Utiliser un template lors de la soumission

Lorsque vous soumettez un rendu — via upload web, Client App, ou plugin de soumission DCC — le formulaire de soumission inclut une liste déroulante « Render Node Template ». Sélectionnez le template créé. Le rendu hérite de l'ensemble de la déclaration de stack ; vous n'avez pas besoin de re-spécifier le DCC, le renderer ou les versions de plugins dans le formulaire de soumission.

Deux notes opérationnelles :

• Template + priorité Express se composent. Vous pouvez soumettre un rendu templateé avec la priorité Express. Le scheduler cherche un worker disponible correspondant aux deux contraintes ; si aucun n'est disponible, il en provisionne un. Les rendus Express templateés ont généralement une fenêtre de dispatch légèrement plus longue que les rendus Express sur environnement par défaut, mais la différence de tarif est identique.
• Template + Simulate Local Path se composent. Si votre projet nécessite également des chemins absolus, configurez Simulate Local Path lors de la soumission normalement (voir §Simulate Local Path). Le template contrôle l'environnement logiciel ; Simulate Local Path contrôle la structure du système de fichiers. Ce sont des préoccupations orthogonales.

Édition et gestion des versions des templates

Un template est mutable — vous pouvez modifier le verrouillage de version, ajouter ou supprimer des plugins, ou remplacer des payloads de fichiers. Mais modifier un template affecte tous les rendus futurs qui l'utilisent ; les rendus en cours déjà dispatchés continuent avec la version du template capturée au moment de la soumission.

Pour les studios qui ont besoin d'un contrôle de version strict à travers les révisions de template, un schéma courant est le clone-puis-édition : lorsque vous devez mettre à jour des versions de plugins, clonez le template existant sous studio-archviz-2024-vray6-r2, effectuez les modifications, et mettez à jour les scripts de soumission de votre projet pour pointer vers le nouveau template. L'ancien template reste intact pour tout projet en cours qui dépend de son stack exact.

Modes d'échec courants

• « Aucun worker correspondant — provisionnement de 5-10 minutes. » Ce n'est pas une erreur, juste une information. Le premier rendu templateé après un changement de stack provisionne des workers neufs. Les rendus suivants utilisant le même template sont dispatchés immédiatement car les workers sont déjà chauds.
• « Licence de plugin non disponible pour le template. » Le plugin spécifié ne figure pas dans notre catalogue de licences hébergées. Contactez le support — pour les plugins courants, nous ajoutons généralement la licence hébergée en quelques jours ouvrés ; pour les plugins de niche, nous pouvons soit intégrer la licence, soit vous permettre de fournir un fichier de licence avec votre soumission.
• « Version du renderer non prise en charge. » Les versions anciennes de DCC ou de renderer sont périodiquement retirées du stack actif. L'éditeur de template le signale à l'enregistrement ; le correctif consiste à mettre à jour le template vers une version supportée ou à cloner-puis-éditer vers une build actuelle.
• « Rendu dispatché mais le stack du worker ne correspond pas au template. » Rare, mais important à connaître. Si cela se produit, le rendu échoue à la vérification de cohérence pré-rendu et la render farm le remet en file sur un worker confirmé correspondant automatiquement. Vous ne payez pas la tentative de dispatch échouée.

Troubleshoot Machine

La Troubleshoot Machine est le pendant diagnostique du chemin de rendu en production. Plutôt que de soumettre un rendu réel et d'attendre qu'il échoue avec un message d'erreur, vous démarrez une Troubleshoot Machine — une VM Windows correspondant à l'environnement logiciel du nœud de rendu — et vous vous y connectez via Microsoft Remote Desktop Connection. Vous voyez exactement ce que verrait le worker de rendu, pouvez ouvrir votre fichier de scène, identifier ce qui échoue, le corriger sur place, sauvegarder la scène corrigée dans votre espace de stockage, puis soumettre un rendu en production en confiance.

Le problème qu'elle résout

La plupart des échecs de rendu tombent dans deux catégories : les problèmes au niveau de la scène (un plugin manquant, une référence de ressource corrompue, un paramètre de renderer incompatible avec la version sur le worker) et les problèmes d'environnement (une licence non disponible, un plugin ne se chargeant pas, une discordance de chemins). Les deux sont difficiles à diagnostiquer à distance — le seul signal que vous obtenez d'un rendu en production échoué est le journal de rendu, qui est souvent peu explicite.

La Troubleshoot Machine compresse la boucle de diagnostic. Au lieu de soumettre → échouer → lire le journal → deviner → resoumettre → échouer → deviner → resoumettre, vous démarrez une Troubleshoot Machine, voyez l'erreur réelle dans l'interface graphique de votre DCC, la corrigez une fois, et soumettez un rendu réel qui fonctionne.

Fonctionnement sur notre render farm

Lorsque vous demandez une Troubleshoot Machine, la render farm provisionne une VM Windows neuve correspondant au stack actuel du nœud de rendu pour le DCC que vous spécifiez (et tout Render Node Template actif, le cas échéant). La VM monte votre stockage SRF Spaces comme lecteur S: — les fichiers de projet que vous avez déjà chargés apparaissent exactement comme ils le feraient sur un worker de rendu en production. Vous vous connectez via RDP depuis votre poste de travail local.

La VM dispose d'un budget de temps — généralement mesuré en minutes, facturé sur vos crédits de rendu à un tarif documenté (vérifiez le tableau de bord pour le tarif actuel ; celui-ci change occasionnellement). Lorsque vous avez terminé, vous vous déconnectez et soumettez soit un rendu en production depuis le même projet, soit libérez la VM.

Démarrer une session Troubleshoot Machine

Étapes :

1. Depuis le tableau de bord, naviguez vers « Troubleshoot Machine » (ou l'entrée équivalente du tableau de bord — le nommage peut varier entre les versions).
2. Sélectionnez le DCC correspondant à votre projet. La VM sera provisionnée avec ce DCC pré-installé et correspondant à votre Render Node Template déclaré le cas échéant.
3. Confirmez le budget de temps. Le tableau de bord indique le coût en crédits par minute ; vous vous engagez sur une durée de session maximale et pouvez la prolonger pendant la session si nécessaire.
4. Attendez le provisionnement. Cela prend généralement quelques minutes — une VM neuve est préparée avec votre stack logiciel.
5. Recevez les informations de connexion RDP. Le tableau de bord fournit un nom d'hôte, un nom d'utilisateur et un mot de passe (ou un fichier RDP téléchargeable). Sur Windows, double-cliquez sur le fichier RDP pour vous connecter ; sur macOS, utilisez Microsoft Remote Desktop depuis l'App Store.
6. Connectez-vous. Vous êtes maintenant sur le worker. Le lecteur S: contient les fichiers de projet de vos SRF Spaces.

Utilisation de la session

Une fois connecté, votre flux de travail est le même que si vous étiez devant le worker de rendu :

• Ouvrez votre fichier de scène depuis S:. Le DCC se lance dans la version spécifiée par votre template ou la version par défaut de la render farm pour ce DCC.
• Reproduisez l'échec. Quel que soit le problème en production — un aperçu de rendu, une erreur de script, une référence de ressource — il devrait se reproduire ici. Enquêtez en utilisant les propres outils de diagnostic du DCC.
• Corrigez la scène. Reconnecter les ressources manquantes, changer les paramètres de rendu, réparer les références de plugins, ou tout ce que le diagnostic requiert.
• Sauvegardez dans S:. Enregistrez la scène corrigée dans S:\SuperRendersOutput\ ou un autre dossier dans vos SRF Spaces. La sauvegarde est persistante — lorsque vous terminez la session Troubleshoot Machine, la scène corrigée reste dans votre espace de stockage.
• (Optionnel) Soumettez un rendu réel depuis la VM. Le plugin de soumission SuperRenders du DCC est installé dans la Troubleshoot Machine ; vous pouvez soumettre un rendu en production depuis la VM, puis vous déconnecter et laisser la render farm traiter normalement.

Lorsque vous avez terminé, déconnectez-vous du RDP et terminez la session depuis le tableau de bord. La VM est détruite ; tous les fichiers sauvegardés dans S: restent dans vos SRF Spaces.

Modes d'échec courants

• « Impossible de se connecter en RDP — connexion expirée. » Vérifiez que votre réseau local ou VPN autorise le RDP sortant (port 3389). Certains réseaux d'entreprise bloquent l'egress RDP. Si c'est le cas, demandez à votre équipe informatique de mettre en liste blanche le nom d'hôte de la Troubleshoot Machine.
• « Identifiants RDP refusés. » Re-téléchargez le fichier RDP depuis le tableau de bord — les identifiants sont spécifiques à la session et peuvent expirer si la session est mise en pause trop longtemps.
• « Le lecteur S: est vide ou des fichiers sont manquants. » Le lecteur pointe vers vos SRF Spaces — si des fichiers n'apparaissent pas, soit le chargement dans SRF Spaces n'était pas encore terminé quand la VM a été provisionnée, soit vous regardez dans le mauvais dossier. Le point de montage par défaut est généralement S:\<account-id>\.
• « Ma correction a fonctionné dans Troubleshoot Machine mais le rendu en production échoue toujours. » Le plus souvent, c'est parce que le rendu en production a été soumis avec un Render Node Template différent (ou l'environnement par défaut) de celui utilisé par la session Troubleshoot Machine. Vérifiez que la sélection du template dans la soumission en production correspond à la configuration de la Troubleshoot Machine.

Simulate Local Path

Simulate Local Path est le plus petit des quatre utilitaires en termes de portée, mais celui qui résout la plus grande catégorie unique de projets « impossibles à rendre dans le cloud ». Certaines scènes DCC référencent les ressources par chemin absolu codé en dur — C:\projects\studio\my-scene\textures\wood_01.tx, par exemple — plutôt que par chemin relatif. Lorsque cette scène est chargée sur une render farm, le renderer ne trouve pas les textures car le chemin absolu n'existe pas sur le worker. Simulate Local Path fait en sorte que le chemin absolu existe.

Le problème qu'il résout

La solution simple à cette catégorie de problème est de re-patcher la scène avant la soumission — passer chaque référence de ressource de l'absolu au relatif — mais pour certains workflows ce n'est pas pratique :

• Les scènes Anima (plugin de personnages animés AXYZ Design) écrivent des chemins absolus vers les fichiers de cache de personnages lors de la sauvegarde de scène ; le re-patching manuel casse la liaison de cache.
• Le rendu par cache 4K de Corona Image Editor écrit des chemins absolus que le renderer s'attend à retrouver au même emplacement au moment du rendu.
• Les workflows d'export Substance / Substance Painter peuvent incorporer des chemins absolus vers les sources de textures.
• Les références de ressources Alembic écrivent parfois des chemins absolus selon les paramètres d'export du DCC.
• Les anciens projets archivés où re-patcher chaque référence de ressource n'est pas pratique, et le studio veut simplement rendre le projet tel quel.

Pour ces cas, Simulate Local Path indique à la render farm : lorsque ce rendu s'exécute, recréez le chemin absolu sur le worker pour que le renderer trouve ses ressources là où la scène les attend.

Fonctionnement sur notre render farm

Lorsque vous chargez un projet avec Simulate Local Path activé, le Client App SuperRenders (ou l'upload web, avec le bon paramètre) préserve la structure de chemin absolu d'origine lors du chargement. Sur le worker de rendu, la render farm crée l'arborescence de répertoires correspondante au même chemin absolu avant le démarrage du rendu — ainsi, si votre fichier de scène référence D:\studio-2024\project-x\textures\wood.tx, le worker dispose d'un vrai D:\studio-2024\project-x\textures\wood.tx au moment du rendu et la scène résout correctement.

Le mécanisme est plus fiable lorsqu'il est associé à l'option « Auto keep local path » du Client App SuperRenders, qui préserve automatiquement le chemin absolu lors du chargement. Pour l'upload web, vous définissez manuellement la structure de chemin dans la structure de dossiers SRF Spaces avant de charger les fichiers.

Configurer Simulate Local Path

Il y a deux façons d'accéder à cette fonctionnalité :

Via le Client App SuperRenders (recommandé) :

1. Dans le Client App, avant d'ajouter des fichiers à un chargement, ouvrez les paramètres de chargement.
2. Activez « Auto keep local path » (le libellé exact peut légèrement changer entre les versions du Client App — cherchez la case à cocher de préservation de chemin).
3. Ajoutez vos fichiers de projet. Le Client App lit le chemin absolu de chaque fichier lors de son ajout et le préserve dans l'arborescence de chargement.
4. Confirmez l'arborescence de chemin dans l'aperçu de chargement. Vous devriez voir la structure de chemin absolu complète reflétée dans vos SRF Spaces.
5. Chargez normalement. La structure de chemin est transférée avec les fichiers.
6. Lors de la soumission, activez « Simulate Local Path » sur le rendu — le tableau de bord ou le formulaire de soumission du Client App dispose d'une case à cocher ou d'une liste déroulante pour cela. La render farm recréera le chemin absolu sur le worker.

Via l'upload web (manuel) :

1. Dans SRF Spaces (le navigateur de fichiers web dans votre tableau de bord), utilisez le bouton « Créer un dossier » pour recréer manuellement la structure de chemin absolu. Par exemple, si votre projet référence D:\studio-2024\project-x\, créez un dossier D: (littéralement, comme nom de dossier), puis un sous-dossier studio-2024, puis project-x, etc.
2. Chargez vos fichiers dans l'arborescence de chemin recréée. Chaque fichier se retrouve au chemin absolu correspondant dans SRF Spaces.
3. Lors de la soumission, activez « Simulate Local Path » sur le rendu. La render farm lira la structure de chemin depuis SRF Spaces et la reproduira sur le worker.

La voie d'upload web est plus manuelle mais fonctionne correctement lorsqu'elle est correctement configurée. Le Client App est plus rapide et moins sujet aux erreurs pour les studios qui procèdent régulièrement ainsi.

Notes opérationnelles

• Lettres de lecteur. Sur le worker de rendu, le lecteur simulé (par exemple D: si votre projet utilise D:\…) est un montage logique, pas un lecteur physique. Le montage est créé au démarrage du rendu et démonté à la fin ; il n'est pas persistant.
• Limites de longueur de chemin. Windows a des limites historiques de longueur de chemin (environ 260 caractères pour les applications legacy). Si vos chemins absolus sont très longs, certains DCC peuvent échouer à charger des fichiers même après la configuration de Simulate Local Path. Le correctif consiste soit à raccourcir les chemins au niveau du projet, soit à activer la prise en charge des longs chemins dans votre DCC, ce que la plupart des versions actuelles supportent.
• Composition inter-DCC. Simulate Local Path peut être combiné avec un Render Node Template et avec la Troubleshoot Machine — l'arborescence de chemin simulée apparaît identiquement dans les trois contextes.

Modes d'échec courants

• « Ressource toujours manquante après activation de Simulate Local Path. » La cause la plus fréquente est que le chargement n'a pas préservé le chemin. Ouvrez SRF Spaces dans le tableau de bord web et confirmez que la structure de chemin absolu y existe. Si ce n'est pas le cas, rechargez avec « Auto keep local path » activé dans le Client App.
• « Le rendu démarre mais charge la mauvaise texture. » Parfois une scène contient plusieurs ressources avec le même nom de fichier dans des chemins différents ; si la simulation de chemin est incomplète, le renderer peut revenir à un fichier différent de même nom. Vérifiez que la structure de chemin complète est préservée dans SRF Spaces.
• « Le renderer signale un accès refusé au chemin simulé. » Cela signifie généralement que le chemin implique un nom de répertoire réservé par Windows (con, aux, prn, etc.) qui ne peut pas être créé comme dossier ordinaire. Re-patchez le projet pour éviter le nom réservé.

Accès API

L'accès programmatique à la soumission Super Renders Farm est en cours de développement. Une API REST publique pour la soumission de rendus, l'interrogation du statut et la récupération des sorties est en cours de conception ; à l'heure actuelle, aucun endpoint API public n'est disponible pour l'intégration directe.

Pour les besoins actuels de soumission programmatique, les voies supportées sont :

• Le Client App SuperRenders — l'application desktop Client App () peut être pilotée depuis des scripts sur Windows et macOS via sa surface en ligne de commande (là où elle est disponible) ou par automatisation de dépôt de fichiers dans le répertoire d'upload. Pour les studios disposant d'outils d'automatisation de pipeline établis, le Client App est actuellement le meilleur point d'intégration.
• Le plugin de soumission DCC — le plugin par DCC (3ds Max, Maya, Cinema 4D) s'intègre à l'environnement de scripting propre au DCC (MAXScript, Python, etc.) et peut être piloté depuis des scripts de pipeline qui s'exécutent déjà dans le DCC.

Lorsque l'API publique sera disponible, cette section sera remplacée par la référence complète de l'API (authentification, endpoints, limites de débit, exemples SDK). Pour les studios bloqués sur une API publique pour leur intégration de pipeline, contactez le support pour partager votre cas d'usage — la feuille de route est informée par les exigences réelles de pipeline.

Références croisées

• — flux standard upload-soumission-téléchargement sans ces utilitaires
• — installation et utilisation de l'application desktop
• — comparaison des méthodes de chargement
• — facturation des crédits de rendu, dont la tarification des sessions Troubleshoot Machine
• — référence de dépannage inter-DCC
• , , — configuration de soumission par DCC qui se combine avec ces utilitaires

FAQ

Q : Ai-je besoin d'un Render Node Template pour chaque rendu ? A : Non. La plupart des rendus s'exécutent correctement avec l'environnement logiciel par défaut de la render farm — les versions les plus courantes de DCC et de renderer avec les plugins les plus fréquents. Un Render Node Template est pour les cas où vous avez besoin d'un verrouillage de version sur un projet longue durée, ou lorsque vous utilisez un plugin absent du catalogue par défaut. Si vous n'êtes pas sûr d'en avoir besoin, l'environnement par défaut est presque toujours le bon choix de départ.

Q : Combien coûte une session Troubleshoot Machine ? A : Les sessions Troubleshoot Machine sont facturées sur vos crédits de rendu à un tarif par minute affiché sur le tableau de bord au démarrage de la session. Le tarif change occasionnellement à mesure que nous mettons à jour l'infrastructure VM sous-jacente ; le tableau de bord fait toujours foi. Pour une session de diagnostic typique de 30 minutes, attendez-vous à une fraction du coût d'un seul rendu complet.

Q : Puis-je utiliser Simulate Local Path si mon projet est sur macOS ou Linux ? A : L'environnement de rendu sur le worker est Windows, donc les chemins absolus sont simulés sous forme de chemins Windows (format D:\…). Si votre projet est créé sur macOS ou Linux avec des chemins absolus de type /Users/… ou /home/…, la simulation de chemin peut toujours fonctionner — la render farm crée un montage Windows logique qui correspond à la chaîne de chemin attendue par la scène — mais en pratique les projets créés sur mac/Linux utilisent généralement des chemins relatifs et n'ont pas besoin de cet utilitaire.

Q : Le Render Node Template allonge-t-il le temps de rendu ? A : Le premier rendu soumis avec un nouveau template peut prendre quelques minutes de plus à dispatcher pendant que la render farm provisionne des workers correspondants. Les rendus suivants utilisant le même template sont dispatchés à la vitesse de l'environnement par défaut car les workers correspondants sont déjà chauds. Le temps net par rendu une fois le template actif est identique à l'environnement par défaut.

Q : Puis-je modifier un Render Node Template pendant qu'un rendu est en cours ? A : Oui, mais le rendu en cours continue avec la version du template capturée au moment de la soumission. La modification n'affecte que les soumissions futures. Pour les projets nécessitant un contrôle de version plus strict, clonez le template sous un nouveau nom et mettez à jour vos scripts de soumission pour pointer vers le nouveau clone plutôt que de modifier le template existant.

Q : La version de mon DCC n'apparaît pas dans la liste déroulante du Render Node Template. Que faire ? A : Contactez le support et indiquez la version dont vous avez besoin. Pour les DCC courants, nous hébergeons généralement les versions actuelles ainsi que quelques versions précédentes ; les versions très anciennes peuvent avoir été retirées du stack actif. Nous pouvons généralement intégrer une version précédente en quelques jours, ou vous guider vers la version supportée la plus proche compatible avec votre scène.

Q : Existe-t-il une API publique pour soumettre des rendus depuis mon pipeline ? A : Pas encore. Une API REST publique est en cours de développement. Aujourd'hui, le chemin de soumission programmatique recommandé est soit le Client App SuperRenders (piloté depuis des scripts), soit le plugin de soumission par DCC (piloté depuis l'environnement de scripting natif du DCC). Si votre cas d'automatisation de pipeline est spécifiquement bloqué sur une API publique, contactez le support — la feuille de route est informée par les exigences réelles de pipeline, et votre contribution aide à la priorisation.

Q : Puis-je exécuter une Troubleshoot Machine contre un Render Node Template ? A : Oui — et c'est le schéma recommandé lorsque vous déboguez un rendu templateé. La session Troubleshoot Machine lit votre Render Node Template actif au moment du provisionnement et provisionne la VM avec l'environnement logiciel correspondant. Vous voyez exactement ce que verrait le worker en production, y compris les versions de plugins du template.