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

Nia­gara vient sem­ble-t-il rem­plac­er Cas­cade, le sys­tème de ges­tion des par­tic­ules, un peu comme Sequencer est venu rem­plac­er Mati­nee pour les ani­ma­tions. Bon, ça ne veut pas dire que l’ancien sera sup­primé, mais peut-être que tous les efforts seront con­cen­trés sur cette nou­velle mou­ture, qui est pour le moment, en “Ear­ly Access”. Il n’est donc pas con­seil­lé de l’utiliser en pro­duc­tion.

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

Nia­gara est-il meilleur que Cas­cade? Sa force réside dans sa capac­ité à laiss­er l’utilisateur scripter le com­porte­ment de ses par­tic­ules sans devoir inter­venir coté code pour créer de nou­velles fonc­tion­nal­ités.

Il utilise un sys­tème de nœuds visuels que les artistes peu­vent utilis­er facile­ment. On peut toute­fois se pos­er des ques­tions quant aux per­for­mances de Nia­gara / Cas­cade. A cela, Epic répond que le code généré par les blue­prints est inter­prété par un sys­tème de bas niveau per­me­t­tant de hautes per­for­mances.

Toute­fois, cela fonc­tionne sur CPU, et sur GP, mais pas sur toutes les plate­formes (voir un peu plus loin).

Pour un aperçu de Nia­gara, vous pou­vez vision­ner la présen­ta­tion VFX pro­gram­ma­ble de GDC 2018 avec Nia­gara de Unre­al Engine et lire la doc­u­men­ta­tion de Nia­gara .

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

Gauche — Sys­tème de par­tic­ules util­isant un mod­ule d’entrée dynamique; Droite — Mod­ule d’entrée dynamique

  • Skele­tal Mesh­es peu­vent spé­ci­fi­er leur émis­sion à par­tir de la sur­face, soit par le nom du matéri­au, soit par une région d’influence de l’os nom­mée.
  • La spé­ci­fi­ca­tion des valeurs par défaut dans les mod­ules a été améliorée, per­me­t­tant à de nom­breux com­porte­ments d’appeler des fonc­tions à l’aide d’entrées dynamiques par défaut.
  • Mesh par­tic­ules sup­por­t­ent main­tenant la vitesse angu­laire.
  • La prise en charge des beams a été ajoutée au ren­du Rib­bon avec les nou­veaux mod­ules cor­re­spon­dants.
  • Les dépen­dances entre mod­ules peu­vent main­tenant être définies, per­me­t­tant à l’utilisateur d’être infor­mé quand il place la pile dans une mau­vaise con­fig­u­ra­tion. En out­re, les util­isa­teurs ont des options de cor­rec­tion automa­tique .
  • De nom­breuses amélio­ra­tions ont été apportées à merg­ing Sys­tem Emit­ters et Base Emit­ters„ amélio­rant ain­si la sta­bil­ité glob­ale.
  • Les mod­ules peu­vent main­tenant être activés / dés­ac­tivés dans la pile. Cela fonc­tion­nera égale­ment pour l’héritage.
  • La prise en charge du séquenceur et Blue­print pour la déf­i­ni­tion des vari­ables d’espace de nom d’utilisateur Nia­gara a été ajoutée.
  • Vous pou­vez génér­er des paramètres à l’aide d’expres­sions HLSL per­son­nal­isées, d’entrées dynamiques (graph snip­pets) , de liens vers d’autres vari­ables ou par valeur .
  • En option, les par­tic­ules peu­vent main­tenant avoir un iden­ti­fi­ant per­sis­tant
  • Plusieurs moteurs de ren­du de chaque type peu­vent être appliqués à un émet­teur. Un émet­teur peut avoir deux moteurs de ren­du, l’un tirant sa posi­tion de la posi­tion d’une par­tic­ule et l’autre tirant sa posi­tion de la posi­tion de décalage d’une par­tic­ule.
  • Le plu­g­in Nia­gara Extras con­tient égale­ment un matéri­au de débo­gage qui achem­ine divers paramètres par par­tic­ule vers un affichage de type dia­logue.
  • impor­ta­teur CSV
  • une grande var­iété de fonc­tion­nal­ités pour Nia­gara a été ajoutée sous le sys­tème de test automa­tisé.

