Lançamento de Julho de 2026
Se junho serviu para construir os alicerces, julho foi o mês de dar vida aos ambientes.
Foram dezenove lançamentos ao longo de trinta dias — incluindo dois saltos de versão major — com um vigésimo, a v3.4.0, desembarcando logo nos primeiros dias de agosto. O Turian Studio deixou de ser apenas um editor funcional para se tornar um ambiente onde realmente dá gosto de trabalhar o dia todo.
Mas a grande história de julho não é meramente uma lista de recursos. É a história de uma única cena.
Por volta do meio do mês, colocamos o Turian à prova com a famosa cena Amazon Lumberyard Bistro — 2,8 milhões de triângulos, 1.591 sub-meshes, 132 materiais, 633 texturas comprimidas e 1,4 GB de arquivos de arte brutos. Ele renderizou exatas 32 superfícies e jogou a toalha. Tudo o que veio a seguir — o suporte a FBX, o culling, a reformulação das sombras, a infraestrutura de profiling e até um dos saltos de versão major — derivou do esforço direto para fazer essa cena carregar, renderizar e rodar de forma fluida.
- Um Studio Onde Dá Gosto de Trabalhar
- Jogos com Rosto: GUI In-Game
- O Renderizador Amadurece
- A Epopeia do Bistro
- Importação: Muito Além do glTF
- Multiplataforma: A Chegada do Windows
- Saltos de Versão Sem Drama
- Preparando o Terreno
- Olhando para o Futuro
Um Studio Onde Dá Gosto de Trabalhar
O editor de junho era funcional; o de julho é verdadeiramente confortável.
Painéis Encaixáveis
Ticket #90
A maior mudança individual no fluxo de trabalho do Studio: os painéis já não ficam travados em posições fixas. Agora você pode arrastar, encaixar (dock), desencaixar, dividir e reorganizar qualquer painel — Hierarquia, Scene View, Game View, Inspetor, Asset Browser, Profiler e Log — criando o layout ideal para o seu projeto.
O layout é salvo entre as sessões, então basta configurá-lo uma vez. Se quiser recomeçar, o botão "Reset Layout" restaura os padrões instantaneamente. Presets integrados (Default, 4 Split, 2x3, Tall, Wide) oferecem pontos de partida rápidos para diferentes tarefas — seja editar uma cena, depurar a UI ou analisar a performance.
Nos bastidores, uma nova API de Painéis permite que plugins e pacotes registrem seus próprios painéis customizados. O sistema de composição do editor deixou de ser rígido (hardcoded); qualquer ferramenta ou visualizador futuro pode se integrar como uma janela encaixável de primeira classe.
O Painel de Boas-Vindas
Abrir o Studio sem um projeto antes resultava em uma Hierarquia vazia e uma viewport em branco. Agora você é recebido pelo painel de Boas-Vindas: lista de projetos recentes com seus respectivos caminhos, botões de destaque para Novo Projeto e Abrir Projeto, a versão da engine e links diretos para a documentação, blog, changelog, Discord, Matrix e rastreador de issues.
Ele se comporta como qualquer outro painel — pode ser encaixado ou fechado —, mas funciona como a visualização padrão quando nenhum projeto está carregado, saindo de cena no instante em que um projeto é aberto.
O menu suspenso de projetos na barra superior também evoluiu. Cada projeto recente agora conta com a opção de "abrir em uma nova janela", permitindo trabalhar com dois projetos lado a lado. Além disso, ao tentar trocar de projeto com alterações não salvas, o editor solicita confirmação antes. Essa verificação de alterações pendentes (dirty-check) utiliza uma API interna compartilhada em vez de um remendo no manipulador de fechar janela. Assim, qualquer ação que possa causar perda de trabalho — fechar o editor, trocar de projeto ou abrir uma nova janela — faz a mesma checagem de segurança.
Temas
Dark, Light, Dark High Contrast, Darcula e Catppuccin — cinco temas já vêm inclusos por padrão e podem ser visualizados em tempo real no menu View. Basta passar o cursor sobre o nome do tema para ter uma pré-visualização imediata; clique para confirmar e aplicar.
O tipo de asset .uitheme torna os temas recursos editáveis de primeira classe. É possível criar seu próprio tema duplicando um existente e ajustando cores, arredondamento de cantos e largura das bordas dos painéis — tudo editável pelo Inspector com pré-visualização ao vivo.
Os temas podem ser importados e exportados como arquivos, facilitando o compartilhamento da identidade visual da equipe no estúdio. A mesma infraestrutura gerencia o tamanho da fonte, o zoom da interface e a substituição opcional da fonte do sistema — ajustáveis por sessão no menu View ou de forma permanente nas configurações (Settings).
Arraste o controle deslizante para comparar os temas Dark e Light no mesmo layout do editor:
O Painel de Log
Ticket #23
Qualquer engine imprime mensagens no stdout. Um editor profissional permite encontrar exatamente o que você procura.
O novo painel de Log captura todas as mensagens da engine e do editor em um console encaixável. Ele conta com filtros por nível de log (Debug, Info, Warning, Error), menus suspensos por categoria e busca por texto. Mensagens idênticas consecutivas são agrupadas em uma única linha com contador de repetições — algo indispensável ao depurar loops intensos. Além disso, as stack traces de erro são simbolizadas e expansíveis automaticamente, oferecendo links clicáveis no formato arquivo:linha.
Agora você pode manter o painel de log encaixado na parte inferior da tela sem atrapalhar seu espaço de trabalho, encontrando rapidamente a origem dos problemas em meio ao ruído de mensagens.
Editor de Configurações Unificado
Ticket #88
As configurações do Studio costumavam ficar espalhadas por diversos locais — arquivos JSON, menus de painéis individuais e padrões não documentados. Julho trouxe um editor de Configurações (Settings) de verdade, que se abre como uma aba convencional com barra lateral pesquisável, categorias bem organizadas (General, Editor Camera, Asset Browser, UI, Performance, Shortcuts) e rastreamento de modificações em tempo real com indicador de estado pendente (dirty).
O editor reaproveita a mesma infraestrutura de reflexão e widgets de propriedades do Inspector. Com isso, cada campo de configuração se beneficia das mesmas validações, editores específicos por tipo e rastreamento de alterações utilizados pelas propriedades dos assets.
Asset Browser e Pré-visualização de Assets
Tickets #79, #80, #83, #81, #68, #85, #72, #84, #19, #25
O Asset Browser ganhou três modos de navegação este mês — Grid (miniaturas em grade), Grid+Tree (grade com barra lateral de pastas) e Tree Only (árvore completa de pastas e arquivos) —, alternáveis por um ícone prático na barra de ferramentas. A barra de navegação estilo breadcrumbs agora é clicável para subir de nível rapidamente, e o menu Criar (Create) foi organizado em submenus categorizados em vez de uma lista longa e plana.
As células da grade agora têm largura fixa. Assim, uma pasta com 600 texturas é exibida como um mosaico uniforme e organizado, em vez de uma grade irregular moldada pelo tamanho dos nomes de arquivos. Nomes muito longos são truncados (exibindo o nome completo ao passar o cursor sobre o item), as extensões podem ser ocultadas e o tamanho das células acompanha o nível de zoom. Sub-assets — como meshes, materiais e prefabs gerados a partir de um modelo importado — podem ser expandidos diretamente a partir de um ícone + no item principal.
Junto com essas melhorias, chegaram as miniaturas de pré-visualização de assets: ao selecionar um item, o Inspector exibe uma visualização rápida compatível com texturas, modelos e materiais. O sistema de preview é extensível através da arquitetura de plugins, permitindo que tipos de assets customizados forneçam seus próprios renderizadores de pré-visualização.
Mapeamento de Atalhos e Registro de Comandos
Ticket #14
Os atalhos de teclado agora formam um sistema completo de primeira classe. Um registro central de comandos mapeia todas as ações do editor — Desfazer, Refazer, Salvar, Play/Stop, Build Game, Próxima Aba — às suas teclas padrão. Os usuários podem reatribuir qualquer atalho usando um editor dedicado em Settings, adicionar atalhos secundários ou remover a atribuição de um comando por completo. Há detecção automática de conflitos: se dois comandos tentarem utilizar a mesma combinação de teclas, o editor sinaliza o problema na hora.
Os atalhos ativos são exibidos ao lado dos respectivos itens de menu, dispensando a necessidade de memorizar as combinações de teclas.
Gizmo de Orientação da Scene View
Ticket #126
A Scene View recebeu um gizmo giroscópico no canto superior direito — o seletor de eixos familiar para quem utiliza Blender, Unity ou Unreal. Ele gira acompanhando a orientação da câmera no espaço do mundo, garantindo que você nunca perca a referência de orientação ao navegar por uma cena complexa.
Mas ele não serve apenas como indicador visual. Clicar em uma das faces do gizmo alinha instantaneamente a câmera ao longo daquele eixo, mantendo o ponto de foco centralizado. Com isso, alternar para uma vista frontal, lateral ou superior exige apenas um clique em vez de ajustes manuais de câmera. O seletor do modo de projeção fica logo abaixo, permitindo alternar entre perspectiva e ortográfica com um único clique.
Tarefas em Segundo Plano e o Semáforo de FPS
Importar um projeto do porte do Bistro dispara mais de mil tarefas individuais de importação. A barra de tarefas costumava exibir todas elas na tela — algo tecnicamente preciso, porém nada prático.
O sistema de tarefas em segundo plano foi totalmente reformulado: tarefas pai que possuem tarefas filhas agora são agrupadas em uma barra de progresso agregada — exibindo o progresso geral, o tempo decorrido e um botão de Cancelar —, enquanto as subtarefas individuais continuam sendo rastreadas internamente, podendo ser expandidas ou canceladas de forma independente.
Junto a isso, a barra de status ganhou um contador de FPS permanente com indicador visual no estilo semáforo: verde para 60 FPS ou mais, amarelo para 30 a 59 FPS e vermelho para valores inferiores. Ambos os limites podem ser ajustados nas configurações (Settings). O grande diferencial é que o contador amostra o envio real dos quadros para a tela (frame presents) em vez de se basear no redesenho da interface. Dessa forma, ele continua reportando a taxa de quadros real mesmo quando o editor está ocioso, sem travar no instante em que você para de mover o mouse.
Localização
O Studio agora fala o seu idioma. O novo sistema de localização vem com suporte nativo a Inglês e Português do Brasil, construído sobre um framework preparado para expandir.
O sistema de internacionalização (i18n) vai muito além da simples substituição de textos: ele suporta regras de pluralização (no padrão CLDR), interpolação de formatos de mensagem, desambiguação de traduções por contexto e troca de fontes por idioma — fundamental para renderizar textos em CJK (chinês/japonês/coreano), árabe ou devanagari. Ferramentas integradas extraem as strings traduzíveis do código-fonte e as compilam em tabelas binárias, de modo que adicionar um novo idioma é apenas uma importação de dados, sem precisar alterar o código-fonte.
A troca de idioma é instantânea — altere a opção nas configurações (Settings) e toda a interface é atualizada na hora, sem precisar reiniciar o Studio.
Jogos com Rosto: GUI In-Game
Uma engine que não consegue desenhar um menu não consegue lançar um jogo. No início de julho, doze tickets foram concluídos simultaneamente para resolver esse problema de vez.
Os jogos criados no Turian agora contam com um sistema completo de GUI in-game, baseado no tipo de asset UIDoc — documentos declarativos de interface gráfica criados no Studio e instanciados em tempo de execução. Painéis no formato Ninepatch escalam imagens sem distorcer os cantos, elementos de texto (labels) cuidam da tipografia e botões interativos enviam eventos tipados diretamente para o código do jogo. Como o UIDoc é um asset convencional, alterar uma tela de menu torna-se um trabalho de design com recarregamento em tempo real, sem exigir recompilação de código por parte dos programadores.
O editor de UI traz uma tela estilo WYSIWYG (o que você vê é o que você obtém) com árvore de nós própria e um Inspector para ajuste de layout e estilos — incluindo opções como expand, gravity, margin, tint, corner radius, font e font size. O desenvolvimento é feito com base em uma resolução de referência usando escala letterbox, garantindo que a mesma interface se adapte com precisão a diferentes proporções de tela (aspect ratios).
Mais para o final do mês, o sistema recebeu suporte a assets de canal GameEvent: uma maneira orientada a dados para conectar a lógica do jogo — como abrir uma porta, iniciar um diálogo ou tocar um efeito sonoro — sem acoplar código nem criar dependências rígidas entre componentes. Um botão em um UIDoc dispara um canal, e qualquer componente inscrito reage ao evento. O Inspector permite vincular essas conexões visualmente, no mesmo estilo dos UnityEvents.
Também foi introduzido o suporte a testes de regressão por captura de tela (screenshot verification). Com isso, é possível automatizar testes visuais de layouts de interface em ambientes de integração contínua (CI) — a engine renderiza o quadro de UI em modo headless e compara a imagem resultante com uma imagem de referência.
O Renderizador Amadurece
Julho elevou o nível do renderizador do Turian, passando de uma renderização funcional para um resultado visual impressionante.
Iluminação Baseada em Imagem e Skyboxes
Pergunte a qualquer artista 3D: a iluminação é o fator decisivo para o visual de uma cena. Até então, o Turian suportava apenas luzes analíticas — direcionais, pontuais e spots. Isso deixava ambientes externos com um aspecto lavado e artificial.
A iluminação baseada em imagem (Image-Based Lighting ou IBL) muda completamente esse cenário. Ao importar um mapa de ambiente HDR (no formato .hdr / Radiance), ele passa a atuar tanto como o skybox visível quanto como a fonte principal de iluminação da cena. A engine projeta o mapa em harmônicos esféricos de ordem 2 para calcular a irradiância difusa e amostra um mapa especular pré-filtrado para gerar reflexos — integrando ambos ao shader PBR junto com as luzes analíticas.
Esse termo especular passou por uma segunda revisão ao longo do mês. A implementação inicial reutilizava os mips da própria textura equirretangular como aproximação, o que causava borrões excessivos nos polos e distorcia os lóbulos de reflexo em ângulos de visão rasantes. Ela foi substituída por uma conversão real render-to-cubemap com pré-filtragem por amostragem de importância GGX para cada nível de mip — a abordagem padrão split-sum. Agora, os reflexos são bem definidos em superfícies de baixa rugosidade (roughness), mantêm a forma correta em rugosidades médias e ficam livres de artefatos nos polos. A API do EnvironmentComponent voltada para o usuário permaneceu exatamente a mesma; apenas o cálculo subjacente foi aprimorado.
O resultado: cenas externas iluminadas por um mapa HDRI parecem naturais e realistas sem exigir o posicionamento manual de dezenas de luzes. Um único mapa de ambiente fornece todas as referências ambientais, direcionais e reflexivas necessárias.
Arraste o controle deslizante para comparar a mesma cena apenas com iluminação analítica (antes) e com iluminação baseada em imagem (depois):
Gerenciamento de Cores: sRGB e Tonemapping ACES
Ticket #27
A iluminação PBR estava sendo calculada no espaço gama — as texturas de albedo não passavam pela conversão de sRGB para linear, e faltava um estágio de tonemapping na saída final. Julho corrigiu ambas as falhas.
As texturas de cor (albedo e emissivas) agora são amostradas em sRGB e convertidas para o espaço linear antes dos cálculos de iluminação. Mapas de normais, metálico-rugosidade e oclusão permanecem em espaço linear, como deve ser. Todo o pipeline de iluminação opera em espaço linear e o resultado final passa pelo tonemapping fílmico ACES — padrão da indústria para reprodução de cores cinematográfica e realista — antes da correção gama para exibição.
Isso garante uma iluminação fisicamente correta (PBR), alinhada ao comportamento de câmeras e monitores reais. Materiais metálicos ganham aspecto verdadeiramente metálico, as sombras preservam detalhes e as altas luzes (highlights) sofrem uma atenuação suave em vez de estourarem em branco puro.
Pós-Processamento HDR
Ticket #136
Uma iluminação correta entrega uma imagem realista. O pós-processamento transforma essa imagem em uma verdadeira fotografia.
O Turian agora conta com um pipeline modular de pós-processamento em HDR, executado após a etapa de iluminação: bloom (com limiar, intensidade e raio de desfoque ajustáveis, fazendo superfícies hiperiluminadas brilharem como em lentes reais), graduação de cor (color grading usando a especificação ASC CDL lift/gamma/gain) e vinheta (vignette, com controle de intensidade, raio e suavidade).
O destaque está na forma de controle: em vez de uma configuração global estática, os efeitos são gerenciados pelo componente PostProcessVolumeComponent. Um volume pode ser global — aplicando-se a toda a cena com peso total — ou local, delimitado por uma caixa ou esfera ligada à transformação do nó. Volumes sobrepostos são interpolados suavemente com base em prioridade e distância, e cada categoria de efeito pode ser ativada individualmente. Assim, um volume pode alterar o color grading sem afetar o efeito de bloom.
Dessa forma, a atmosfera visual transiciona organicamente à medida que o jogador se desloca pelo mapa: tons quentes com um leve bloom sob os toldos, e tons frios e dessaturados ao entrar em um beco — tudo sem precisar de scripts. Cada parâmetro pode ser ajustado no Inspector com visualização em tempo real.
Arraste para comparar o terraço do Bistro com o volume de pós-processamento desativado (antes) e ativado (depois) — observe o brilho das lâmpadas e a suavização nas bordas:
Modos de Blend, Culling de Faces e Alpha Mask
Ticket #26
Os materiais agora suportam modos de transparência alfa (alpha blend) e aditiva (additive blend), seleção configurável de eliminação de faces (culling: frontal, traseira ou nenhuma) e renderização por recorte de transparência (alpha-mask cutout). Com isso, objetos transparentes, sistemas de partículas, vegetação e vidros podem ser criados de forma nativa e sem gambiarras.
A Epopeia do Bistro
Epic #132
Toda engine precisa de uma cena desafiadora capaz de colocá-la à prova.
O Amazon Lumberyard Bistro é o teste de estresse clássico da indústria: o trecho urbano de uma rua com 2,8 milhões de triângulos apenas na área externa, 1.591 sub-meshes, 132 materiais e 633 texturas DDS totalizando 1,4 GB. É o tipo de arquivo típico de uma produção comercial de alto nível — e ele revelou praticamente todas as limitações que o Turian vinha mascarando até então.
Batendo na Parede
A primeira importação pareceu "bem-sucedida". No entanto, a cena renderizou apenas 32 superfícies das 1.591 existentes.
O problema não estava no importador, mas em uma trava hardcoded no renderizador: MAX_SUBMESH_MATERIALS = 32. Aumentar esse limite exigia reformular a vinculação dos materiais, o que implicava em uma mudança incompatível (breaking change) no formato de cena — dando origem à versão v3.0.0 (detalhada a seguir). Agora, os materiais são vinculados por slot de material em vez do índice de cada sub-mesh. Com isso, um modelo com 1.591 sub-meshes que compartilha 132 materiais precisa de apenas 132 slots, e não 1.591. O limite por slot subiu para 160 e o limite de sub-meshes na GPU foi completamente removido.
De repente, a rua inteira apareceu na tela. Mas a performance ficou completamente inviável.
Fazendo Caber
Ticket #141
Antes de otimizar as chamadas de desenho (draw calls), era preciso reduzir o volume de dados. O processo de compilação (cook) do FBX recebeu uma etapa de fusão de vértices (vertex welding), que indexa e compartilha vértices idênticos. Isso reduziu drasticamente o buffer de vértices (que era de 272 MB) e acelerou o tempo de importação. O resultado: menor consumo de memória VRAM, melhor aproveitamento do cache da GPU e iterações mais rápidas.
Culling, Três Vezes
Ticket #143
O descarte de geometria fora da visão da câmera (frustum culling) evoluiu ao longo de três arquiteturas sucessivas, cada uma desenvolvida após a medição dos gargalos da anterior.
Primeiro, culling por objeto na CPU: descartava meshes inteiras fora do campo de visão. Como a cena do Bistro é praticamente uma única mesh gigante, essa abordagem não trouxe ganho algum.
Segundo, culling por sub-mesh na CPU: testava os limites de cada uma das 1.591 sub-meshes a cada quadro no processador. Melhorou a situação, mas o custo de processamento na CPU tornou-se o próprio gargalo.
Terceiro (a solução atual): culling direcionado por GPU (GPU-driven culling). Um compute shader testa os limites de cada sub-mesh contra o frustum de visão e grava os comandos de desenho indireto (indirect draw) diretamente em um buffer da GPU. Em seguida, o passe de renderização emite uma única chamada DrawIndirect por grupo de material. A CPU deixa de iterar sobre as sub-meshes. As sub-meshes também são ordenadas por material para minimizar as trocas de estado de pipeline e vinculação.
Paralelamente, as luzes da cena foram movidas para um storage buffer na GPU, elevando o limite máximo de luzes por cena de 8 para 256.
Meça antes de Otimizar
Mesmo após três reescritas do sistema de culling, a taxa de quadros continuava baixa — e a constatação sincera é que ninguém sabia exatamente para onde o tempo de processamento estava indo. Culling de oclusão, Hi-Z, meshlets e LODs eram alternativas plausíveis, mas escolher uma delas sem dados concretos seria dar um quarto palpite no escuro.
Por isso, em vez de implementar uma quarta otimização às cegas, julho trouxe ferramentas de medição: consultas de timestamp na GPU (GPU timestamp queries) opcionais, delimitadas por fences, ao redor de cada passe de renderização — sombras, compute de culling, passe principal e objetos transparentes. Essas medições são exibidas por passe no painel Profiler do Studio, acompanhadas de um detalhamento expandido das fases de execução na CPU. O valor de gpu_time_ms no Profiler deixou de ser uma estimativa calculada pela CPU e tornou-se uma medição real do tempo de processamento da placa de vídeo.
O diagnóstico trouxe resultados imediatos. Uma das descobertas surpreendentes: ao abrir um projeto já importado, a engine lia e calculava o hash do conteúdo de todos os assets originais a cada inicialização — eram 1,7 GB de texturas sendo reprocessados apenas para confirmar que nada havia mudado. A inclusão de uma verificação rápida por data de modificação (mtime) e tamanho do arquivo transformou esse processo pesado em uma checagem quase instantânea.
A medição detalhada de tempo da GPU é opcional por um motivo simples: ler os timestamps a cada passe força uma sincronização que adiciona um pequeno overhead, não valendo a pena mantê-la ativa quando não se está investigando um gargalo. No painel Profiler, ela pode ser ativada por uma caixa de seleção, acompanhada de controles de V-Sync e limite de FPS, gravando os dados automaticamente ao entrar no modo Play.
Quadros Mais Baratos
As medições permitiram aplicar otimizações diretas e cirúrgicas: materiais resolvidos agora são mantidos em cache em vez de reavaliados a cada chamada de desenho; o passe de sombras recebeu culling de frustum por cascata (evitando renderizar a cena completa quatro vezes); e o passe de cena passou a renderizar em um alvo com multisampling 4x (MSAA) nos dispositivos suportados — entregando bordas nítidas por uma fração do custo do supersampling.
Visual no Ponto Certo
Ticket #157
Com a cena finalmente fluida e interativa, a diferença restante em relação ao render de referência da ORCA era puramente perceptual — e se resumia à oclusão de luz. O termo de iluminação ambiental IBL trata a luz do céu como vinda do infinito. Por isso, cada fenda ou superfície sob um toldo recebia a iluminação completa do hemisfério superior. A imagem de referência, por outro lado, é marcante pelo seu sombreamento de contato (contact darkening).
Dois novos recursos resolveram a maior parte dessa diferença:
Mapas de sombra em cascata. Sombras direcionais agora utilizam quatro cascatas compartilhando um único atlas de sombras. O cálculo de divisão segue a combinação logarítmica/uniforme, onde cada cascata possui seu próprio bias e passe de culling na GPU. As cascatas próximas mantêm definição suficiente para gerar sombras de contato nítidas, enquanto as distantes cobrem até o final da rua.
Oclusão ambiental em espaço de tela (SSAO). Um novo pré-passe de profundidade e normais alimenta o passe de SSAO (seguido de desfoque), que escurece o termo ambiente IBL onde a geometria se auto-oclui. Cantos de paredes, batentes de portas e a parte inferior de mesas finalmente parecem ancorados ao ambiente, e não flutuando.
Uma ressalva importante: a cena do Bistro foi concebida originalmente como uma cena noturna, iluminada principalmente por postes e luzes internas, enquanto a referência da ORCA é um ambiente diurno ensolarado. Como o SSAO modula apenas o termo de iluminação ambiente por especificação, seu impacto nesse cenário noturno é real, porém mais sutil do que em uma cena diurna. A iluminação indireta (bounce lighting) e reflexos locais continuam em desenvolvimento no ticket #157.
Importação: Muito Além do glTF
Importação de FBX
Embora o glTF tenha se consolidado como o padrão moderno da indústria, o FBX continua sendo o formato nativo da maioria das ferramentas de criação 3D (DCC) — como Maya e 3ds Max —, além de ser o formato padrão em diversas bibliotecas comerciais de assets.
O Turian agora suporta importação direta de arquivos FBX, compatível com os formatos binário e ASCII. Meshes, materiais (com mapeamento adaptativo para o modelo metálico-rugosidade da engine), texturas embutidas ou externas e a hierarquia completa de nós são extraídos e convertidos em assets nativos. A estrutura de nós da cena FBX é preservada na forma de um prefab com todos os seus sub-assets vinculados, pronto para ser arrastado para suas cenas.
Importação de Hierarquia glTF
Ticket #8
Anteriormente, a importação de glTF carregava meshes e materiais, mas descartava a hierarquia da cena. A partir de julho, arquivos glTF e GLB passam a preservar sua estrutura de nós na forma de um prefab, mantendo o relacionamento correto entre objetos pais e filhos. Modelos complexos formados por dezenas de peças separadas agora são organizados em uma estrutura hierárquica clara, em vez de uma lista desordenada de meshes.
Importação de Texturas DDS
Ticket #134
Arquivos no formato DirectDraw Surface (DDS) — amplamente utilizados para armazenar texturas pré-comprimidas para GPUs — agora podem ser importados diretamente. Há suporte completo aos formatos de compressão de bloco BC1 a BC7, com etiquetagem sRGB correta e tratamento de inversão de eixo Y para mapas de normais (Y-flip). Assets fornecidos com texturas DDS pré-comprimidas podem ser usados de imediato, sem necessidade de conversão.
Metadados Amigáveis ao Git
Um problema sutil, porém incômodo: os arquivos utilitários .meta associados a cada asset misturavam dois tipos de dados totalmente diferentes. Informações permanentes — como GUID, tipo de asset, configurações de importação e sub-assets — precisam estar sob controle de versão (Git), pois qualquer clone do repositório exige GUIDs idênticos para resolver as referências das cenas. No entanto, o arquivo também armazenava dados temporários de cache: hash do arquivo fonte, tamanho, data de modificação (mtime) e versão do importador.
Como o Git não preserva a data de modificação dos arquivos (mtime), a primeira importação após um git clone encontrava divergências e reescrevia todos os arquivos .meta do projeto. Isso gerava alterações pendentes no Git causadas puramente pelo checkout do repositório. Pior ainda: qualquer bug que causasse uma reescrita indevida poluía o git status de toda a equipe.
A solução foi mover os campos de cache para o diretório .cache/ (que já consta no .gitignore), indexados por GUID. Agora, clonar e abrir um projeto não gera nenhuma alteração nos arquivos .meta, e atualizar a versão de um importador não modifica nenhum arquivo rastreado pelo Git.
Essa mesma etapa corrigiu um pequeno bug com grande impacto: alterar a opção de ativar/desativar ("active") de um objeto da cena no Inspector não marcava a cena como modificada (dirty), o que podia fazer com que a alteração fosse perdida sem aviso.
Multiplataforma: A Chegada do Windows
O Turian Studio agora compila e executa nativamente no Windows, trazendo o Direct3D 12 (D3D12) como backend gráfico alternativo ao Vulkan. Esse foi o maior trabalho de infraestrutura do mês: ajustar a detecção de SDKs, corrigir suposições de caminhos de arquivos e rotinas de linkagem específicas de plataforma, implementar um carregador de bibliotecas dinâmicas multiplataforma (já que a std.DynLib do Zig 0.16 não possuía suporte a Windows) e validar a criação de janelas e tratamento de entradas (input). A integração contínua (CI) agora testa a compilação do Studio no Windows, e os pacotes de lançamento para Windows incluem tanto o CLI quanto a interface do Studio.
No início de agosto, o trabalho continuou com uma rotina de estabilização em tempo de execução para validar aspectos que vão além da renderização inicial: o ciclo de compilação e carregamento do modo Play — que gera uma DLL libturian_play.dll via subprocesso do zig e a carrega dinamicamente —, além da reflexão de scripts e geração de código, que continham suposições rígidas sobre caminhos no padrão POSIX.
O suporte multiplataforma vai além de apenas rodar em sistemas operacionais diferentes. Significa garantir que a engine utilize a API gráfica ideal de cada ambiente: Vulkan no Linux e Windows, D3D12 como alternativa no Windows e a base necessária para suportar Metal no macOS em atualizações futuras.
Saltos de Versão Sem Drama
Em julho lançamos dois saltos de versão major — v2.0.0 e v3.0.0 —, ambos impulsionados por alterações incompatíveis (breaking changes) necessárias, mas sem exigir mais do que alguns minutos para a migração.
v2.0.0: Materiais por Sub-mesh
O importador de glTF/GLB originalmente processava apenas a primeira primitiva da primeira mesh. A v2.0.0 corrigiu essa limitação introduzindo um sistema completo de materiais por sub-mesh: o formato de mesh TMSH recebeu uma tabela de sub-meshes, o componente MeshRendererComponent substituiu o campo único material por um array materials, e os arquivos de cena foram atualizados adequadamente.
A história completa — incluindo os motivos pelos quais uma única mudança incompatível justifica o salto de versão major — está detalhada no anúncio da v2.0.0.
v3.0.0: Vinculação por Slot de Material
Ticket #140
Enquanto a v2 vinculava materiais por índice de sub-mesh, a v3.0.0 realiza a vinculação por slot de material — permitindo que modelos com milhares de sub-meshes que compartilham poucos materiais utilizem apenas a quantidade necessária de slots. O limite de materiais aumentou de 32 para 160 e a restrição de sub-meshes na GPU foi eliminada.
A migração é simples: execute turian-cli migrate <projeto> para atualizar os arquivos de cena e ajuste o código que acessa os materiais do renderizador para utilizar o índice do slot de material em vez da sub-mesh. Confira o passo a passo completo no guia de migração para v3.0.0.
Um Framework para Tornar as Próximas Transições Simples
Ticket #137
Passar por duas alterações incompatíveis no mesmo mês deixou uma lição clara: o arquivo project.json registrava o campo turian_version sem que nada o validasse, e cada migração era criada de forma improvisada, sem uma estrutura padronizada para as edições futuras.
Julho resolveu esse problema com a criação de um framework completo de checagem de versão e migração. Ao abrir um projeto, a engine compara a versão registrada no arquivo com a versão atual — exibindo avisos para divergências de versão major e, opcionalmente, para minor (configurável em Settings). As rotinas de migração são organizadas em um registro centralizado (um arquivo por versão), contendo metadados indicando se a operação é idempotente. A migração da v2 (material_guid → material_guids) foi incorporada como a primeira entrada oficial desse novo framework.
A ferramenta de linha de comando foi a primeira a receber o recurso: turian-cli migrate <projeto> [--yes|--no] [--dry-run], podendo rodar de forma automatizada em ambientes de CI ou no modo --dry-run, que lista todas as migrações pendentes e etapas manuais antes de alterar qualquer arquivo. A caixa de diálogo no Studio que exibirá essas informações ao abrir um projeto está na próxima etapa de desenvolvimento. O detalhamento técnico pode ser consultado no ADR-0012.
Preparando o Terreno
Nem toda mudança é um recurso de destaque na capa. Algumas representam a infraestrutura invisível sobre a qual os recursos futuros serão construídos.
Sistema de Plugins e Pacotes
O Turian agora conta com um Sistema de Plugins e Pacotes completo, que inclui arquivos de manifesto, módulos e registro dinâmico em tempo de execução. Plugins podem criar menus customizados, painéis encaixáveis e editores de propriedades no Inspector. Os manifestos de pacotes declaram suas dependências e capacidades, e a engine os descobre e carrega automaticamente a partir da pasta do projeto.
Essa é a base para a criação de um futuro ecossistema de pacotes — permitindo que plugins da comunidade, pacotes de arte/assets e extensões da engine sejam instalados sem modificar o código-fonte principal.
Um Studio Mais Enxuto
Ticket #152
O código do Studio havia acumulado uma pasta services/ repleta de módulos não relacionados à interface gráfica — como operações de projeto, estado de sessão, sistema de desfazer (undo), área de transferência e tarefas de importação. Esses módulos foram movidos para a pasta editor/, que foi organizada por responsabilidades (project/, session/, assets/, build/, tasks/, shortcuts/, i18n/).
A grande vantagem dessa separação é a definição de um limite claro: o módulo editor/ é independente de GUI e pode ser testado sem necessidade de abrir uma janela, enquanto o studio/ atua como a camada de interface visual sobre ele. É essa arquitetura que permite às ferramentas headless — como o CLI, testes de CI e o servidor MCP — reaproveitarem toda a lógica do editor sem duplicar código. Essa diretriz está documentada no ADR-0015.
Registros de Decisões de Arquitetura
As justificativas técnicas por trás das principais decisões de arquitetura do mês agora estão formalizadas em documentações próprias: quinze ADRs cobrem o sistema de pacotes, injeção de dependências, gizmos, modo Play, iluminação e sombras, culling na GPU, versionamento de projetos e a separação entre editor e studio.
Fonte como Asset de Primeira Classe
Ticket #109
Os arquivos de fonte passaram a ser gerenciados pelo mesmo pipeline de importação utilizado em modelos e texturas. Assets de fonte suportam substituições por idioma (essenciais para renderização de caracteres CJK) e integram-se ao sistema de localização para troca automática de fonte conforme o idioma selecionado.
Saída de Build, Ícone de Projeto e CI
O pipeline de compilação (build) agora gera seus arquivos em uma pasta .public configurável, e os projetos podem definir um ícone customizado que é exibido na janela e na barra de tarefas do executável gerado. O Studio também ganhou um favicon e uma caixa de diálogo "Sobre" (About). No lado de infraestrutura, a lógica de empacotamento de lançamentos deixou os arquivos YAML e foi convertida em subcomandos de uma ferramenta em Zig — executando exatamente o mesmo código localmente e no ambiente de CI —, reduzindo a esteira de publicação para apenas duas etapas.
Mudança de Licença para MPL 2.0
O Turian alterou sua licença de GPLv3 para a Mozilla Public License 2.0 (MPL 2.0) — uma licença copyleft em nível de arquivo, em vez de nível de projeto. Com isso, é possível desenvolver e comercializar jogos proprietários sobre a engine mantendo o código do seu jogo fechado, enquanto melhorias feitas na engine permanecem de código aberto. Essa mudança atende diretamente ao feedback da comunidade; os detalhes completos podem ser lidos no artigo Migração da GPLv3 para MPL 2.0.
Olhando para o Futuro
Julho transformou o Turian de um projeto promissor em um ambiente de desenvolvimento maduro e produtivo. O Studio agora passa a sensação de uma ferramenta profissional — com painéis encaixáveis, temas personalizáveis, atalhos de teclado, console de log completo e suporte a localização. O renderizador gera imagens de alta qualidade visual, os importadores suportam os dois formatos 3D mais importantes e uma cena que antes renderizava apenas 32 superfícies hoje roda suavemente exibindo um cenário urbano completo.
A jornada de otimização com a cena Bistro ainda não acabou — iluminação indireta (bounce lighting), reflexos locais e culling de oclusão continuam no horizonte —, mas ela já cumpriu seu papel. Cada uma dessas evoluções surgiu ao enfrentar os desafios de uma cena real que se recusava a rodar, provando ser um aprendizado muito mais valioso do que qualquer teste sintético (benchmark).
Agosto dará continuidade a esse trabalho: aprimoramentos no renderizador, sistemas de animação, áudio e a interface do diálogo de migração no Studio. Acompanhe as próximas novidades no nosso roadmap.
Baixe o último lançamento, explore a nossa documentação e junte-se à comunidade no Discord ou no Matrix para acompanhar de perto.
Nos vemos no editor!
#release#editor#engine#studio