Utilidades avanzadas: Render Node Template, Troubleshoot Machine, Simulate Local Path y acceso API

Super Renders Farm expone cuatro utilidades avanzadas para estudios que necesitan más que el flujo predeterminado de carga, envío y descarga en la web: Render Node Template (defina un entorno de software reproducible para los workers que rendericen su trabajo), Troubleshoot Machine (inicie una máquina virtual de depuración accesible por RDP que coincida con el entorno del nodo de render), Simulate Local Path (preserve rutas absolutas para proyectos que resuelven activos por ruta codificada) y el acceso API (actualmente limitado — consulte §Acceso API para la situación actual de envío programático). Esta página es el manual de referencia para las cuatro — cuándo usar cada una, cómo funciona el mecanismo subyacente en nuestra render farm, los pasos exactos para configurar o invocar cada una, y los modos de fallo que vemos con mayor frecuencia en soporte.

Si es nuevo en la render farm y busca el flujo de carga predeterminado, la es el punto de partida correcto. Si está depurando un trabajo fallido, la página de cubre los patrones de error más frecuentes. Las utilidades documentadas aquí son para casos en que el flujo predeterminado no se adapta — típicamente estudios grandes con pipelines establecidos, proyectos con requisitos de rutas de activos inusuales, o sesiones de depuración puntuales donde necesita ver exactamente lo que ve el worker de render.

Cuándo usar cada utilidad — referencia rápida

Una breve orientación antes de las secciones por utilidad:

| Si necesita… | Use | |---|---| | Fijar qué versión del DCC, versiones de plugins y licencias de plugins se ejecutan en los workers asignados a su trabajo | Render Node Template | | Conectarse a un worker de render real mediante Microsoft Remote Desktop, corregir una escena en el lugar y luego enviarla como trabajo real | Troubleshoot Machine | | Renderizar un proyecto que usa rutas absolutas (C:\projects\… o D:\textures\…) y no puede convertirse a rutas relativas | Simulate Local Path | | Enviar trabajos mediante programación desde un script o herramienta de pipeline | Acceso API (consulte el marcador de posición — la ruta actual es la Aplicación Cliente o el plugin de DCC) |

Puede combinarlas. Un Render Node Template puede combinarse con Simulate Local Path en el mismo trabajo. La Troubleshoot Machine respeta tanto su Render Node Template activo como cualquier configuración de Simulate Local Path, de modo que el entorno de depuración coincide con el entorno de render de producción. Las cuatro utilidades están diseñadas para componerse.

Render Node Template

El Render Node Template es la más potente de las cuatro utilidades y la de más larga trayectoria. Le permite especificar el entorno de software exacto que deben tener sus workers de render antes de tomar su trabajo: qué versión de 3ds Max, qué versión de V-Ray, qué plugins están instalados y licenciados, y cualquier archivo de configuración personalizado que deba estar en el worker antes de que comience el render. Una vez definida, la plantilla es reutilizable entre trabajos — cada envío que etiquete con esa plantilla se ejecuta contra un stack de workers idéntico.

Qué problema resuelve

De forma predeterminada, Super Renders Farm preinstala un stack de software seleccionado en cada worker de render — versiones recientes del DCC y los motores de render y plugins más comunes, calibrados para las cargas de trabajo que vemos con mayor frecuencia. Para el 80% de los trabajos esto es el valor predeterminado correcto; el worker ya tiene el software que necesita su escena. Pero hay dos situaciones en las que el valor predeterminado no es suficiente:

• Fijación de versión. Su estudio estandarizó en 3ds Max 2024 + V-Ray 6.10.05 + una versión específica de Forest Pack, y no puede arriesgarse a que un worker tome una versión de punto más nueva que introduzca diferencias de muestreo o ruido entre fotogramas de la misma animación.
• Plugins de nicho. Usa un plugin (o una versión de plugin) que no está en el stack predeterminado de la render farm — por ejemplo, una versión menos común de Phoenix FD, un puente de Pulze ZBrush, o una versión de función inusual de Corona.