Interface utilisateur mise à jour

L’interface Nia­gara a été conçue pour ren­dre les effets com­plex­es intu­itifs à créer. Elle utilise une “pile” comme prin­ci­pale méth­ode de com­bi­nai­son de morceaux de logique de script. Dans la pile, vous trou­verez une chronolo­gie pour con­trôler les aspects de l’effet au fil du temps, un pan­neau de paramètres pour un accès facile aux vari­ables disponibles dans l’effet, une feuille de cal­cul d’attributs pour trou­ver rapi­de­ment et réa­gir à l’information que l’effet est en cours d’ exé­cu­tion.

Nouveaux modules

Tous les mod­ules de Nia­gara ont été mis à jour ou réécrits pour pren­dre en charge les com­porte­ments couram­ment util­isés. De nou­velles fonc­tion­nal­ités de l’interface util­isa­teur ont égale­ment été ajoutées pour la pile Nia­gara qui imi­tent les options des développeurs avec UProp­er­ties en C ++, per­me­t­tant l’activation / dés­ac­ti­va­tion en ligne ou l’affichage des vari­ables en fonc­tion de l’état d’une autre vari­able.

Simulation GPU

Nia­gara prend main­tenant en charge la sim­u­la­tion GPU lorsqu’il est util­isé sur les plates-formes DX11PS4 , Xbox One , OpenGL (ES3.1) et Met­al . Il est prévu que Vulkan et Switch pren­nent en charge la sim­u­la­tion GPU dans une future ver­sion. Les lim­i­ta­tions actuelles et les prob­lèmes con­nus avec la sim­u­la­tion GPU sont décrits ci-dessous:

  • Le sup­port com­plet de Nia­gara néces­site la capac­ité de relire les don­nées du GPU. Actuelle­ment, seules nos inter­faces de ren­du DX11 et PS4 sup­por­t­ent cette fonc­tion­nal­ité, et OpenGL et Met­al sont en cours.
  • Les champs Col­li­sion , Curves et Curl Noise sont pris en charge sur le GPULes mail­lages, les mail­lages dépouil­lés, les com­posants de spline et d’autres inter­faces de don­nées spé­cial­isées ne sont pas encore pris en charge. L’API per­me­t­tant aux shaders GPU d’interagir avec UNi­a­gara­DataIn­ter­faces a égale­ment été repen­sée.
  • Le ren­dus Sprite et Instanced Sta­t­ic Mesh à par­tir de par­tic­ules est pris en charge sur les sim­u­la­tions GPU. À l’heure actuelle, la généra­tion de lumière à par­tir de par­tic­ules et de rubans à par­tir de par­tic­ules ne fonc­tionne pas sur le GPU.
  • Les événe­ments ne fonc­tion­nent que sur le processeur et subiront des mod­i­fi­ca­tions impor­tantes après Unre­al Engine 4.20.

Simulation  CPU

La sim­u­la­tion CPU Nia­gara fonc­tionne main­tenant sur PC, PS4, Xbox One, OpenGL (ES3.1) et Met­al. Pour le moment, Vulkan et Switch ne sont pas sup­port­és.

  • La machine virtuelle du processeur (VM) com­pile main­tenant son con­tenu au DDC sur un thread d’arrière-plan, ce qui améliore con­sid­érable­ment la vitesse de com­pi­la­tion glob­ale et l’efficacité de l’équipe. Un tra­vail sup­plé­men­taire est néces­saire pour que l’étape d’optimisation VM finale se pro­duise dans Shader­Com­pile­Work­er car elle dépend de bib­lio­thèques non thread-safe. Les dépen­dances de com­pi­la­tion sont cor­recte­ment suiv­ies à tra­vers les mod­ules.
  • La sim­u­la­tion de physique sur l’unité cen­trale devrait mod­élis­er cor­recte­ment les valeurs physiques du matéri­au pour la fric­tion et la resti­tu­tion (rebondisse­ment).
  • Les émet­teurs vont main­tenant simuler en par­al­lèle sur les threads de tra­vail.

Voilà, je vous pro­pose une petite présen­ta­tion réal­isée par Mele­tou qui vous présen­tera de façon pra­tique une pre­mière util­i­sa­tion de Nia­gara:

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.