Discussion :

[Gregouar]

Bonjour à tous,

Ça fait un certain temps que je ne suis plus venu par ici, mais peut-être que certains vieux briscards parmi vous se souvienne d'Holyspirit que je développais il y a quelques années. Plus récemment (il y a 6 ans quand-même ), j'avais commencé à travailler sur un début de 2.5D shading engine (i.e. utilisation d'asset 3D prérendu old-school en utilisant des techniques d'éclairage modernes) avec la SFML et OpenGL, en C++, qui ressemblait à quelque chose comme ça:


Puis j'ai été fort pris par mes études, tout ça. Cependant, la nostalgie du développement de jeux me touchant de plus en plus, j'ai décidé de m'y remettre. Et pour ça, j'ai décidé de commencer d'abord par développer un nouveau moteur d'éclairage 2.5D, toujours avec la SFML. Je suis donc ici pour vous en parler, vous montrer un peu ce que je bricole et si possible avoir des retours et idées pour améliorer tout ça. Je compte aussi me servir de ce topic un peu comme un blog de développement, expliquant dans différents messages les techniques que j'ai mises en place pour arriver au résultat (n'hésitez pas à me demander l'un ou l'autre point que vous auriez envie que j'explique plus en détails! ). En parlant de résultat, pour le moment, ça ressemble à ça:




Fiche technique

• C++
• SFML/OpenGL
• Deferred Rendering
• PBR shading
• Isometric/2.5D assets

Concept de base

L'idée est très simple (et pas original : il y a plusieurs exemples sur youtube, sinon Pillars of Eternity utilise un concept similaire) : beaucoup de moteurs de rendus 3D utilise une technique qu'on appelle "Deferred shading" qui consiste à reporter le plus loin possible le calcul de l'éclairage de la scène. Concrètement, ça se fait en rendant toute la géométrie de la scène dans différents buffers qui contiennent l'information des fragments (i.e. pixels à l'écran): leur couleur diffuse, l'orientation de la surface, le matériau et la position dans la scène. Ensuite, basé sur ces informations là, le shader d'éclairage calcule l'illumination de chaque pixel affiché à l'écran. Le gros avantage de cette technique est que le calcul d'éclairage n'a besoin de ce faire qu'une seule fois par pixel, au lieux d'une fois par pixel par objet (on n'a pas besoin de calculer l'éclairage d'un pixel caché par un autre objet, en gros). Je vous invite à consulter ce tutoriel pour plus d'explications.
Et maintenant, tout ce qu'il nous reste à faire c'est mélanger ces techniques d'éclairage avec des objets high-poly prérendus, où au lieu de prérendre un modèle déjà éclairé, on pré-rend les 4 passes (couleur, orientation, matériaux, hauteur). Par exemple:


Et donc dans la scène:
Albedo:

Normal:

Heightmap:

Material:

+ encore des passes pour le bloom, SSAO, shadows maps, etc.

Ce que le moteur fait actuellement

• Calcul de la géométrie de la scène en tenant compte de la heightmap pour calculer l'intersection d'objets 2.5D en temps réel.
• Éclairage de la scène en utilisant des techniques PBR (i.e. Physically Based Rendering).
• Calcul de projection d'ombres pour lumière directionnel (type soleil) basé sur la géométrie visible.
• Calcul de projection d'ombres dynamiques pour lumières omnidirectionnelles en utilisant de la géométrie 3D basique invisible ajoutée à la scène (j'expliquerai ça dans un post à part).
• SSAO
• Bloom