El Render Node Template le permite declarar el stack de forma explícita. La render farm luego enruta su trabajo a workers que ya coincidan con la plantilla declarada, o provisiona nuevos workers para que coincidan antes de asignar el trabajo. De cualquier manera, la garantía de fijación de versión es de extremo a extremo.

Cómo funciona en nuestra render farm

Un Render Node Template es un registro de configuración nombrado adjunto a su cuenta. Contiene:

• El DCC y la versión — por ejemplo 3ds Max 2024.2.2.
• El motor de render y la versión — por ejemplo V-Ray 6.10.05.
• Una lista de plugins con versiones — por ejemplo Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• Un canal de licencias — qué licencias (Chaos, Maxon, Otoy, AXYZ Design) deben estar disponibles para el worker a través de nuestra infraestructura de licencias global. La mayoría de los plugins están cubiertos de serie; si su plantilla hace referencia a un plugin que aún no alojamos, soporte lo marca y usted aporta su propio archivo de licencia.
• Cargas de archivos opcionales — archivos de configuración, presets o bibliotecas de shaders que deben colocarse en una ubicación conocida en el worker antes del inicio del render.

Cuando envía un trabajo y lo etiqueta con una plantilla, el programador de la render farm coteja la plantilla con el pool de workers actual. Si hay workers coincidentes disponibles, el trabajo se despacha de inmediato. Si no hay un worker coincidente disponible, el programador provisiona uno nuevo contra la plantilla — esto suele llevar unos minutos más que un trabajo de stack predeterminado, que es la principal compensación.

Crear un Render Node Template

El editor de plantillas es accesible desde el panel de control de su cuenta en "Render Node Templates" (o similar — la etiqueta exacta de la interfaz puede cambiar entre versiones del panel de control; si no ve la entrada, contacte con soporte y la activaremos para su cuenta).

Pasos:

1. Inicie sesión en superrendersfarm.com y abra la sección Render Node Templates de su panel de control.
2. Cree una nueva plantilla y asígnele un nombre descriptivo — típicamente un código de proyecto o una etiqueta estándar del estudio como studio-archviz-2024-vray6. El nombre es suyo; la render farm solo lo usa para la coincidencia.
3. Elija el DCC y la versión. El menú desplegable lista todas las versiones del DCC que alojamos actualmente. Si su versión requerida no está en la lista, la plantilla no puede crearse contra ella sin una conversación con soporte — algunas versiones heredadas están obsoletas.
4. Elija el motor de render y la versión. Misma restricción — el menú desplegable refleja el stack actual de la render farm.
5. Añada plugins uno por uno. Para cada plugin: seleccione el nombre del plugin del catálogo, elija la versión y confirme el canal de licencias. Los plugins fuera de nuestro catálogo requieren una conversación con soporte para añadir — típicamente un esfuerzo puntual si el plugin es suficientemente convencional para que podamos alojar la licencia.
6. Adjunte cualquier carga de archivos. Cargue los archivos de configuración o preset que necesite en el worker. La render farm los almacena junto a la plantilla y los copia al directorio de trabajo del worker antes del inicio del render.
7. Guarde y valide. El panel de control ejecuta un pase de validación contra el pool de workers actual e informa "workers coincidentes disponibles" (despacho inmediato en el primer trabajo) o "sin coincidencias actuales — los workers se provisionarán en el primer uso" (ligero retraso de inicio en el primer trabajo).

La plantilla está ahora disponible para su selección en cualquier envío de trabajo posterior.

Usar una plantilla en el momento del envío

Cuando envía un trabajo de render — a través de la carga web, la Aplicación Cliente o el plugin de envío del DCC — el formulario de envío incluye un menú desplegable "Render Node Template". Seleccione la plantilla que creó. El trabajo hereda toda la declaración del stack; no necesita volver a especificar el DCC, el motor de render o las versiones de plugins en el propio formulario de envío.

Dos notas operativas:

