Laurent a écrit :
Pendant ce temps, chez nvidia.

stylé ! Dur de croire que c'est du temps réel, c'est fort.

Ah oui, ça claque moins la rétine de la ménagère de 50+ mais c'est impressionnant.

La question que je me pose par rapport à Nanite c'est est-ce que ça va aider aussi sur les D.A. non photoréalistes, ou sur les "petits" projets ? Pour Lumen j'imagine que ça va aider de façon équivalente niveau workflow (quoique sur des rendus très stylisés les hacks/tricks sont souvent nécessaires)

Ah et une autre aussi : avec tous ces miyards polygones, comment ça se passe pour les collisions et le moteur physique ? Ca gère les collision meshes convexes ?

Et une dernière question un peu HS : ça fait plusieurs années que je dev (humblement pour le taf, et en bidouille R&D perso) sur Unity... C'est comment l'UE maintenant ? Mes derniers souvenirs (lointains) c'est un éditeur puissant mais la désagréable impression de devoir démonter une roue pour la remonter tant bien que mal pour faire le moindre truc non standard, là où Unity bah c'est un peu la page blanche donc...

Mais sinon j'ai qu'une envie : que Arkane nous fasse un truc avec ça.

@CBL: De ce que j'ai compris Chaos ca marche avec l'ancien pipeline (mesh low poly, préslicé, sans LODs). A mon avis ca ne bénéficiera pas de Nanite. Du moins, pas dans l'immédiat.

@Skizomeuh: Pour les collisions, Nanite devrait pouvoir générer des approximations à la volée (vu que les colls sont aussi des meshes, ils pourraient en bénéficier automatiquement.

Skizomeuh a écrit :

Et une dernière question un peu HS : ça fait plusieurs années que je dev (humblement pour le taf, et en bidouille R&D perso) sur Unity... C'est comment l'UE maintenant ? Mes derniers souvenirs (lointains) c'est un éditeur puissant mais la désagréable impression de devoir démonter une roue pour la remonter tant bien que mal pour faire le moindre truc non standard, là où Unity bah c'est un peu la page blanche donc...

Lointain comment ? Tu parles de UE2, UE3 ou UE4 ?
Perso depuis UE4, je trouve ça top et tout ce qui à mon avis devait changer par rapport à UE3 a été fait comme je l'attendais. Après j'ai pas vraiment beaucoup touché Unity donc pas évident de comparer...

Epic a même fait un guide pour passer de Unity à UE4.

channie a écrit :
@CBL: De ce que j'ai compris Chaos ca marche avec l'ancien pipeline (mesh low poly, préslicé, sans LODs). A mon avis ca ne bénéficiera pas de Nanite. Du moins, pas dans l'immédiat.

Je ne suis pas sur car quand elle vole, il y a des pants entiers de décors qui s'effondrent et ça a une bonne tête de Chaos. Et sur le blog, ils précisent bien que Chaos est utilisé.

channie a écrit :
@CBL: De ce que j'ai compris Chaos ca marche avec l'ancien pipeline (mesh low poly, préslicé, sans LODs). A mon avis ca ne bénéficiera pas de Nanite. Du moins, pas dans l'immédiat.

Certains moteurs physiques permettent de gérer des collisions en signed distance field, donc peut-être qu'un jour ça pourra en profiter. Par contre des colliders avec une telle haute fréquence, ça posera des problèmes. Il faudra un truc simplifié de toute façon, même avec un collider signed distance field.

Par contre rien n'indique qu'ils ne font pas des raycasts sur le mesh de rendu pour placer l'IK des pieds.

CBL a écrit :
Je ne suis pas sur car quand elle vole, il y a des pants entiers de décors qui s'effondrent et ça a une bonne tête de Chaos. Et sur le blog, ils précisent bien que Chaos est utilisé.

Le rendu est traditionnellement détaché des collisions physiques. Donc c'est tout à fait naturel d'avoir Chaos en plus de Nanite. La question c'est de voir s'ils ont créé des liens entre les deux, ce qui serait novateur.

Nous ce que l'on veut c'est que l'editeur d'events de multimedia fusion soit intégré à Ue5.

CBL a écrit :
Je ne suis pas sur car quand elle vole, il y a des pants entiers de décors qui s'effondrent et ça a une bonne tête de Chaos. Et sur le blog, ils précisent bien que Chaos est utilisé.

Ma main à couper que les destructions de la séquence de vol utilisent le système de caching/replay d'Unreal :)

Ah ça par contre c'est fort possible.

MaVmAn a écrit :

Lointain comment ? Tu parles de UE2, UE3 ou UE4 ?
Perso depuis UE4, je trouve ça top et tout ce qui à mon avis devait changer par rapport à UE3 a été fait comme je l'attendais. Après j'ai pas vraiment beaucoup touché Unity donc pas évident de comparer...

UE3.

Faudra que je teste à l'occase. Mais comme j'ai un fort pli C# et process de Unity, j'espère que l'adaptation va pas être trop un frein.

Skizomeuh a écrit :

MaVmAn a écrit :

Lointain comment ? Tu parles de UE2, UE3 ou UE4 ?
Perso depuis UE4, je trouve ça top et tout ce qui à mon avis devait changer par rapport à UE3 a été fait comme je l'attendais. Après j'ai pas vraiment beaucoup touché Unity donc pas évident de comparer...

UE3.

Faudra que je teste à l'occase. Mais comme j'ai un fort pli C# et process de Unity, j'espère que l'adaptation va pas être trop un frein.

J'ai toujours trouvé que c'est juste une histoire de philosophie en fait. Fondamentalement, depuis l'UE3 on te donne masse outils pour faire des choses assez facilement ET tu peux entrer dans le code pour faire du pur custom et ou des fonctionnalités qui n'existent pas.

Unity comme tu dis c'est page blanche. Et franchement, pour certains trucs c'est un peu la misère. Moi qui suit dédié à la création sonore et musicale, il y a des trucs dans Unity que je trouve ultra poussifs et qui nécessitent beaucoup de travail d'implémentation côté code alors qu'avec le nombre de versions qu'il y a eut aujourd'hui, ce sont des choses qui devraient être gérées. Exemple :
- Concurrence sonore globale et par instance ( nombre de sons joués simultanément )
- Occlusion
- Type d'atténuation (radiale, cubique, capsule) etc...

L'implémenter dans l'engine inciterait des gens à utiliser leur moteur et ça éviterait des soucis de perfs. Tout le monde n'est pas codeur audio, et si la team de Unity implémente les algos nativement, ils peuvent optimiser et améliorer avec le temps.

Néanmoins, moi qui peste souvent sur pas mal de fonctionnalités existantes ou manquantes audio de l'UE ( les DSP custom viennent seulement d'arriver avec la 4.23/4.24 ), il a fort a parier que Unity a fait le pari de dire "nous, on est pas super bons en son, donc on va laisser le middleware faire son job". Ce qui en soit n'est pas totalement débile et une des raisons pour lesquelles la majorité des projets qui sortent avec Unity se reposent sur FMOD qui est hyper facile à implémenter.

