Conceitos-chave do Niágara

Filosofia de design do Niagara

Por que reinventar efeitos visuais para o Unreal Engine?

O Unreal Engine está expandindo sua base de usuários e agora é usado em muitos setores fora do espaço de desenvolvimento de jogos. Exemplos são:

• Visualização arquitetônica
• Desenho industrial, como desenhos automotivos
• TV virtual e produção de filmes

Nossos usuários são mais diversificados do que nunca: desde estudantes de design a pequenos desenvolvedores independentes, grandes equipes de estúdios profissionais e indivíduos e empresas fora do setor de jogos. À medida que avançamos, os desenvolvedores da Epic não saberão tudo sobre todos os setores que usam o Unreal Engine. Queríamos criar um sistema de efeitos visuais que funcionasse para todos os nossos usuários, em todos os setores.

Nossos objetivos para um novo sistema de efeitos visuais

Queríamos criar um novo sistema que desse a todos os usuários a flexibilidade para criar os efeitos desejados. Nossas metas para nosso novo sistema de efeitos visuais foram:

• Colocar o controle total nas mãos dos artistas.
• Ser programável e personalizável em todos os eixos.
• Fornece ferramentas melhores para depuração, visualização e desempenho.
• Oferecer suporte a dados de outras partes do Unreal Engine ou de fontes externas.
• Ficar fora do caminho do usuário.

Como o Niagara permite alcançar essas metas

Compartilhamento de dados

O controle total do usuário começa com o acesso aos dados. Queremos que o usuário possa usar todos os dados de qualquer parte do Unreal Engine, bem como usar dados de outros aplicativos. Portanto, resolvemos expor tudo para o usuário.

Carga útil de partículas

Para expor todos esses dados ao usuário, temos que estabelecer como alguém pode usá-los. Namespaces fornecem contêineres para dados hierárquicos. Por exemplo, Emitter.Age contém dados para um emissor; Particle.Position contém dados para uma partícula. Nosso mapa de parâmetros é a carga útil da partícula que carrega todos os atributos da partícula. Como resultado disso, tudo se torna opcional.

Vários tipos de dados podem ser adicionados

Qualquer tipo de dado pode ser adicionado como um parâmetro de partícula. É possível adicionar estruturas complexas, matrizes de transformação ou sinalizadores booleanos. Você pode adicionar esses ou qualquer outro tipo de dados e usá-los na sua simulação de efeitos.

Combinando o paradigma de gráfico e o paradigma de pilha

Existem vantagens tanto para o paradigma da pilha (como o usado em Cascata) quanto para o paradigma de gráfico (como o usado em Blueprints). Pilhas fornecem aos usuários comportamento modular e legibilidade. Gráficos dão aos usuários mais controle sobre o comportamento. Nosso novo sistema de efeitos combina as vantagens de ambos os paradigmas.

Hierarquia para a estrutura híbrida do Niagara

Módulos

Módulos funcionam em um paradigma de gráfico: você pode criar módulos com HLSL no Editor de scripts usando um gráfico de nó visual. Módulos se comunicam com dados comuns, encapsulam comportamentos e se empilham juntos.

Emissores

Emissores funcionam em um paradigma de pilha: eles servem como contêineres para módulos e podem ser empilhados para criar vários efeitos. Um emissor é de propósito único, mas também é reutilizável. Parâmetros são transferidos até o nível do emissor a partir de módulos, mas você pode modificar módulos e parâmetros no emissor.

Sistemas

Assim como emissores, sistemas funcionam em um paradigma de pilha e também trabalham com uma linha de tempo do Sequencer, que você pode usar para controlar como os emissores no sistema se comportam. Um sistema é um recipiente para emissores. O sistema combina esses emissores em um único efeito. Ao editar um sistema no Editor Niagara, você pode modificar e substituir qualquer parâmetro, módulo ou emissor que esteja nesse sistema.

Pilha de seleção e grupos de pilhas do Niagara

A simulação de partículas no Niagara opera conceitualmente como uma pilha: ela flui do topo até o fundo da pilha e executa os módulos em ordem. Crucialmente, cada módulo é atribuído a um grupo que descreve quando esse módulo é executado. Por exemplo, módulos que inicializam partículas ou que agem quando uma partícula surge estão no grupo Geração de partículas.

Dentro de cada grupo, pode haver vários estágios, que são chamados em determinados pontos do ciclo de vida de um sistema. Emissores, sistemas e partículas têm estágios de Geração e Atualização por padrão. Os estágios de geração são invocados no primeiro quadro em que esse grupo existe. Por exemplo, sistemas invocam seu estágio de geração quando são instanciados pela primeira vez no nível e ativados. Partículas invocam seu estágio de geração sempre que o emissor emite uma partícula, e as instruções de geração são executadas para cada nova partícula criada. Estágios de atualização são invocados em cada quadro em que o sistema, o emissor ou a partícula está ativo.

Também existem estágios avançados, como Eventos e Estágios de simulação, que podem ser adicionados ao fluxo de geração e atualização. Eventos são invocados sempre que uma partícula gera um novo evento, e um emissor é definido para lidar com esse evento. Sempre que possível, os estágios de manipuladores de eventos ocorrem no mesmo quadro, mas após o evento de origem. Estágios de simulação são um recurso avançado de GPU. Esse recurso permite que vários estágios de geração e atualização aconteçam em sequência e é útil para a construção de estruturas complexas, como simulações de fluidos.

Um módulo é um item, mas um item não é um módulo. Módulos são recursos editáveis que um usuário pode criar. Itens referem-se a partes de um sistema ou emissor que o usuário não pode criar. Exemplos de itens são propriedades de sistemas, propriedades de emissores e renderizadores.

Estágios, grupos, namespaces e encapsulamento de dados

Ao adicionar cada módulo a um estágio (Atualização, Geração, Evento ou Simulação) em um grupo (Sistema, Emissor ou Partícula), você pode controlar quando um módulo é executado, bem como em quais dados ele opera. Grupos de pilhas são associados a Namespaces, que definem em quais dados os módulos desse grupo podem ler ou gravar.

Por exemplo, os módulos executados no grupo Sistema podem ler e gravar em parâmetros no namespace do sistema, mas só podem ler os parâmetros que pertencem aos namespaces Engine ou Usuário. À medida que a execução desce pela pilha do grupo Sistema para o grupo Emissor, os módulos em execução no grupo Emissor Group podem ler e gravar nos parâmetros do namespace Emissor, mas só podem ler os parâmetros nos namespaces Sistema, Engine e Usuário. Módulos no grupo Partícula só podem ler parâmetros nos namespaces Sistema e Emissor.

Como os módulos nos grupos Emissor podem ler parâmetros no namespace Sistema, a simulação relevante para todos os emissores pode ser executada uma vez por módulos no grupo Sistema, e os resultados disso (armazenados no namespace Sistema) podem ser lidos pelos módulos do grupo Emissor em cada emissor individual. Isso continua com os módulos do grupo Partícula, que podem ler os parâmetros nos namespaces Sistema e Emissor. Consulte a tabela abaixo para obter uma representação mais concisa dessas relações.