• La plantilla + la prioridad Express se combinan. Puede enviar un trabajo con plantilla con prioridad Express. El programador intenta encontrar un worker inactivo que coincida con ambas restricciones; si ninguno está disponible, provisiona uno. Los trabajos Express con plantilla suelen tener una ventana de despacho ligeramente más larga que los trabajos Express de stack predeterminado, pero la diferencia de precio es la misma.
• La plantilla + Simulate Local Path se combinan. Si su proyecto también requiere rutas absolutas, configure Simulate Local Path en el envío de forma normal (consulte §Simulate Local Path). La plantilla controla el entorno de software; Simulate Local Path controla el diseño del sistema de archivos. Son aspectos ortogonales.

Editar y versionar plantillas

Una plantilla es mutable — puede editar la fijación de versión, añadir o eliminar plugins, o reemplazar cargas de archivos. Pero editar una plantilla afecta a todos los trabajos futuros que la usen; los trabajos en curso ya despachados continúan con la versión de la plantilla que capturaron en el momento del envío.

Para estudios que necesitan un control estricto de versiones entre revisiones de plantillas, un patrón común es clonar y luego editar: cuando necesite actualizar versiones de plugins, clone la plantilla existente a studio-archviz-2024-vray6-r2, realice los cambios allí y actualice los scripts de envío de su proyecto para apuntar a la nueva plantilla. La plantilla antigua permanece intacta para cualquier proyecto en curso que dependa de su stack exacto.

Modos de fallo comunes

• "No hay workers coincidentes — el provisionamiento tarda de 5 a 10 minutos." Esto no es un error, solo un aviso. El primer trabajo con plantilla después de un cambio de stack provisiona workers nuevos. Los trabajos posteriores contra la misma plantilla se despachan de inmediato porque los workers ya están activos.
• "Licencia del plugin no disponible para la plantilla." El plugin que especificó no está en nuestro catálogo de licencias alojadas. Contacte con soporte — para plugins convencionales generalmente añadimos licencias alojadas en unos pocos días hábiles; para plugins de nicho podemos incorporar la licencia o usted aporta un archivo de licencia con su envío.
• "La versión del motor de render ya no es compatible." Las versiones más antiguas del DCC o del motor de render se retiran del stack activo periódicamente. El editor de plantillas muestra esto al guardar; la solución es actualizar la plantilla a una versión compatible o clonar y editar a una versión actual.
• "El trabajo se despachó pero el stack del worker no coincide con la plantilla." Raro, pero vale la pena conocerlo. Si esto ocurre, el trabajo falla la comprobación de integridad previa al render y la render farm lo vuelve a poner en cola automáticamente en un worker con coincidencia confirmada. No se cobran los intentos de despacho fallidos.

Troubleshoot Machine

La Troubleshoot Machine es la contraparte de diagnóstico de la ruta de render de producción. En lugar de enviar un trabajo real y esperar a que falle con un mensaje de error, inicia una Troubleshoot Machine — una máquina virtual Windows que coincide con el stack de software del nodo de render — y se conecta a ella a través de Microsoft Remote Desktop Connection. Ve exactamente lo que vería el worker de render, puede abrir su archivo de escena, identificar qué está fallando, corregirlo en el lugar, guardar la escena corregida de vuelta en su almacenamiento y luego enviar un trabajo de producción real con confianza.

Qué problema resuelve

La mayoría de los fallos de render caen en dos categorías: problemas a nivel de escena (un plugin faltante, un activo referenciado dañado, una configuración del motor de render incompatible con la versión del worker) y problemas a nivel de entorno (una licencia no disponible, un plugin que no se carga, un desajuste de ruta). Ambos son difíciles de diagnosticar de forma remota — la única señal que obtiene de un trabajo de producción fallido es el registro de render, que a menudo es escueto.

La Troubleshoot Machine comprime el ciclo de diagnóstico. En lugar de enviar → fallar → leer registro → adivinar → reenviar → fallar → adivinar → reenviar, inicia una Troubleshoot Machine, ve el error real en la interfaz gráfica de su DCC, lo corrige una vez y envía un trabajo real que funciona.

Cómo funciona en nuestra render farm

Cuando solicita una Troubleshoot Machine, la render farm provisiona una nueva máquina virtual Windows que coincide con el stack actual del nodo de render para el DCC que especifique (y cualquier Render Node Template activo, si tiene uno). La máquina virtual monta su almacenamiento de SRF Spaces como la unidad S: — así que los archivos de proyecto que ya ha cargado aparecen exactamente como lo harían en un worker de render de producción. Se conecta mediante RDP desde su estación de trabajo local.