Parce que même avec le nouveau moteur audio de l'UE qui se stabilise depuis quelques temps là. Je trouve quand même le middleware comme FMOD que je connais pas mal ou encore Wwise... à des années lumières de ce que fait le natif. Sérieusement, les réverbes à convolution arrivent seulement avec la 4.26.

Après l'audio en lui même n'est pas le sujet, tfaçon on sait tous que c'est surtout la partie graphique qui fait vendre du moteur. Quand on voit le pognon qui est claqué pour afficher des milliards de polys et des textures de 25km de large et qu'on a pas encore de moteur de propagation physique du son, je me remet à pleurer roulé en boule dans le salon. Bref...

...au delà du son, il y a pas mal d'aspect de Unity qui sont similaires. Il faut littéralement faire à peut près tout à l'os. Ca change un peu depuis que le visual scripting et le shader graph sont arrivés, mais pour le reste... paye tes lignes de code.

Avec l'UE, tu peux prototyper vite, arriver à quelque chose de fonctionnel, puis passer en code ou optim à mort les blueprints. Y'a pas mal de choses qui restent en blueprint (même dans les gros projets) tellement c'est puissant pour des fonctionnalités basiques.

Il faut se familiariser avec, mais une fois que t'as mis le nez dedans et que tu as un peu l'engine dans les pattes... c'est quand tu reviens sur Unity que ça piquote.

Les blueprint restent tout de même fort indigestes. C'est pas si puissant que ça, faut connaitre les fonctionnalités, bouffer des tutos pendant des mois.

