Atualização do motor
Ei! Já faz um tempo desde que publiquei um devlog. Só queria postar brevemente sobre minha experiência de atualização do motor para a unidade.
Por muitos anos, tenho executado na Unity 2019.4 LTS- e porque planejamos enviar o jogo em consoles modernos, achei que period hora de uma grande atualização do motor.
Originalmente, não pretendi atualizar para a Unity 6 por causa de seu modelo de receita. No entanto, para benefício de todos (incluindo unidade), Felizmente, isso foi revertido em setembro.
Decidi que modernizaria totalmente Desolus para correr na Unity 6, então não precisarei me preocupar muito com isso mais tarde, quando o jogo realmente for enviado.
No entanto, como a atualização do mecanismo durou cerca de 5 anos de alterações da unidade no código, decidi fazê -lo em um processo escalonado e atualizei para 2022 LTs primeiro.
—-
Unity 2019 LTS -> Unity 2022 LTS
Se você leu meu devlog, sabe que Desolus está executando um pipeline de renderização de scripts personalizado que eu me escrevi. Felizmente, a codificação de gatos tem uma grande quantidade de documentação sobre como escrever seu próprio pipeline, E eles também tiveram um guia de unidade de 2019 -> 2022 para atualização.
O processo de atualização de 2022 foi principalmente indolor- apenas algumas atualizações simples da API para algumas coisas. No entanto, brand percebi que, uma vez que o jogo compilou * todos os shaders do jogo foram quebrados. * Não só estava quebrado, mas eu estava recebendo um erro ambíguo de ‘sintaxe inválida’ no arquivo de nível superior nos meus shaders.
O que acabou sendo a causa foi aparentemente, em algum lugar entre o Unity 2019 e o Unity 2022, a sintaxe do comentário foi alterada?
Não havia nada de errado com o meu código, exceto que o comentário estava causando um erro de análise no compilador.
Levei cerca de duas horas batendo a cabeça contra a parede, mas finalmente consegui descobrir essa mudança obscura e fiz a unidade 2022 correndo bem.
—-
Unidade 2022 LTS -> Unidade 6
A atualização da Unity 6 foi mais desafiadora do que a atualização da Unidade 2022.
Novamente, as diferenças de API C# foram bastante triviais, mas acabei lutando por causa de uma mudança obscura do shader.
Eu uso o SpeedTree para Desolus e existe há muitos anos. Como estou usando um SRP personalizado, no entanto, tive que portar o SpeedTree Shader para o meu próprio pipeline de renderização.
Tudo é traduzido para HLSL. No entanto, há um obscuro incluir o arquivo dos tempos antigos nos quais eu ainda confiava, chamado speedtreewind.cginc. Isso é interno à unidade. Não sei onde existe e não está disponível publicamente no Repositório de Gráficos da Unidade.
Eu estava recebendo algum tipo de erro de compilação com este arquivo, que é interno e não pode ser editado, então tive que desenterrá -lo das profundezas da Web e traduzi -lo do código do shader CG para o HLSL.
Depois disso, peguei o SpeedTree Shader para compilar, mas notei que não havia vento! Isso funcionou bem durante a atualização de 2022, então algo deve ter mudado da Unidade 2022 para a Unidade 6.
Lutando para consertar isso, eu investigei o repositório interno da unidade para a história dos shaders Speedtree, e prendeu a mudança exata a esse compromisso.
Ainda um pouco confuso, enviei uma mensagem para o Desenvolvedor de tecnologias da Unity, que escreveu essas mudanças. Ele foi bom o suficiente para responder (obrigado Volkan!) Ele descreveu como o sistema eólico mudou entre a Unidade 2022 e a Unidade 6.
Consegui resolver o problema através de algumas modificações adicionais no meu shader SpeedTree e, portanto, a atualização da Unidade 6 foi completa!
—-
Alterações de SRP: correções de textura e otimizações de memória
Decidi que, enquanto ainda estava na coragem da minha base de código, também faria algumas otimizações no meu pipeline de renderização.
Se você não viu minha palestra no Desolus SRP, recomendo assistir!
https://www.youtube.com/watch?v=jgux640hhbu
Mergulhando em que mudanças eu fiz em um quadro:
—-
Mudança na maneira como as normais são armazenadas no passe de profundidade/normais.
Anteriormente, cometi um erro com a forma como eu armazenei meu espaço mundial normais.
Os normais do espaço mundial são um vetor que existe na faixa (-1, -1, -1) a (1,1,1), os valores que são armazenados no canal vermelho/verde/azul.
Porque eu estava armazenando os valores em um Textura rgbahalfPresumi que os valores negativos seriam armazenados corretamente e isso foi suportado pelo formato de textura.
No entanto, esse não foi o caso, os valores estavam sendo fixados na faixa (0,0,0) para (1,1,1).
Isso causou um erro em vários shaders posteriormente no pipeline, que se baseava nos normais do espaço mundial, pois metade dos valores estava efetivamente ausente e definida como 0.
O que acabei fazendo foi criar uma função de pacote/descompactar, que remapeia os normais do intervalo (-1, -1, -1) a (1,1,1) para o intervalo (0,0,0) a (1,1,1), para que os valores possam ser armazenados adequadamente na textura. Quando preciso dos normais mais tarde no pipeline, o processo reverso é feito para mapear os normais de volta aos seus valores originais.
Embora se possa argumentar que há uma perda de precisão, a diferença é nominal e os valores corretos fazem uma grande diferença na fixação de erros visuais.
—-
Mudanças na maneira como funciona a reflexão do espaço da tela
Eu fiz algumas otimizações sobre como meu A reflexão do espaço da tela funciona.
Anteriormente, eu tinha um passe adicional de ‘SSR’ para objetos, que foi usado para consertar artefatos no SSR.
O que isso fez foi definir efetivamente um intervalo nos valores de buffer de profundidade, para que o SSR não ‘desfeita’ e causasse enormes quantidades de artefatos gráficos.
Felizmente, consegui eliminar esse passe inteiramente corrigindo bugs com a maneira como meu shader SSR lidou com os valores do buffer de profundidade. Efetivamente, o que fiz foi definir uma faixa máxima na qual o buffer de profundidade poderia ser avaliado.
—-
Várias otimizações de textura
Anteriormente, eu não period muito preciso com os formatos de textura no meu pipeline de renderização de scripts.
A maioria dos passes foi muito armazenada como um Rgbahalf rendertexture(o formato de buffer de cores padrão para o meu SRP), que é realmente bastante caro.
Havia ganhos óbvios a serem obtidos para passes como o meu ‘portal Go’, que só desenha um tom de vermelho. Usar um rgbahalf para armazenar esses dados foi completamente um desperdício, quando eu poderia ter armazenou a textura como um R8que é apenas uma textura de 8 bits de 8 bits, em vez de uma textura de quatro bits de quatro canais.
Mudei o formato de textura por cerca de cinco a seis passes diferentes, e isso resultou em uma grande melhoria para o VRAM, que é usada no jogo, além de um pequeno aumento na taxa de quadros.
—-
Conclusão
No geral, estou muito feliz com o progresso da atualização do mecanismo do Unity e do refator SRP. Agora estou totalmente de volta à terra do design do quebra -cabeça!
—-