La máquina virtual tiene un presupuesto de tiempo — típicamente medido en minutos, facturado contra sus créditos de render a una tasa documentada (consulte el panel de control para la tasa actual; esto cambia ocasionalmente). Cuando termina, se desconecta y envía un trabajo de producción desde el mismo proyecto o libera la máquina virtual.

Iniciar una sesión de Troubleshoot Machine

Pasos:

1. Desde el panel de control, navegue a "Troubleshoot Machine" (o la entrada equivalente del panel de control — el nombre puede variar entre versiones).
2. Seleccione el DCC que coincide con su proyecto. La máquina virtual se provisionará con ese DCC preinstalado y coincidiendo con su Render Node Template declarado si tiene uno.
3. Confirme el presupuesto de tiempo. El panel de control muestra el costo de crédito por minuto; se compromete a una duración máxima de sesión y puede extenderla durante la sesión si es necesario.
4. Espere el provisionamiento. Esto normalmente tarda unos minutos — se está preparando una nueva máquina virtual con su stack de software.
5. Reciba los datos de conexión RDP. El panel de control proporciona un nombre de host, nombre de usuario y contraseña (o un archivo RDP descargable). En Windows, haga doble clic en el archivo RDP para conectarse; en macOS, use Microsoft Remote Desktop de la App Store.
6. Conéctese. Ahora está en el worker. La unidad S: contiene los archivos de proyecto de SRF Spaces.

Usar la sesión

Una vez conectado, su flujo de trabajo es el mismo que si estuviera sentado frente al worker de render:

• Abra su archivo de escena desde S:. El DCC se inicia en la versión especificada por su plantilla o el valor predeterminado de la render farm para ese DCC.
• Reproduzca el fallo. Lo que fuera que estaba fallando en producción — una vista previa de render, un error de script, una referencia de activo — debería reproducirse aquí. Investigue usando las propias herramientas de diagnóstico del DCC.
• Corrija la escena. Vuelva a vincular los activos faltantes, cambie la configuración del render, repare las referencias del plugin, o lo que requiera el diagnóstico.
• Guarde de vuelta en S:. Guarde la escena corregida en S:\SuperRendersOutput\ u otra carpeta en su SRF Spaces. El guardado es persistente — cuando finaliza la sesión de Troubleshoot Machine, la escena corregida permanece en su almacenamiento.
• (Opcional) Envíe un trabajo real desde dentro de la máquina virtual. El plugin de envío del DCC de SuperRenders está instalado dentro de la Troubleshoot Machine; puede enviar un trabajo de render de producción desde dentro de la máquina virtual, luego desconectarse y dejar que la render farm renderice normalmente.

Cuando haya terminado, desconéctese del RDP y finalice la sesión desde el panel de control. La máquina virtual se destruye; los archivos que guardó en S: permanecen en su SRF Spaces.

Modos de fallo comunes

• "No se puede conectar al RDP — tiempo de espera de conexión agotado." Compruebe que su red local o VPN permita el RDP saliente (puerto 3389). Algunas redes corporativas bloquean el egreso de RDP. Si es el caso, pida a su equipo de TI que incluya en la lista blanca el nombre de host de la Troubleshoot Machine.
• "Credenciales de RDP rechazadas." Vuelva a descargar el archivo RDP desde el panel de control — las credenciales son específicas de la sesión y pueden expirar si la sesión se pausa demasiado tiempo.
• "La unidad S: está vacía o faltan archivos." La unidad se mapea a su SRF Spaces — si los archivos no aparecen, la carga a SRF Spaces aún no había completado cuando se provisionó la máquina virtual, o está viendo la carpeta incorrecta. El montaje predeterminado es típicamente S:\<id-de-cuenta>\.
• "Mi corrección funcionó en la Troubleshoot Machine pero el trabajo de producción sigue fallando." La mayoría de las veces esto se debe a que el trabajo de producción se envió con un Render Node Template diferente (o stack predeterminado) al que usó la sesión de Troubleshoot Machine. Verifique que la selección de plantilla en el envío de producción coincida con la configuración de la Troubleshoot Machine.