La suite à court terme
Il reste encore beaucoup de travail pour améliorer l'architecture globale du moteur, ajouter des fonctionnalités de base et surtout l'optimisation (j'ai déjà des idées que je vais implémenter sous peu, je vous tiens au courant). Je compte aussi ajouter bien évidemment des objets animés. Ensuite, je voudrais aussi développer un shader pour rendre l'eau, avec si possible détection de la géométrie pour ajouter de la mousse. Je voudrais aussi ajouter la possibilité de faire de la pluie, qui humidifierait les zones exposées (ça devrait être facile en utilisant la même technologie que pour la projection des ombres directionnelles et changer les propriétés de type "matériau" du fragment exposé).

La suite à long terme
Utiliser le moteur pour un projet de jeu indie open-source (non pas Holyspirit 2 ). Mais je ne me sens pas encore prêt à communiquer plus là-dessus.

Et les sources dans tout ça ?
Pour le moment, je préfère ne pas trop les distribuer car beaucoup de choses sont encore trop brouillonnes je pense. Cependant, je peux vous les envoyer sur demande. ;-p

[Guntha]

Salut,

J'avoue que j'ai plussoyé avant d'avoir lu tout le poste, parce que les images étaient jolies :p

C'est pas con d'utiliser du deferred sur de la 2D, sachant que c'est difficile d'avoir un bon antialiasing dans ce type de rendu: toi, l'antialiasing est directement dans les sprites

Je crois que le projet Elysian Shadows faisait aussi un éclairage 3D sur de la 2D (je crois qu'aux dernières nouvelles, au final, la scène est complètement en 3D avec une projection orthographique...)

J'ai hâte de voir tout ça en mouvement =)

[el_slapper]

J'avoue que j'ai plussoyé avant d'avoir lu tout le poste, parce que les images étaient jolies :p

Tout pareil. C'est de la bonne came. Et le bizarre anneau violet rend bien, aussi, de mon humble opinion.

[Gregouar]

Yeah merci

bizarre anneau violet

C'est mon superbe tore de test de matériaux

[LittleWhite]

Bon retour !
Cela s'annonce bien !
J'attends une vidéo, style cycle jour/nuit, donc avec la lumière du soleil qui bouge et les couleurs qui changent (passe de post process ?).

[Gregouar]

J'attends une vidéo, style cycle jour/nuit, donc avec la lumière du soleil qui bouge et les couleurs qui changent (passe de post process ?).

Autant changer la couleur, intensité et lumière ambiante est facile (ainsi que pourquoi pas l'exposition vu que je travaille en HDR), mais faire les ombres directionnelles qui bougent en temps réel n'est pas possible pour le moment. C'est une des choses que je voudrais encore trouver un moyen d'améliorer: le calcul de la projection de l'ombre est très lent car je dois le faire côté CPU (en gros c'est assez simple: je parcours tous les pixels du sprite 2.5D, je calcule la projection sur le sol et je dessine le fragments dans une autre texture ; ça donne bien évidemment un résultat approximatif mais je blur le tout et ça rend pas mal au final). Donc je ne le fais qu'une fois au moment de générer la scène, et ça prend déjà du temps.
Une idée pour essayer d'améliorer ça serait peut-être d'essayer de travailler avec un compute shader (?) mais il faut encore que je me renseigne là dessus.

[LittleWhite]

Arf, j'avais oublié que c'était des sprites .
Du coup, pourquoi utiliser des sprites (2D donc), alors qu'en 3D, ce serait plus simple ?

Sinon, il faut bel et bien faire un prérendu de l'ombre (possible en offline) et pour l'appliquer, il faudrait appliquer une rotation (suivant position du soleil) et une déformation (suivant hauteur du soleil). L'ombre serait toujours la même, mais serait simplement positionnée autrement suivant la position du soleil.

[Gregouar]

Du coup, pourquoi utiliser des sprites (2D donc), alors qu'en 3D, ce serait plus simple ?

La première raison est que c'est fun.
La seconde est que je suis incapable de faire du lowpoly, alors que faire du highpoly est plus simple.
La troisième est que j'aime le côté oldschool que donne le rendu 2.5D.

Sinon, il faut bel et bien faire un prérendu de l'ombre (possible en offline) et pour l'appliquer, il faudrait appliquer une rotation (suivant position du soleil) et une déformation (suivant hauteur du soleil). L'ombre serait toujours la même, mais serait simplement positionnée autrement suivant la position du soleil.

Ce que je fais est plus compliqué que ça, mais je calcule déjà la projection de l'ombre en fonction de la position du soleil. Le seul problème est que recalculer la projection avec le soleil qui bouge est très couteux. Le deuxième problème est que vu que je ne projette l'ombre que de la géométrie visible, on est limité à faire un soleil qui se trouve dans le dos de la caméra, avec une orientation assez proche.

[Tonton Nico]

Salut Gregouar,

Je ne comprends pas du tout de quoi il est question mais en tout cas le rendu et l'art graphique est vraiment bien ! je ne peux que te conseiller de continuer ton projet

TontonNico

[Mat.M]

salut Gregouar eh bien bravo pour continuer sur ce projet
Quant à passer à la 3d moi aussi j'hésite et puis faut penser à une conversion éventuelle sur les tablettes ( Android..)
un jeu en 3d temps réel ça doit pomper beaucoup de ressources sur une tablette d'où l'intérêt de la 2d

[Gregouar]

un jeu en 3d temps réel ça doit pomper beaucoup de ressources sur une tablette d'où l'intérêt de la 2d

Je ne suis pas trop au courant du hardware dans les tablettes actuelles, mais je ne pense pas que ce que je fais soit vraiment adéquat pour une tablette... même si je suis en train d'améliorer les performances autant que possible, ça reste assez gourmand (beaucoup plus qu'une application 2D standard). Au final, j'évite juste la case "afficher des milliers de triangles" (ce que les GPU sont optimisés pour) mais les couts en perf pour le shading restent les mêmes. De plus, je dois rendre chaque sprite en X4, ce qui veut dire un cout assez élevé en lectures de textures. En fait, je ne suis pas sûr que le gain en performances entre 2.5D comme je fais et 3D soit si important.

Par contre, je pense que les tablettes actuelles sont tout à fait capable de faire tourner des applications 3D, il y a des exemples de jeux au rendu assez bon il me semble. Pour moi la plus grosse difficulté est la création d'assets.

Je vous parlerai bientôt de l'optimisation que je suis en train de mettre au point. Mes premiers tests sont assez concluants.

[Gregouar]

Re-bonjour la compagnie,

J'ai mis au point l'optimisation dont je vous parlais, et donc me voici pour vous expliquer ça. Le problème, le voici:

J'ai placé quelque chose comme 400 tores dans la scène et évidemment, rendre toute cette géométrie dans les 4 buffers 2 fois (une passe pour l'opaque et une passe pour l'alpha, ici l'anticrénelage), ça consomme beaucoup de performances (on peut voir que je suis à moins de 10 images par seconde) ! Peut-être que certain d'entre vous me diront d'utiliser des FBO et c'est réglé. Sauf que c'est juste une simulation pour tester et qu'en vrai je voudrais pouvoir faire des scènes complexes avec beaucoup d'objets différents.

