Filosofía de diseño de Niagara
¿Por qué reinventar los efectos visuales para Unreal Engine?
Unreal Engine está expandiendo su base de usuarios y ahora se utiliza en muchas industrias fuera del espacio de desarrollo de juegos. Algunos ejemplos son:
- Visualización arquitectónica
- Diseño industrial, como diseños automotrices
- Televisión virtual y producción cinematográfica
Nuestros usuarios son más diversos que nunca: desde estudiantes de diseño, pequeños desarrolladores independientes y equipos de grandes estudios de desarrollo profesional hasta personas y compañías ajenas a la industria de los videojuegos. A medida que avanzamos, los desarrolladores de Epic no sabrán todo sobre cada una de las industrias que usan Unreal Engine. Queríamos crear un sistema de efectos visuales (VFX) que funcionara para todos los usuarios en todas las industrias.
Nuestras metas para un nuevo sistema de VFX
Queríamos crear un nuevo sistema que les diera a todos los usuarios la flexibilidad para crear los efectos que necesitaran. Las metas para nuestro nuevo sistema de VFX eran:
- Poner todo el control en las manos de los artistas.
- Ser programable y personalizable en cada aspecto.
- Proporcionar mejores herramientas para debugging, visualización y rendimiento.
- Ofrecer compatibilidad con los datos de otras partes de Unreal Engine o de fuentes externas.
- No ser un obstáculo para el usuario.
Cómo Niagara alcanza nuestras metas
Compartición de datos
El control total por parte del usuario comienza con el acceso a los datos. Queremos que el usuario pueda usar cualquier dato de cualquier parte de Unreal Engine, así como de otras aplicaciones. Así que decidimos exponer todo al usuario.
Carga de partícula
Para exponer todos estos datos al usuario, debemos establecer de qué manera alguien puede usarlos. Los espacios de nombre proporcionan contenedores para los datos jerárquicos. Por ejemplo, Emitter.Age contiene datos para un emisor; Particle.Position contiene datos para una partícula. Nuestro mapa de parámetros es la carga de partícula que lleva todos los atributos de la partícula. Como resultado, todo se hace opcional.
Se pueden agregar muchos tipos de datos
Se puede añadir cualquier tipo de dato como parámetro de una partícula. Puedes agregar estructuras complejas, matrices de transformación o indicadores booleanos. Puedes añadir estos u otros tipos de datos y usarlos en tu simulación de efectos.
Combinación del paradigma de gráfico con el paradigma de pila
Ambos paradigmas tienen sus ventajas (el de pila se puede usar en Cascade y, el de gráfico, en Blueprints). Las pilas le ofrecen al usuario un comportamiento modular y legibilidad. Los gráficos le ofrecen al usuario más control sobre el comportamiento. Nuestro nuevo sistema de efectos combina las ventajas de ambos paradigmas.
Jerarquía para la estructura híbrida de Niagara
Módulos
Los módulos funcionan en un paradigma de gráfico, puedes crear módulos con HLSL en el editor de scripts usando un gráfico de nodo visual. Los módulos se comunican con los datos comunes, encapsulan conductas y apilan.
Emisores
Los emisores funcionan en un paradigma de pila, sirven como contenedores para los módulos y se pueden apilar para crear varios efectos. Los emisores tienen un solo propósito, pero también son reutilizables. Los parámetros se transfieren hasta el nivel del emisor desde los módulos, pero puedes modificar los módulos y los parámetros en el emisor.
Sistemas
Así como los emisores, los sistemas funcionan en un paradigma de pila; también funcionan con la línea de tiempo de un secuenciador, que puedes usar para controlar cómo se comportan los emisores en el sistema. Un sistema es un contenedor para los emisores. El sistema combina estos emisores en un solo efecto. Al editar un sistema en el editor de Niagara, puedes modificar y sobrescribir cualquier parámetro, módulo o emisor que esté en el sistema.
Pila de selección y grupos de pila de Niagara
La simulación de partículas en Niagara opera conceptualmente como una pila: la simulación fluye desde la parte superior de la pila hasta la base y ejecuta los módulos en orden. Cada módulo se asigna a un grupo que describe cuándo se ejecuta el módulo. Por ejemplo, los módulos que inicializan partículas o actúan cuando se genera una partícula están en el grupo Generación de partícula.
Con cada grupo, puede haber múltiples etapas, que se llaman en puntos particulares en el ciclo de vida de un sistema. Los emisores, los sistemas y las partículas tienen etapas de Generación y Actualización por defecto. Las etapas de generación se invocan en el primer recuadro donde existe ese grupo. Por ejemplo, los sistemas invocan su etapa de generación cuando el sistema se instancia por primera vez en el nivel y se activa. Las partículas invocan su etapa de generación cuando el emisor emite una partícula, y las instrucciones de generación se ejecutarán para cada partícula nueva que se cree. Las etapas de actualización se invocan en cada recuadro donde estén activos el sistema, el emisor o la partícula.
También hay etapas avanzadas, como los Eventos y las Etapas de simulación, que se pueden agregar al flujo de generación y actualización. Los Eventos se invocan cuando una partícula genera un nuevo evento y se configura un emisor para que maneje ese evento. Cuando es posible, las etapas del manejador de eventos ocurren en el mismo recuadro, pero después del evento disparador. Las Etapas de simulación son una función avanzada de la GPU. Esta función permite que ocurran en secuencia múltiples etapas de generación y actualización, y es útil para construir estructuras complejas como las simulaciones de fluidos.
Un módulo es un ítem, pero un ítem no es un módulo. Los Módulos son recursos editables que un usuario puede crear. Los Ítems se refieren a las partes de un sistema o emisor que el usuario no puede crear. Las propiedades del sistema, las propiedades del emisor y los renderizadores son ejemplos de ítems.
Etapas, grupos, nombres de espacio y encapsulación de datos
Al añadir cada módulo a una etapa (Actualización, Generación, Evento o Simulación) en un grupo (Sistema, Emisor o Partícula), puedes controlar cuándo se ejecuta un módulo y sobre qué datos opera este. Los grupos de pila están asociados con los Nombres de espacio que definen qué datos puede leer y escribir el módulo en ese grupo.
Por ejemplo, los módulos que se ejecutan en el grupo Sistema pueden leer y escribir sobre los parámetros en el nombre de espacio Sistema, pero solo pueden leer de parámetros que pertenecen a los nombres de espacio Motor o Usuario. Mientras la ejecución baja por la pila desde el grupo Sistema hacia el grupo Emisor, los módulos que se ejecutan en el grupo Emisor pueden leer y escribir sobre los parámetros en el nombre de espacio Emisor, pero solo pueden leer de los parámetros en los nombres de espacio Sistema, Motor y Usuario. Los módulos en el grupo Partícula solo pueden leer de los parámetros en los nombres de espacio Sistema y Emisor.
Dado que los módulos en los grupos Emisor pueden leer de los parámetros en el nombre de espacio Sistema, los módulos en el grupo Sistema pueden llevar a cabo una vez la simulación que sea relevante para todos los emisores, y los módulos del grupo Emisor en cada emisor individual pueden leer los resultados de esto (almacenados en el nombre de espacio Sistema). Esto continúa con los módulos del grupo Partícula, que pueden leer de los parámetros en los nombres de espacio Sistema y Emisor. Consulta la tabla de abajo para ver una representación más concisa de estas relaciones.
| Grupo del módulo | Espacios de nombre de lectura | Espacios de nombre de escritura |
|---|---|---|
| Sistema | Sistema, Motor, Usuario | Sistema |
| Emisor | Sistema, Emisor, Motor, Usuario | Emisor |
| Partícula | Sistema, Emisor, Partícula, Motor, Usuario | Partícula |