Un truc comme multimedia fusion a un système de blueprint bien meilleur pour un artiste.
T'es dans ue4, tu veux que lorsqu'un perso entre dans une zone de la map bien spécifique il change de couleur de peau. T'es complement perdu avec les blueprints, tu ne sais pas trop par quoi commencer.

Dans multimedia fusion, même si tu ne l'as jamais fait, tu vas très facilement pouvoir le faire car tout est clair et bien écrit.

Y a vraiment beaucoup de travail à faire pour faciliter la vie des artistes qui veulent faire des jeux vidéos.
Par exemple, je ne comprends pas qu'en 2020 UE4 ne permette pas facilement de faire un fps juste avec une interface graphique. On devrait pouvoir créer un doom like ou un armed assault juste en bougeant des curseurs et en créant des assets.

C'est complexe comme sujet ce que tu évoques. Je suis pas d'accord quand tu dis "ce n'est pas si puissant que ça"... tu peux vraiment vraiment faire beaucoup de choses même s'il y a des limitations. Néanmoins je suis d'accord avec toi, il faut connaitre le système de blueprint et avoir un profil un peu tech pour facilement entrer dedans.

C'est la problématique sur ce qui est visuel : faciliter l'accès et l'interface c'est aussi limiter les possibilités. Si tu commences à proposer des systèmes de boutons "avancés" pour garder un niveau de personnalisation élevé, tu commences à augmenter la complexité de l'interface et donc à réduire la facilité d'accès et la compréhension pour certains utilisateurs.

Il est impossible d'avoir le meilleur des deux mondes. Tu ne peux pas avoir un système avec une forte flexibilité et haute personnalisation tout en étant ultra minimaliste et compréhensible par le commun des mortels.

Je trouve que le blueprinting de l'UE4 est un bon compromis. Il faut juste prendre le temps de former tes artistes :)

Après moi j'ai une chance, je viens d'un monde ultra tech, du code... c'est plutôt facile pour moi de m'approprier ces mécaniques. Un "If" ou "Foreach" en blueprint c'est naturel pour moi. Pour un LD ou game designer, certainement beaucoup moins.

Rien ne t'empêche de produire des blueprints pour tes artistes qui sont faciles à utiliser. C'est ce que je fais en son, et c'est aussi pour moi, pour me faciliter la vie... qui fait 95% de l'audio design dans les maps.

Autre point de vue, celui d'un total noob comme mois, qui a juste envie de réussir à se créer des petits environnement persos en VR, et qui est en train d'essayer en partant de zéro un peut tous les outils auquel il n'a jamais touché qui permettraient de faire ca.

Mon critere : ca doit me permettre d'obtenir un résultat de qualité ( aucun intérêt a créer mon environnement si au final je ne peux pas le faire ressembler a ce que j'ai en tête ) mais rester le plus simple possible. Je ne vise pas un truc commercial, même pas un truc a partager. Je le fait pour moi, et je veux juste faire un environnement statique a visiter, donc je n'ai pas forcément besoin d'outils de scripting incroyables.