Alors, comment faire ?

Heureusement, en général, la scène est principalement composée d'éléments statiques, qui ne bougent pas ! Dès lors, pourquoi se fatiguer à refaire le rendu de leur géométrie à chaque fois, recalculer le depthbuffer, etc alors qu'une seule fois suffirait ? Autant faire une fois le rendu, le garder en mémoire, puis dessiner par dessus les objets dynamiques qui bouge, et pourquoi pas refaire le rendu si jamais un élément qui devrait être statique aurait bougé, non ? D'autant plus que tout l'éclairage est déjà "deferred" et est donc calculé que sur le rendu final !

Bien sûr, on ne peut pas se permettre de faire le rendu de toute la map, ça serait un peu trop gourmand en mémoire (je pense). Dès lors, j'ai décidé de couper mon écran en "plein" (pas trop non plus) de sections carrées, que je prérends. Ensuite, il suffit de vérifier si un object statique à bougé dedans, et si oui refaire le rendu que de ce morceau là de l'écran (en utilisant par exemple le stencil buffer). Bien sûr, ça ne marche pas si on bouge le caméra ! On doit alors recalculer le rendu tant qu'on bouge la caméra et ça donne un résultat bien saccadé... Ma solution est donc de travailler avec "un écran virtuel", un buffer, un peu plus grand (d'une section en faite) que l'écran réel. Dès lors, je peux le faire bouger avec la caméra, en ne recalculant éventuellement que la portion qu'il faut si on arrive à la limite (on copie les buffers, on décale d'une section et on recalcule juste la bande qu'il manque).

Maintenant, grâce à ça, je peux rendre ma scène et obtenir les même performances que sans aucun tore affiché à l'écran (50-60 FPS sur mon portable pour le moment). Avec uniquement une baisse quand on bouge la caméra, avec juste une frame qui descend à l'équivalent de 25 FPS (juste celle où on met à jour la bande à afficher en gros).

Je pense que cette optimisation va être l'un des avantages principaux du fait de travailler avec un moteur isométrique.

[Gregouar]

Et je m'amuse avec la Screen Space Reflection:

[LittleWhite]

Qu'est ce qui est réfléchit ? Les autres sprites ? ou juste une skybox et les lumières ?

[Gregouar]

