Tessera Engine

As fronteiras são impostas por pastas e interfaces. Só Platform fala com SDL3; apenas RHI/D3D12/ inclui headers Direct3D. Render decide o que desenhar sem gravar comandos na GPU. ECS, Jobs e Scene não incluem Render/ nem RHI/; Assets e Project também permanecem independentes da renderização.

Bibliotecas de importação e compressão pertencem exclusivamente a Tools/TesseraCooker. O runtime consome dados cozidos sem carregar dependências de autoria. Buscas de includes verificam essas regras, mas a compilação oferece uma prova mais forte: Tessera.NoD3D12.sln compila motor e editor com backend nulo e interface SDL_Renderer. Um tipo D3D12 que vaze quebra essa solução; seus builds produzem zero objetos Dx*.obj.

Cada worker possui um deque Chase-Lev: empilha e desempilha sem lock, enquanto workers ociosos roubam da outra ponta. Um worker que espera um job executa outros trabalhos na própria pilha. O teste com um único worker verifica que as dependências continuam progredindo. Threads externas ao pool esperam passivamente; deixá-las ajudar criaria dois produtores para um deque que admite apenas um.

Jobs têm afinidade AnyWorker, LongRunning ou MainThread. Contadores separados acompanham trabalho do quadro e de longa duração, para a compilação de shader não prolongar a espera do quadro. Na comparação registrada, o quadro mais lento durante uma recompilação caiu de 803 ms para 18,75 ms. FrameArena por worker oferece alocação temporária; ParallelFor sobre 1.048.576 elementos produziu o resultado serial com zero alocações de heap.

Três defeitos de concorrência apareceram no desenvolvimento, incluindo um que só ocorria com a janela do editor visível. Um watchdog que nomeia o estágio travado ajudou a isolá-lo. Trocar o roubo em lote pelo roubo por elemento transferiu esse custo para a thread ociosa. Um grafo largo de trabalho real registrou 94,7% de ocupação dos workers.

O cooker usa o mesmo sistema: comprimir uma textura 2048² levou 311,8 s com uma thread e 9,7 s com 24. Tracy e uma timeline no editor expõem atividade de CPU/GPU e trabalho por worker. São medições específicas do projeto, não garantias gerais de throughput.

Mesh shaders não estão implementados no renderizador. O pipeline existente mantém esse caminho aberto: slots da root signature canônica são visíveis a todos os estágios, pipelines usam pipeline state stream, DXC reconhece ms e as no Shader Model 6.5 ou posterior e a detecção de capacidades consulta o suporte da GPU.

Um teste criou com sucesso um pipeline de mesh shader contra a root signature canônica. Isso verifica compatibilidade, não um caminho de renderização entregue. meshoptimizer está escolhido, mas não integrado. O plano é o cooker gerar meshlets em um novo chunk do .tmesh; arquivos antigos manterão o caminho tradicional de vértices quando o chunk estiver ausente. Os contratos do contêiner e do pipeline viabilizam essa extensão.

Um passe declara leituras e escritas de recursos, tipos de acesso e estágios da GPU. O grafo vê todo o quadro e deriva ordem e barreiras dessas declarações. Nunca grava comandos. O executor D3D12 lê a ordem de execução e as barreiras por passe e então grava o trabalho correspondente.

A compilação monta dependências contra o último escritor anterior, rejeita ciclos com um plano vazio, remove produtores sem uso, seleciona filas, calcula vidas de transitórios e gera barreiras quando o papel do recurso muda. Recursos exportados e efeitos colaterais declarados preservam trabalho necessário; apenas importar um recurso não protege seu produtor da remoção.

Ordem de uso e tempo de vida diferem com compute opcional: posições no plano não descrevem execuções sobrepostas. O grafo fornece intervalos de vida; o dono dos heaps decide aliasing e pede suas barreiras. Meu alocador empacota por vida, requisito que levou à recusa da abordagem por tamanho do D3D12 Memory Allocator avaliado. Oito recursos deliberadamente escalonados usaram 2.688 KB em vez de 10.752 KB, redução de 4,00× e o mínimo para esse teste.

O grafo forward fornecido foi exportado do Sample.tscn em 6 de outubro de 2026. Nessa configuração registrada, 20 passes produzem 15 barreiras. Seis passes desligados de oclusão/ray tracing só abrem escopos vazios: um passe sem escritas não é um produtor sem uso e não é removido automaticamente. A transição destacada de SceneColor antes de ToneMapPass é deduzida da mudança de render target para leitura de shader. As contagens variam com o caminho de shading e os efeitos ativos.

Reset() limpa os dados do quadro preservando a capacidade dos vetores; os handles de recursos do grafo expiram com ele. A exportação Graphviz e o painel do editor expõem o plano; --rendergraph-self-test executa 242 verificações sem GPU.

Dear ImGui docking mantém o editor em C++, no processo do motor. A Lobby abre um projeto sem iniciar outro aplicativo. O Content Browser tem miniaturas renderizadas, cache em disco com invalidação automática e imports em segundo plano. Janelas de malha/prefab oferecem previews na GPU; o editor de textura isola canais e empacota ORM. As propriedades dos assets mostram diretamente os chunks binários.

Hierarchy, Inspector, transforms com ImGuizmo, undo/redo, prefabs, tags e cores por asset apoiam a edição de cenas. O Material Graph é uma visualização de leitura derivada do .tmat; sua fiação não é editável. Os widgets dos grafos vêm do GraphEditor do ImGuizmo.

Play, Pause, Stop e Simulate compartilham o mecanismo de snapshot: Stop restaura o mundo capturado e verifica seu hash idêntico. Cenas de autoria usam JSON para diffs legíveis no Git e são cozidas em binário para runtime. Profiling, Render Graph, ECS Diagnostics e Console permitem inspecionar os sistemas em execução no editor.

Voltei ao Sharpmake depois do CMake para um único gerador definir builds na IDE e na linha de comando. Sharpmake e vcpkg produzem duas soluções em Debug, Development, Profile e Shipping: oito builds locais, todos com avisos tratados como erros. Verificadores pós-build conferem DLLs de runtime e árvores de shaders espelhadas.

Testes por subsistema sem janela incluem 4.883 verificações do ECS, 242 do render graph e 837 do cooker. Sondas de linha de comando exercitam recursos individuais; um harness compara tempos e contadores com uma baseline. Os diffs de imagem contra a versão anterior exigem zero pixels diferentes na cena para os critérios de aceitação das refatorações descritos aqui.

Os números vêm dos registros do projeto usados neste estudo. Documentam o método de validação e os cenários medidos, sem representar uma nova execução do repositório privado por este site. O build alternativo, as auditorias de replay e as comparações de imagem verificam falhas diferentes que apenas um build normal bem-sucedido não revelaria.