Bah mon resentit aprés quelques dizaines d'heures de tutos et expérimentations, c'est que Unity et Unreal se valent globalement. Mais unreal me fournis plus de composant prêts à l'emplois, et me permet de faire un peut plus de trucs sans avoir a m'appuyer sur un autre outil externe ( Que du coup il faut que j'aprenne en plus). Et puis megascan, ca fournis quand même une putain de base d'assets. Ce n'est pas juste certains matériaux et meshs qui sont gratos, c'est toute la bibliothèque si ont utilise l'unreal engine du coup.
Hammer est vraiment, VRAIMENT rebutant. Je me suis dit que le mieux pour me faire une petite maison hantée en VR etait peut etre de partir de HL:ALyx, pour profiter de tous les assets de la campagne, des interactions / déplacements déjà préparés, et du moteur bien optimisé pour la VR. Mais l'interface est vraiment brute. Et si je ne trouve pas mon bonheur dan les assets de la campagne, pour le coup je suis bon pour me taper un paquet d'outils externes.

En outil secondaire d'ailleurs, pour modéliser la géométrie pas trop high poly sketchup est vraiment incroyablement intuitif pour un noob. Si seulement il pouvait faire correctement les UV map et normal maps, je crois que j'aurais pas eu besoin de plus.
Mais visiblement, il vas falloir que je me mette aussi à blender.

Et sinon, tant qu'on est sur le sujet, personne n'a un tuto a conseiller sur l'utilisation de la tessellation sous unreal ? Parceque j'arrive plus ou moins a l'appliquer, mais bizarement ca l'air de fonctionner exactement pareil sur des surfaces basique ( en 2 triangles ) et sur un mesh plat sub-divisé au préalable en 500 triangle au m². Alors que les tutos me disent tous que ca devrait donner de meilleurs résultat dans le deuxième cas ... (Sachant, evidemment, que je ne compte pas créer mes propres textures. Je veux juste utiliser correctement celle de megascan.)

@max d'ailleurs tu en as pensé quoi de la conf de cerny sur le son autour de la ps5?

__MaX__ a écrit :
Quand on voit le pognon qui est claqué pour afficher des milliards de polys et des textures de 25km de large et qu'on a pas encore de moteur de propagation physique du son, je me remet à pleurer roulé en boule dans le salon. Bref...

Bah justement, ils parlent un peu d'audio dans la démo. Je ne serais pas surpris que le lancer de rayon, si il peut être fait aussi rapidement pour la lumière puisse être fait de la même façon pour l'audio. Un genre de Ray Tracing Audio.

Physically accurate convolution... Je dirais que c'est le but ici.

Après c'est assez logique que le son passe au second plan : les gens ont des TV 4K HDR mais utilisent les enceintes pourries intégrées dans ces dernières.

CBL a écrit :
Après c'est assez logique que le son passe au second plan : les gens ont des TV 4K HDR mais utilisent les enceintes pourries intégrées dans ces dernières.

C'est un des sujets sur lesquels j'attends la R&D en VR de pied ferme... C'est fou qu'on en soit là alors que le realtime raytracing est une réalité.
Je suis persuadé qu'une percée technique majeure va pousser les utilisateurs à utiliser un casque, même s'ils jouent sur PC ou devant leur téléviseur... Il suffit d'une expérience binaural de base sur youtube pour s'en convaincre, le son change tout et il est vraiment maltraité depuis des années.

La fidélité de reproduction du son CBL c'est un autre problème. Par contre les algos et le réalisme de propagation du son qui implique derrière la réverbe et tout ce qui va avec, ça peut être "lu" sur des enceintes moisies même si c'est moche :D

@noir_desir avec tout ce qu'ils implémentent en natif dans la bécane ça ne peut être qu'un réel plus pour les développeurs. Surtout le HRTF. Il faut espérer que les studios poseront leurs équipes sur une exploitation complète du système cependant.

@Laurent / @BeatKitano, le tracé pour l'audio existe déjà, mais aujourd'hui il se content d'être exploité pour calculer l'atténuation sur les audio source de l'UE. Et ce depuis un moment quand même. Mais le réel calcul de propagation comme le fait Steam audio, qui n'est malheureusement pas compatible avec les consoles pour l'instant, l'UE est loin d'y être.

Et concernant la réverbe à convolution, c'est loin d'être aussi ouf que pourrait l'être un moteur avec du raytracing. C'est assez "statique". Tu fournis à ta réverbe un sample ( comme celui ci ) qui est en fait un clac assez bref joué dans un environnement avec une grosse, moyenne ou petite réverbe. Et l'algo se base sur ce spectre sonore pour générer la réverbe final avec ton mix final dans ton jeu / album / film.

Si la réverbe à convolution c'est ce qui dans le haut du panier en terme de qualité. Je reste néanmoins convaincu qu'on a la puissance de calcul aujourd'hui pour faire une véritable propagation. Il faut que les moteurs commencent à avoir en plus de propriétés physiques qui permettent de dire que cette texture c'est du béton ou du métal, que ces propriétés contiennent aussi les facteurs de d'absorption et réflexion audio.

1 - La qualité serait dingue
2 - On aurait plus besoin des baker des réverbes et produire 25 sons différents dans certains cas (l'exemple le plus courant reste les flingues)
3 - Cela ferait gagner du temps sur le design et l'implémentation, puisque une fois que les propriétés physiques sont définies, le comportement est physiquement crédible ( plus besoin de définir des zones, des bidules à droite à gauche pour faire des transitions etc etc ).

Va y'avoir quelques trucs sympas sur l'UE5 à mon avis niveau son, mais on sera encore loin loin des capacités graphiques ( d'où le succès des libs externes et du middleware ).