Simulate Local Path

Simulate Local Path es la más pequeña de las cuatro utilidades en alcance, pero la que resuelve la mayor categoría individual de proyectos que "no pueden renderizarse en la nube". Algunas escenas del DCC resuelven activos por ruta absoluta codificada — C:\projects\studio\my-scene\textures\wood_01.tx, por ejemplo — en lugar de por ruta relativa. Cuando esa escena se carga en un render farm, el motor de render no puede encontrar las texturas porque la ruta absoluta no existe en el worker. Simulate Local Path hace que la ruta absoluta exista.

Qué problema resuelve

La solución directa a esta categoría de problemas es volver a vincular la escena antes del envío — cambiar cada referencia de activo de absoluta a relativa — pero para algunos flujos de trabajo esto no es práctico:

• Las escenas de Anima (el plugin de personas animadas de AXYZ Design) escriben rutas absolutas a los archivos de caché de personajes en el momento de guardar la escena; la revinculación manual rompe el enlace de caché.
• El rendering de caché 4K de Corona Image Editor escribe rutas absolutas que el motor de render espera encontrar de nuevo en la misma ruta en el momento del render.
• Los flujos de trabajo de exportación de Substance / Substance Painter pueden incrustar rutas absolutas a las fuentes de textura.
• Las referencias de activos de Alembic a veces escriben rutas absolutas según la configuración de exportación del DCC.
• Los proyectos de archivo antiguos donde volver a vincular cada referencia de activo es impracticable y el estudio simplemente quiere que el proyecto se renderice tal como está.

Para estos casos, Simulate Local Path le dice a la render farm: cuando se ejecute este trabajo, recree la ruta absoluta en el worker para que el motor de render encuentre sus activos donde la escena los espera.

Cómo funciona en nuestra render farm

Cuando carga un proyecto con Simulate Local Path habilitado, la Aplicación Cliente de SuperRenders (o la carga web, con la configuración correcta) preserva la estructura original de ruta absoluta en la carga. En el worker de render, la render farm crea el árbol de directorios correspondiente en la misma ruta absoluta antes del inicio del render — por lo que si su archivo de escena hace referencia a D:\studio-2024\project-x\textures\wood.tx, el worker tiene un D:\studio-2024\project-x\textures\wood.tx real en el momento del render y la escena se resuelve correctamente.

El mecanismo es más fiable cuando se combina con la opción "Auto keep local path" de la Aplicación Cliente de SuperRenders, que preserva la ruta absoluta automáticamente durante la carga. Para la carga web, usted establece la estructura de ruta manualmente en la estructura de carpetas de SRF Spaces antes de cargar los archivos.

Configurar Simulate Local Path

Hay dos formas de acceder a esta función:

Mediante la Aplicación Cliente de SuperRenders (recomendado):

1. En la Aplicación Cliente, antes de añadir archivos a una carga, abra la configuración de carga.
2. Habilite "Auto keep local path" (la etiqueta exacta puede variar ligeramente entre versiones de la Aplicación Cliente — busque la casilla de preservación de ruta).
3. Añada sus archivos de proyecto. La Aplicación Cliente lee la ruta absoluta de cada archivo a medida que se añade y la preserva en el árbol de carga.
4. Confirme el árbol de rutas en la vista previa de carga. Debería ver la estructura de ruta absoluta completa reflejada en su SRF Spaces.
5. Cargue normalmente. La estructura de rutas se transfiere junto con los archivos.
6. En el momento del envío, habilite "Simulate Local Path" en el trabajo — el formulario de envío del panel de control o de la Aplicación Cliente tiene una casilla de verificación o menú desplegable para esto. La render farm recreará la ruta absoluta en el worker.

Mediante la carga web (manual):

