Rapid Render: configurador de productos 3D en tiempo real

Resumen rápido

• Rol: Desarrollador de software (motor 3D central, canalización de activos, integración de V-Ray SDK)
• Duración: febrero 2021 – enero 2022
• Plataforma: Unity WebGL + Escritorio
• Tecnologías principales: Unity 2020 LTS, URP, C#, Python, V-Ray SDK, glTF, Draco
• Tipos de salida: vista previa de WebGL en tiempo real, renderizado sin conexión de 1080p, exportación de escenas JSON
• Evidencia verificada: Código abierto: [Solicitud de extracción de DracoPy n.° 17] (https://github.com/seung-lab/DracoPy/pull/17). Rendimiento: carga WebGL <3 segundos / 60 FPS - prueba: [clase_dispositivo], [navegador], [escena: tri_count=[tri_count], textura_count=[texture_count], avg_asset_mb=[avg_asset_mb]]. Representación sin conexión: V-Ray 1080p ~15 min. Configuración: [muestras], [eliminar ruido], [máquina/especificaciones], [render_farm?]

Motor de renderizado y configuración 3D RapidRender

Desarrollé el motor 3D central de RapidRender dentro de Sugar Technology. Al combinar las capacidades de renderizado en tiempo real de Unity con el enfoque de trazado de rayos con calidad de producción de V-Ray, establecí una estructura híbrida que produce tanto diseño interactivo como resultados finales de alta calidad en la misma plataforma.

Problemas y limitaciones

• Objetivo para abrir escenas pesadas en WebGL con bajo tiempo de carga.
• La necesidad de normalizar formatos de activos 3D heterogéneos en un único estándar.
• Espere coherencia visual entre la vista previa en tiempo real y la salida fotorrealista sin conexión.
• Renderizar colas de trabajos y costos de retraso en la canalización fuera de línea.
• Diversidad de navegador/GPU y limitaciones de rendimiento.

Resumen de la solución

Diseñé un pipeline híbrido: producción de escenas en tiempo real de Unity + renderizado fuera de línea de V-Ray. La escena de Unity se importó al SDK de V-Ray con Python a través del formato intermedio JSON; Se logró consistencia en la calidad y al mismo tiempo se mantuvo el rendimiento web con la cartera de activos glTF/Draco.

Descripción general de la arquitectura

• Escena de Unity -> Interoperabilidad JSON -> Python -> V-Ray SDK -> Salida de renderizado de 1080p.
• Tiempo de ejecución de WebGL: compilación de Unity + transmisión de activos asincrónica + integración del panel de control.
• Mantener el esquema de etapa compatible con versiones anteriores y serialización JSON.

Canalización de activos (glTF/glb + Draco)

• Diferentes formatos de fabricantes normalizados a glTF/glb; El desenvoltorio UV, el horneado de texturas y la inyección de metadatos están automatizados.
• La coherencia de los datos se garantizó con conjuntos de reglas y validación basados ​​en Pygltflib.
• Carga asíncrona y streaming progresivo implementado con UnityGLTF.
• Tamaño de entrega WebGL optimizado con compresión Draco.

Rendimiento y optimización

• Los efectos de material, vidrio y contorno se produjeron con Shader Graph y sombreadores HLSL personalizados.
• Se implementaron sorteos de llamadas por lotes, creación de instancias de GPU, atlas de texturas y estrategias LOD.
• El ajuste iterativo del rendimiento se realizó con Unity Profiler + Frame Debugger.

V-Ray Pipeline (trabajos de renderizado)

• Escena de Unity exportada como JSON; Portado a V-Ray SDK con Python.
• La consistencia de la salida sin conexión se logró preservando el mapeo de cámara/luz/material.
• Se estableció el equilibrio calidad/tiempo con muestreo adaptativo y eliminación de ruido.
• Los trabajos de renderizado se pusieron en cola y se administraron con scripts de automatización.

Contribución de código abierto (evidencia verificada)

Preparé el PR #17, que agrega coordenadas de textura y soporte normal a DracoPy; La contribución fue aceptada en la comunidad de código abierto y se fusionó con la rama principal.

Efecto/Resultados

• Tiempo de carga de la escena WebGL - <3 segundos - contexto: [clase_dispositivo], [navegador], [escena: tri_count=[tri_count], textura_count=[texture_count], avg_asset_mb=[avg_asset_mb]], medición: [profiling_tool].
• Fluidez en tiempo real - 60 FPS - contexto: [device_class], [resolución], [escena: tri_count=[tri_count]], medición: [profiler].- Tiempo de renderizado sin conexión - 1080p ~ 15 min - configuraciones: [muestras], [eliminar ruido], [máquina/especificaciones], [render_farm?].
• Efecto de compresión Draco - (se puede agregar métrica: tasa de reducción del tamaño del paquete) - métrica: [build_size_report].
• Errores de validación de activos - (se pueden agregar métricas) - medición: registros de validación de canalización.

Pila tecnológica (Categorías)

• Motor: Unity 2020 LTS, URP, Shader Graph
• Idiomas: C#, Python 3.8, Cython
• Representación: V-Ray 5, V-Ray SDK, HDRI, IES
• Formatos: glTF 2.0, glb, Draco, Assimp
• Web: WebGL, WebAssembly, gzip/Brotli, CDN
• Datos/Interoperabilidad: JSON, Newtonsoft.Json
• Herramientas: Visual Studio, PyCharm, Unity Editor, Git

Preguntas frecuentes

¿Por qué el enfoque híbrido Unity + V-Ray?

Para satisfacer la necesidad de interacción en tiempo real y salida fotorrealista fuera de línea en la misma plataforma.

¿Por qué se eligió glTF/glb?

Porque proporciona compatibilidad web, amplio soporte de herramientas y estandarización estable.

¿Por qué Draco es crítico?

Para reducir el tiempo de carga y el tamaño del paquete en WebGL.

¿Cómo se mantenían los 60 FPS en WebGL?

Con procesamiento por lotes, creación de instancias, LOD, optimización de sombreadores y ajuste basado en perfiladores.

¿Cómo se gestionó la orquestación del trabajo de la granja de renderizado?

Los flujos de priorización/reintento se establecieron con scripts de Python y un enfoque de cola de trabajos.

¿Cómo se gestionaron el control de versiones y la migración?

Con control de versiones de esquema JSON y scripts de migración automática.

¿Cómo se garantiza la calidad de la cartera de activos?

Con validaciones de Pygltflib y reglas de metadatos.

Proyectos relacionados

• Kayra Export: Mercado y plataforma de comercio electrónico
• ABC Logistics: Plataforma de seguimiento GIS en tiempo real- Dunelm: Experiencia de "ver en la habitación" de AR compatible con LiDAR

Pie de imprenta del proyecto

• Empresa: Tecnología del Azúcar
• Posición: Desarrollador de software
• Sector: Tecnologías de Arquitectura y Diseño de Interiores
• Plataforma: Unity WebGL y escritorio
• Tecnologías principales: Unity 3D, C#, Python, V-Ray
• Formatos 3D: glTF/glb, compresión Draco
• Código abierto: Compatibilidad con coordenadas de textura y normales de DracoPy (PR n.º 17)
• Duración: Febrero 2021 – Enero 2022
• Ubicación: Estambul, Turquía
• Contribución de GitHub: Solicitud de extracción de DracoPy n.º 17