Le principe de la Screen Space Reflection est de réfléchir les autres entités.
Bien évidemment, vu qu'on ne travaille qu'avec la géométrie visible le résultat n'est pas parfait (typiquement on ne sait pas réfléchir l'arrière de l'arbre). Mais en général ça donne une touche plutôt sympa en plus. Surtout que ça n’arrivera pas, je pense, d'avoir un grand objet réfléchissant où on pourra voir les artefacts (contrairement à par exemple un FPS).

Le principe est assez simple: pour chaque fragment, on calcul le rayon qui part de la caméra et qui est réfléchit selon la normale du fragment. Ensuite, on fait un raytracing pour trouver le premier objet intersecter, en utilisant le depthbuffer (d'où le fait que c'est un effet gourmand, il faut se taper du raytracing en temps réel).



Avec et sans SSR.

[yaraco]

Franchement impressionnant ton boulot Gregouar!

Ça m'a donné envie de cliquer sur le lien de ta signature, dommage qu'il soit down!

[Gregouar]

Franchement impressionnant ton boulot Gregouar!

Ça m'a donné envie de cliquer sur le lien de ta signature, dommage qu'il soit down!

Merci ! Et oops oui, il faudrait que je le retire de là à l'occasion... en attendant, tu peux jeter un oeil ici: holyspirit.

Sinon tu peux aussi consulter une capture du site.

[yaraco]

Ahhhh oui, ok, haha, balèse! Je crois qu'on joue pas dans la même catégorie!

Y'avait combien de personnes derrière ce projet?

[Gregouar]

Y'avait combien de personnes derrière ce projet?

C'est assez difficile à dire, ça dépendait des moments. A l'origine, le noyau dur c'est surtout mon frère Bravach (graphismes 3D et animations, surtout des personnages) et moi (programmation et graphismes des décors). Mais on a travaillé avec tout un tas d'autres gens: Killpatate/stilobique, qui faisait aussi les graphismes 3D, mais lui c'était les beaux bâtiments comme l'abbaye que j'utilise encore ici comme asset ; Roger qui écrivait les dialogues ; Martin Cap qui s'occupait des musiques et du sound design avec ses amis (Julien Renoux, Marine Desmolin), ainsi que Clément Duquesne qui nous a fait des belles musiques aussi ; on a au,si eu l'aide d'un Polonais pour la traduction (Igor Paliychuk) ; puis on a eu de l'aide de différentes personnes pour le site web (Angelis pour le design, Schnafon et EnTraversDesNéons pour le codage) ; j'ai aussi fait faire l'UI par Cremuss, un graphiste freelance qui nous a en plus donné tout un tas de modèles 3D (notamment les guerriers squelettes). Et j'espère n'avoir oublié personne... oh si, on avait plusieurs beta-testeurs fidèles bien sympas et on a reçu de nombreux conseils pertinents de King Kadelfek.

Ahhhh oui, ok, haha, balèse! Je crois qu'on joue pas dans la même catégorie!

Haha c'est juste une question d'ambition & motivitation, j'étais jeune (et stupide) mais très motivé donc je m'étais lancé dans un gros projet et je n'ai pas démordu pendant 5 ans, c'est juste pour ça qu'on arrivé à ce résultat sympa.
Mais après, j'ai commis beaucoup d'erreurs de design à cause de mon inexpérience, qui ont fini par rendre le projet très difficile à entretenir. Mais c'était totally worth it et je recommande à quiconque intéressé de faire de même.

Au passage, voici un petit gif du moteur en mouvement:

[Gregouar]

Ce n'est pas grand chose, mais j'ai ajouté la possibilité d'activer le parallax mapping sur les textures de sol. A l'avenir, je compte peut-être utiliser ça pour permettre d'ajouter dynamiquement du relief (en travaillant avec 2 heightmap, celle de la texture plus celle du relief) ; mais je compte surtout l'utiliser pour calculer le rendu de l'eau (je compte générer des heightmaps pour faire les vagues).

Sans parallax:


Avec parallax:


Etant donné l'angle de la caméra et le grosse différence d'hauteur que je veux pouvoir gérer (i.e. des vagues), il m'a fallu implémenter une technique de parallax utilisant des lancés de rayon pour calculer le point d'intersection avec la géométrie de la texture. C'est assez traditionnel comme méthode, mais aussi relativement gourmand, donc à ne pas abuser (même si ça ne se sent pas trop ici vu que j'ai mis mon sol en static, donc je ne calcule la géométrie que quand c'est nécessaire).