1. En SRF Spaces (el navegador de archivos web dentro del panel de control de su cuenta), use el botón "Crear carpeta" para recrear manualmente la estructura de ruta absoluta. Por ejemplo, si su proyecto hace referencia a D:\studio-2024\project-x\, cree una carpeta D: (literalmente, como nombre de carpeta), luego una subcarpeta studio-2024, luego project-x, y así sucesivamente.
2. Cargue sus archivos en el árbol de rutas recreado. Cada archivo termina en la ruta absoluta correspondiente dentro de SRF Spaces.
3. En el momento del envío, habilite "Simulate Local Path" en el trabajo. La render farm leerá la estructura de rutas de SRF Spaces y la replicará en el worker.

La ruta de carga web es más manual pero funciona correctamente cuando se configura. La Aplicación Cliente es más rápida y menos propensa a errores para estudios que hacen esto con regularidad.

Notas operativas

• Letras de unidad. En el worker de render, la unidad simulada (por ejemplo, D: si su proyecto usa D:\…) es un montaje lógico, no una unidad física. El montaje se crea al inicio del trabajo y se desmonta al finalizarlo; no es persistente.
• Límites de longitud de ruta. Windows tiene límites históricos de longitud de ruta (alrededor de 260 caracteres para aplicaciones heredadas). Si sus rutas absolutas son muy largas, algunos DCCs pueden fallar al cargar archivos incluso después de configurar Simulate Local Path. La solución es acortar las rutas a nivel del proyecto o habilitar la compatibilidad con rutas largas en su DCC, que admite la mayoría de las versiones actuales.
• Composición entre DCCs. Simulate Local Path puede combinarse con un Render Node Template y con la Troubleshoot Machine — el árbol de rutas simulado aparece de forma idéntica en los tres contextos.

Modos de fallo comunes

• "El activo sigue faltando después de habilitar Simulate Local Path." La causa más común es que la carga no preservó realmente la ruta. Abra SRF Spaces en el panel de control web y confirme que la estructura de ruta absoluta existe allí. Si no existe, vuelva a cargar con "Auto keep local path" habilitado en la Aplicación Cliente.
• "El render comienza pero se carga la textura incorrecta." A veces una escena tiene varios activos con el mismo nombre de archivo en rutas diferentes; si la simulación de ruta está incompleta, el motor de render puede recaer en un archivo diferente con el mismo nombre. Verifique que la estructura de ruta completa esté preservada en SRF Spaces.
• "El motor de render informa acceso denegado en la ruta simulada." Esto generalmente significa que la ruta implica un nombre de directorio reservado de Windows (con, aux, prn, etc.) que no puede crearse como carpeta normal. Vuelva a vincular el proyecto para evitar el nombre reservado.

Acceso API

El acceso programático a Super Renders Farm para el envío de trabajos está en la hoja de ruta. Se está diseñando una API REST pública para el envío de trabajos, el sondeo de estado y la recuperación de salida; en este momento no hay endpoints de API públicos disponibles para integración directa.

Para las necesidades actuales de envío programático, las rutas compatibles son:

• La Aplicación Cliente de SuperRenders — la Aplicación Cliente de escritorio () puede ser controlada desde scripts en Windows y macOS a través de su superficie de línea de comandos (donde esté disponible) o mediante automatización de caída de archivos en el directorio de carga. Para estudios con herramientas de automatización de pipeline establecidas, la Aplicación Cliente es el punto de integración de mejores prácticas actual.
• El plugin de envío del DCC — el plugin por DCC (3ds Max, Maya, Cinema 4D) se integra con el propio entorno de scripting del DCC (MAXScript, Python, etc.) y puede ser controlado desde scripts de pipeline que ya se ejecutan dentro del DCC.

Cuando se lance la API pública, esta sección será reemplazada por la referencia de API completa (autenticación, endpoints, límites de velocidad, ejemplos de SDK). Para estudios que están bloqueados en una API pública para su integración de pipeline, contacte con soporte para compartir el caso de uso — la hoja de ruta está informada por requisitos reales de pipeline.

Referencias cruzadas

• — flujo predeterminado de carga, envío y descarga sin estas utilidades
• — instalación y uso de la aplicación de escritorio
• — flujo de envío basado en navegador
• — patrón de transferencia para proyectos grandes
• — cómo se facturan los créditos de render, incluido el precio de las sesiones de Troubleshoot Machine
• — referencia de solución de problemas entre DCCs
• — comparación de métodos de carga
• , , — configuración de envío por DCC que se combina con estas utilidades

