Tessera Engine

Los límites se imponen por carpetas e interfaces. Solo Platform habla con SDL3; únicamente RHI/D3D12/ incluye headers Direct3D. Render decide qué dibujar sin grabar comandos GPU. ECS, Jobs y Scene no incluyen Render/ ni RHI/; Assets y Project también permanecen independientes del renderizado.

Las bibliotecas de importación y compresión pertenecen exclusivamente a Tools/TesseraCooker. El runtime consume datos preparados sin dependencias de autoría. Las búsquedas de includes verifican esas reglas, pero compilar aporta una prueba más fuerte: Tessera.NoD3D12.sln compila motor y editor con backend nulo e interfaz SDL_Renderer. Un tipo D3D12 que escape rompe esa solución; sus builds producen cero objetos Dx*.obj.

Cada worker posee un deque Chase-Lev: apila y desapila sin lock mientras los workers inactivos roban del otro extremo. Un worker que espera un job ejecuta otras tareas en su pila actual. El test con un solo worker verifica que las dependencias progresen. Los threads externos al pool esperan pasivamente; permitirles ayudar crearía dos productores para un deque que solo admite uno.

Los jobs tienen afinidad AnyWorker, LongRunning o MainThread. Contadores separados siguen el trabajo del frame y el de larga duración, evitando que compilar shaders prolongue la espera del frame. En la comparación registrada, el frame más lento durante una recompilación bajó de 803 ms a 18,75 ms. FrameArena por worker ofrece memoria temporal; ParallelFor sobre 1.048.576 elementos produjo el resultado serial con cero asignaciones de heap.

Durante el desarrollo aparecieron tres defectos de concurrencia, uno solo con la ventana del editor visible. Un watchdog que identifica la etapa bloqueada ayudó a aislarlo. Cambiar el robo por lotes a robo por elemento trasladó ese coste al thread inactivo. Un grafo amplio de trabajo real registró 94,7% de ocupación de workers.

El cooker usa el mismo sistema: comprimir una textura 2048² llevó 311,8 s con un thread y 9,7 s con 24. Tracy y una timeline del editor muestran actividad CPU/GPU y trabajo por worker. Son mediciones específicas del proyecto, no garantías generales de throughput.

Los mesh shaders no están implementados en el renderizador. El pipeline existente deja ese camino abierto: los slots de la root signature canónica son visibles para todas las etapas, los pipelines usan pipeline state stream, DXC reconoce ms y as desde Shader Model 6.5 y la detección de capacidades consulta el soporte de la GPU.

Un test creó un pipeline de mesh shader con esa root signature. Verifica compatibilidad, no una ruta de renderizado entregada. meshoptimizer está elegido pero no integrado. El plan es que el cooker genere meshlets en un nuevo chunk .tmesh; los archivos antiguos conservarán el camino tradicional de vértices cuando falte. Los contratos del contenedor y del pipeline permiten esa extensión.

Un pase declara lecturas y escrituras de recursos, tipos de acceso y etapas GPU. El grafo ve el frame completo y deriva orden y barreras de esas declaraciones. Nunca graba comandos. El ejecutor D3D12 lee el orden y las barreras por pase y graba el trabajo correspondiente.

La compilación construye dependencias respecto al último escritor anterior, rechaza ciclos con un plan vacío, elimina productores sin uso, elige colas, calcula vidas de recursos transitorios y genera barreras cuando cambia su función. Los recursos exportados y efectos secundarios declarados preservan el trabajo necesario; importar un recurso no protege a su productor de la eliminación.

Orden de uso y tiempo de vida difieren con compute opcional: las posiciones del plan no describen ejecuciones solapadas. El grafo aporta intervalos de vida; el dueño de los heaps decide aliasing y pide sus barreras. Mi asignador empaqueta por vida, requisito que motivó rechazar el enfoque por tamaño del D3D12 Memory Allocator evaluado. Ocho recursos escalonados intencionalmente usaron 2.688 KB frente a 10.752 KB, reducción de 4,00× y el mínimo para ese test.

El grafo forward proporcionado se exportó de Sample.tscn el 6 de octubre de 2026. En esa configuración registrada, 20 pases producen 15 barreras. Seis pases desactivados de oclusión/ray tracing solo abren scopes vacíos: un pase sin escrituras no es un productor sin uso y no se elimina automáticamente. La transición destacada de SceneColor antes de ToneMapPass se deduce del cambio de render target a lectura de shader. Las cuentas varían con el camino de shading y los efectos activos.

Reset() limpia los datos del frame conservando capacidad de los vectores; los handles de recursos del grafo caducan con él. La exportación Graphviz y el panel del editor muestran el plan; --rendergraph-self-test ejecuta 242 verificaciones sin GPU.

Dear ImGui docking mantiene el editor en C++, dentro del proceso del motor. La Lobby abre un proyecto sin lanzar otra aplicación. El Content Browser tiene miniaturas renderizadas, caché en disco con invalidación automática e imports en segundo plano. Las ventanas de malla/prefab ofrecen previews GPU; el editor de texturas aísla canales y empaqueta ORM. Las propiedades de assets muestran directamente los chunks binarios.

Hierarchy, Inspector, transforms con ImGuizmo, undo/redo, prefabs, tags y colores de assets apoyan la edición de escenas. El Material Graph es una vista de solo lectura derivada de .tmat; sus conexiones no son editables. Los widgets de grafos proceden del GraphEditor de ImGuizmo.

Play, Pause, Stop y Simulate comparten los snapshots: Stop restaura el mundo capturado y verifica un hash idéntico. Las escenas de autoría usan JSON para diffs legibles en Git y se preparan en binario para runtime. Profiling, Render Graph, ECS Diagnostics y Console permiten inspeccionar los sistemas en ejecución desde el editor.

Volví a Sharpmake después de CMake para que un solo generador defina builds en IDE y línea de comandos. Sharpmake y vcpkg producen dos soluciones en Debug, Development, Profile y Shipping: ocho builds locales, todos con advertencias tratadas como errores. Las verificaciones post-build comprueban DLLs de runtime y árboles de shaders replicados.

Los tests sin ventana incluyen 4.883 verificaciones ECS, 242 de render graph y 837 del cooker. Las sondas de línea de comandos ejercitan funciones individuales; un harness compara tiempos y contadores con una baseline. Los diffs de imagen frente a la versión anterior exigen cero píxeles de escena diferentes para los criterios de aceptación de refactorizaciones descritos aquí.

Estas cifras proceden de los registros del proyecto usados para este estudio. Documentan el método y los escenarios medidos, sin representar una nueva ejecución del repositorio privado por este sitio. El build alternativo, las auditorías de replay y las comparaciones de imágenes verifican fallos distintos que un build normal correcto no bastaría para revelar.