UE 4.20: Niagara vient compléter (et remplacer à terme) Cascade !

par | 25 Juil 2018

Niagara vient semble-t-il remplacer Cascade, le système de gestion des particules, un peu comme Sequencer est venu remplacer Matinee pour les animations. Bon, ça ne veut pas dire que l’ancien sera supprimé, mais peut-être que tous les efforts seront concentrés sur cette nouvelle mouture, qui est pour le moment, en « Early Access ». Il n’est donc pas conseillé de l’utiliser en production.

Allons voir cela d’un peu plus près !

Niagara est-il meilleur que Cascade? Sa force réside dans sa capacité à laisser l’utilisateur scripter le comportement de ses particules sans devoir intervenir coté code pour créer de nouvelles fonctionnalités.

Il utilise un système de nœuds visuels que les artistes peuvent utiliser facilement. On peut toutefois se poser des questions quant aux performances de Niagara / Cascade. A cela, Epic répond que le code généré par les blueprints est interprété par un système de bas niveau permettant de hautes performances.

Toutefois, cela fonctionne sur CPU, et sur GP, mais pas sur toutes les plateformes (voir un peu plus loin).

Pour un aperçu de Niagara, vous pouvez visionner la présentation VFX programmable de GDC 2018 avec Niagara de Unreal Engine et lire la documentation de Niagara .

Améliorations de la conception et de la création d’effets

Gauche – Système de particules utilisant un module d’entrée dynamique; Droite – Module d’entrée dynamique

  • Skeletal Meshes peuvent spécifier leur émission à partir de la surface, soit par le nom du matériau, soit par une région d’influence de l’os nommée.
  • La spécification des valeurs par défaut dans les modules a été améliorée, permettant à de nombreux comportements d’appeler des fonctions à l’aide d’entrées dynamiques par défaut.
  • Mesh particules supportent maintenant la vitesse angulaire.
  • La prise en charge des beams a été ajoutée au rendu Ribbon avec les nouveaux modules correspondants.
  • Les dépendances entre modules peuvent maintenant être définies, permettant à l’utilisateur d’être informé quand il place la pile dans une mauvaise configuration. En outre, les utilisateurs ont des options de correction automatique .
  • De nombreuses améliorations ont été apportées à merging System Emitters et Base Emitters,, améliorant ainsi la stabilité globale.
  • Les modules peuvent maintenant être activés / désactivés dans la pile. Cela fonctionnera également pour l’héritage.
  • La prise en charge du séquenceur et Blueprint pour la définition des variables d’espace de nom d’utilisateur Niagara a été ajoutée.
  • Vous pouvez générer des paramètres à l’aide d’expressions HLSL personnalisées, d’entrées dynamiques (graph snippets) , de liens vers d’autres variables ou par valeur .
  • En option, les particules peuvent maintenant avoir un identifiant persistant
  • Plusieurs moteurs de rendu de chaque type peuvent être appliqués à un émetteur. Un émetteur peut avoir deux moteurs de rendu, l’un tirant sa position de la position d’une particule et l’autre tirant sa position de la position de décalage d’une particule.
  • Le plugin Niagara Extras contient également un matériau de débogage qui achemine divers paramètres par particule vers un affichage de type dialogue.
  • importateur CSV
  • une grande variété de fonctionnalités pour Niagara a été ajoutée sous le système de test automatisé.

Interface utilisateur mise à jour

L’interface Niagara a été conçue pour rendre les effets complexes intuitifs à créer. Elle utilise une « pile » comme principale méthode de combinaison de morceaux de logique de script. Dans la pile, vous trouverez une chronologie pour contrôler les aspects de l’effet au fil du temps, un panneau de paramètres pour un accès facile aux variables disponibles dans l’effet, une feuille de calcul d’attributs pour trouver rapidement et réagir à l’information que l’effet est en cours d’ exécution.

Nouveaux modules

Tous les modules de Niagara ont été mis à jour ou réécrits pour prendre en charge les comportements couramment utilisés. De nouvelles fonctionnalités de l’interface utilisateur ont également été ajoutées pour la pile Niagara qui imitent les options des développeurs avec UProperties en C ++, permettant l’activation / désactivation en ligne ou l’affichage des variables en fonction de l’état d’une autre variable.

Simulation GPU

Niagara prend maintenant en charge la simulation GPU lorsqu’il est utilisé sur les plates-formes DX11PS4 , Xbox One , OpenGL (ES3.1) et Metal . Il est prévu que Vulkan et Switch prennent en charge la simulation GPU dans une future version. Les limitations actuelles et les problèmes connus avec la simulation GPU sont décrits ci-dessous:

  • Le support complet de Niagara nécessite la capacité de relire les données du GPU. Actuellement, seules nos interfaces de rendu DX11 et PS4 supportent cette fonctionnalité, et OpenGL et Metal sont en cours.
  • Les champs Collision , Curves et Curl Noise sont pris en charge sur le GPU. Les maillages, les maillages dépouillés, les composants de spline et d’autres interfaces de données spécialisées ne sont pas encore pris en charge. L’API permettant aux shaders GPU d’interagir avec UNiagaraDataInterfaces a également été repensée.
  • Le rendus Sprite et Instanced Static Mesh à partir de particules est pris en charge sur les simulations GPU. À l’heure actuelle, la génération de lumière à partir de particules et de rubans à partir de particules ne fonctionne pas sur le GPU.
  • Les événements ne fonctionnent que sur le processeur et subiront des modifications importantes après Unreal Engine 4.20.

Simulation  CPU

La simulation CPU Niagara fonctionne maintenant sur PC, PS4, Xbox One, OpenGL (ES3.1) et Metal. Pour le moment, Vulkan et Switch ne sont pas supportés.

  • La machine virtuelle du processeur (VM) compile maintenant son contenu au DDC sur un thread d’arrière-plan, ce qui améliore considérablement la vitesse de compilation globale et l’efficacité de l’équipe. Un travail supplémentaire est nécessaire pour que l’étape d’optimisation VM finale se produise dans ShaderCompileWorker car elle dépend de bibliothèques non thread-safe. Les dépendances de compilation sont correctement suivies à travers les modules.
  • La simulation de physique sur l’unité centrale devrait modéliser correctement les valeurs physiques du matériau pour la friction et la restitution (rebondissement).
  • Les émetteurs vont maintenant simuler en parallèle sur les threads de travail.

Voilà, je vous propose une petite présentation réalisée par Meletou qui vous présentera de façon pratique une première utilisation de Niagara:
https://www.youtube.com/watch?v=StwiMOjOx00

Découvrez nos derniers numéros !

0 commentaires

Laisser un commentaire

Ces articles pourraient aussi vous intéresser …

Participez à partir de 1€ à notre campagne sur Ulule
pour obtenir le magazine sous forme papier

cliquez pour aller sur la campagne

Ceci fermera dans 21 secondes