FAQ

Q: ¿Necesito un Render Node Template para cada trabajo? A: No. La mayoría de los trabajos se ejecutan correctamente en el stack de software predeterminado de la render farm — las versiones más comunes del DCC y el motor de render con los plugins más comunes. Un Render Node Template es para casos en que necesita fijación de versión en un proyecto de larga duración, o cuando usa un plugin que no está en el catálogo predeterminado. Si no está seguro de si lo necesita, el stack predeterminado es casi siempre el punto de partida correcto.

Q: ¿Cuánto cuesta una sesión de Troubleshoot Machine? A: Las sesiones de Troubleshoot Machine se facturan contra sus créditos de render a una tasa por minuto que se muestra en el panel de control al inicio de la sesión. La tasa cambia ocasionalmente a medida que actualizamos la infraestructura de máquinas virtuales subyacente; el panel de control siempre es la fuente autorizada. Para una sesión de diagnóstico típica de 30 minutos, espere una pequeña fracción del costo de un trabajo de render completo.

Q: ¿Puedo usar Simulate Local Path si mi proyecto está en macOS o Linux? A: El entorno de render del worker es Windows, por lo que las rutas absolutas se simulan como rutas de Windows (formato D:\…). Si su proyecto está creado en macOS o Linux con rutas absolutas en forma /Users/… o /home/…, la simulación de rutas puede funcionar — la render farm crea un montaje lógico de Windows que coincide con la cadena de ruta que espera la escena — pero en la práctica los proyectos creados en mac/Linux suelen usar rutas relativas y no necesitan esta utilidad.

Q: ¿El Render Node Template añade tiempo de render? A: El primer trabajo enviado contra una nueva plantilla puede tardar unos minutos más en despacharse mientras la render farm provisiona workers coincidentes. Los trabajos posteriores contra la misma plantilla se despachan a la velocidad del stack predeterminado porque los workers coincidentes ya están activos. El tiempo neto por trabajo una vez que la plantilla está activa es el mismo que el del stack predeterminado.

Q: ¿Puedo editar un Render Node Template mientras hay un trabajo en curso? A: Sí, pero el trabajo en curso continúa con la versión de la plantilla que capturó en el momento del envío. La edición solo afecta a los envíos futuros. Para proyectos que necesitan un control de versiones más estricto, clone la plantilla a un nuevo nombre y actualice sus scripts de envío para apuntar al nuevo clon en lugar de editar la plantilla existente.

Q: La versión de mi DCC no aparece en el menú desplegable de Render Node Template. ¿Qué hago? A: Contacte con soporte e indique la versión que necesita. Para DCCs convencionales generalmente alojamos versiones actuales más algunas versiones anteriores; las versiones muy antiguas pueden haber sido retiradas del stack activo. Generalmente podemos incorporar una versión anterior con unos días de antelación, o guiarle a la versión compatible más cercana que coincida con la compatibilidad de su escena.

Q: ¿Hay una API pública que pueda usar para enviar trabajos desde mi pipeline? A: Todavía no. Una API REST pública está en la hoja de ruta. Hoy, la ruta de envío programático recomendada es la Aplicación Cliente de SuperRenders (controlada desde scripts) o el plugin de envío por DCC (controlado desde el entorno de scripting nativo del DCC). Si su caso de uso de automatización de pipeline está bloqueado específicamente en una API pública, contacte con soporte — la hoja de ruta está informada por requisitos reales de pipeline, y su opinión ayuda a priorizar.

Q: ¿Puedo ejecutar una Troubleshoot Machine contra un Render Node Template? A: Sí — y este es el patrón recomendado cuando está depurando un trabajo con plantilla. La sesión de Troubleshoot Machine lee su Render Node Template activo en el momento del provisionamiento y provisiona la máquina virtual con el stack de software coincidente. Ve exactamente lo que vería el worker de producción, incluidas las versiones de plugin de la plantilla.

---