Discussion :

[Guntha]

Bonjour,

Je n'ai pas beaucoup avancé, entre autres à cause de projets pro qui ont empiété sur mon temps perso, mais aussi parce que j'ai pris une décision: comme on se déplace dans les trois dimensions, je trouvais qu'il était difficile de s'y retrouver avec un caméra où l'angle est fixe, du coup j'ai décidé de faire une caméra suiveuse, ce qui m'a un peu pris la tête mais je suis arrivé à un résultat qui me plaît, et pas trop gerbant.

Avant ça, j'ai pu faire un début d'éditeur: on peut sélectionner les objets présents dans la scène et les déplacer.
J'ai aussi fait un effet de réfraction basique: je rends une 2ème fois la scène, avec une texture éventuellement animée, et en remplaçant les coordonnées de texture des meshes par des coordonnées qui correspondent à la direction de la "lumière". Comme il n'y a encore ni normales sur mes modèles, ni atténuation en fonction de la profondeur, l'effet n'est pas terminé: la texture est aussi plaquée sur des faces qui ne sont pas censées recevoir la lumière, et c'est un peu agressif à l'oeil...

Une petite image pour illustrer tout ça (sauf l'éditeur):

(la nouvelle réfraction pète la compression du GIF, qui est donc assez gros, donc je ne le mets pas directement ici :/ Évidemment, ce serait plus agréable de voir le vrai résultat, en 60fps :p )

[el_slapper]

Sympa; j'aime beaucoup la dynamique d'accélération et de freinage.

[LittleWhite]

Les avancées sont sympas. Par contre, j'intensifierai les couleurs (les caustics plus claires, par exemple).

[Guntha]

Oui, il n'y a pas de correction des couleurs, et même pas de lumière Et j'ai pris l'une des premières textures de caustiques que j'ai trouvé sur le net ^^'

Par contre, pourquoi as-tu rendu visible le gif dans mon message? Je l'avais intentionnellement caché derrière son URL pour épargner les petites connexions (il fait tout de même 9 Mo ).

[Guntha]

Bonsoir,



Mon moteur sait enfin ce qu'est une normale, du coup j'ai pu mettre une petite lumière directionnelle, ce qui rend le rendu moins "plat"

Je suis arrivé à un résultat qui me satisfait pour les caustiques, en dehors du fait que j'ai chopé la texture que j'ai utilisé sur Internet (ici: http://www.dgp.toronto.edu/~stam/rea...ics/index.html ), en attendant d'en faire une moi-même.
De plus, maintenant, je fais le rendu en 1 seule fois: au lieu de rendre les caustiques par-dessus le 1er rendu, je fais tout dans le 1er rendu, ce qui me donne plus de contrôle dans la façon dont je blende la texture des caustiques et la texture des objets.

Du coup, je vais résister à la tentation d'améliorer le rendu et essayer de me concentrer sur un système de collision, que j'avais mis de côté jusque là.

[Guntha]

Bonsoir!

Ça m'a pris pas mal de temps, mais finalement j'ai fini par implémenter le système de collisions que je voulais. Il est encore un peu buggé et je voudrais l'enrichir, mais pour l'instant il y en a assez pour reproduire le résultat que j'avais un peu après la fin du week-end de l'année dernière. Mon système permet aussi de générer un mesh du niveau à partir des formes présentes; ce n'est pas très au point et c'est surtout destiné à être exporté pour être retravaillé dans Blender.

Au début, je voulais créer un système où le niveau est une union de formes simples (AABB, sphères, cylindres orientés...) mais j'ai commencé à l'implémenter comme si les formes pouvaient être n'importe quel polyèdre convexe, ce qui m'arrange bien. Je crois que je suis en train de refaire les brushes de Quake
Ce qui complique mon affaire, c'est qu'il peut à la fois y avoir des formes dans lesquelles on ne peut pas entrer, et des formes desquelles on ne peut pas sortir (genre la grosse boîte contenant le niveau, qui auparavant ne faisait pas vraiment partie du système de collision, mais maintenant ça me permet facilement d'avoir des formes de niveau plus compliquées). Gérer la combinaison des 2 est un peu compliqué x(

Il me reste un petit peu de boulot pour avoir le même niveau que celui que j'avais dans la dernière version que j'ai publié (il sera même un peu plus riche, notamment parce que j'ai enrichi mon système de "script": les portes sont devenues quelque chose de plus générique qu'avant). Par contre, les falaises générées aléatoirement au-dessus de l'eau passent à la trappe.

Ne faites pas attention aux couleurs chelous

[JujuPomme]

Hello,

Je suis le topic depuis le début ou presque, j'avais peur qu'il soit tombé dans l'oubli !

Ravi de voir que non ! J'admire le travail réalisé, les animations sont vraiment de qualité. Tout le courage du monde pour la suite !

[Guntha]

Merci Juju!

Je me suis décidé à sortir une nouvelle version:
http://lhuillia.iiens.net/wejv6/livr...ha_12_2017.zip

Au programme:
->Un nouveau système de collision, qui ne me satisfait pas encore complètement (il y a encore quelques cas foireux, et pour l'instant on ne peut placer que des AABB. Le triangulateur qui crée un mesh à partir des colliders du niveau n'est pas non plus au point).
Actuellement je ne supporte que des collisions entre le joueur et des colliders statiques, certains colliders peuvent être activés/désactivés (genre sur les portes). Je ne sais pas encore si je supporterai des collisions entre objets mouvants, enfin surtout si on pourra glisser sur des objets mouvants.
->La nouvelle caméra suiveuse (qui n'a pas changé depuis le mois de mars x) et qui n'a que faire des collisions)
->Une des salles a été enrichie
->Quelques changements graphiques: les caustiques que je n'avais jamais encore sorti dans une version, les algues et les clés n'affichaient rien quand on les regardait de dos à cause de l'ancienne caméra. En revanche, le rendu quand on est au-dessus de la surface de l'eau n'est pas correcte, et on ne peut pas voir la surface de l'eau quand on est en-dessous.
->Un système de script un peu enrichi, qui supporte même une forme primitive de coroutine.

Vous remarquerez que vous pouvez maintenant vous déplacer la tête à l'envers. Je ne sais pas encore si je garderai ça même si c'est pratique; les directions sont inversées quand vous êtes retournés x) Je ne sais pas comment corriger ça sans que la correction soit trop brusque sans complètement changer la maniabilité pour passer à un système à la Descent.

Ce que je prévois pour la suite:
->Encore et toujours les collisions : corriger ce qu'il y a déjà, introduire des polyèdres convexes quelconques et non plus seulement des AABB.
->Pouvoir sauvegarder et charger une partie à n'importe quel moment
->Faire un exporteur et un importeur pour pouvoir enjoliver les meshes que je génère dans Blender puis les remettre dans le jeu. D'une manière générale, enrichir l'éditeur du jeu
->Faire un exporteur de modèle animé vers un format utilisable au runtime (un chantier que j'avais laissé de côté il y a longtemps car j'utilisais assimp qui n'est pas au point concernant les animations) puis supporter les animations squelettales dans mon moteur
->Tout ce qui peut enjoliver le rendu :p

EDIT: non seulement je m'étais trompé de lien, mais l'outil d'insertion d'URL du forum me l'a en plus cassé (il raccourcissait le lien lui-même, pas seulement le libellé)
C'est maintenant un bon lien fonctionnel qui est affiché.

[dancingmad]

Très sympa !

Est-ce que tu as prévu de mettre du filtering sur les textures ? Parce que là ça pique un peu les yeux

[Guntha]

Salut dancingmad et merci,

Sur quelles textures? À part celles qui ressemblent à des briques et à du bois, toutes les textures sont en filtrage bilinéaire.

[micka132]

La question que je me pose c'est comment une brique peut nager sans papatte ni turbine?

[Guntha]

J'ai pas eu le temps de faire plus parlant pendant le week-end de développement de 2016 - d'où le nom du jeu - , et je n'ai pas eu l'occasion de me mettre à la modélisation 3D entre temps, et personne que je connais n'a le temps pour ça, mais dès que possible, je mettrai quelque chose de mieux, que ce soit pour le joueur ou les décors :p

[dancingmad]

Sur quelles textures? À part celles qui ressemblent à des briques et à du bois, toutes les textures sont en filtrage bilinéaire.

C'est moins flagrant sur ton dernier GIF, mais sur celui du 13 Mars il y a clairement un problème de rendu... Soit c'est le shader d'eau qui aliase soit c'est autre chose (ou alors c'est tout simplement le GIF qui est trop compressé). Mais bon ça à l'air mieux avec ta dernière démo !

[Guntha]

Désolé, je crois que je teste des réglages différents à chaque fois que je poste un gif ici pour en minimiser la taille x) Et les caustiques de ce gif n'arrangent rien.

[Guntha]

Bonjour, et bonne année 2018!

Je suis arrivé à un résultat à peu près satisfaisant avec un système de collisions qui me permet de mettre des polyèdres convexes quelconques dans le niveau.

J'ai commencé par abandonner le concept que j'avais où le niveau est une union de formes de laquelle on ne peut pas sortir, remplie de formes dans lesquelles on ne peut pas entrer. Il n'y a plus que les formes dans lesquelles on ne peut pas entrer maintenant. Après avoir fait quelques recherches, j'ai vu que personne ne faisait ce que je faisais, et vu comme je galérais je me suis dit qu'il y avait une bonne raison De plus, ça facilite beaucoup ma triangulation: maintenant, j'ai juste à trianguler séparément les formes.
Je trouvais qu'il y avait quelque chose d'élégant à créer un niveau comme ça, mais le gain est pour ainsi dire inexistant, comparé à faire un niveau en s'assurant soi-même qu'on ne peut pas en sortir... (d'ailleurs, en testant Radiant pour voir comment les jeux style Quake géraient la création de niveau, ils gèrent ce problème autrement: au moment de la compilation, ils vérifient s'il n'y a pas de "fuite" dans la map). Je pensais aussi que ce serait plus rapide de créer un niveau comme ça (pour faire un tunnel, j'aurais besoin d'1 forme au lieu de 3 ou plus), mais c'est en fait plus un problème d'outil que de moteur. (Radiant permet de rendre "creuse" une boîte, en créant en fait des brushes séparés pour chaque face de la boîte, le tout en 1 clic.)

Bien que je pensais que mon système était déjà compatible avec n'importe quel polyèdre convexe, il y avait plusieurs problèmes: non seulement, quand on entre en collisions avec des plans de 2 formes différentes, qui ne forment pas un angle droit, la réponse n'était pas correcte (pour corriger ça, je me suis inspiré du code de Quake, plus précisément de la fonction SV_FlyMove : https://github.com/id-Software/Quake...rver/sv_phys.c ), mais en plus je faisais une grosse approximation qui posait des problèmes: pour tester la collision entre une forme et le joueur, qui est une sphère, je me contentais de pousser les plans de la forme vers l'extérieur, à une distance correspondant au rayon de la sphère. Le résultat semblait à peu près correct avec des AABB, mais avec des formes un peu différentes mélangées, le joueur se retrouvait bloqué à des endroit où il devrait pouvoir glisser. Du coup, j'ai du changer une grande partie du test de collision, et maintenant je fais une vraie somme de Minkowski entre la sphère et la forme (mes polyèdres deviennent des assemblages de plans et de capsules au moment du test de collision).

Ça me donne un résultat assez satisfaisant pour l'instant, je vais donc enrichir mes niveaux actuels pour en profiter. Il faudrait que je vérifie si il n'y a aucune façon dont j'utilise des nombres à virgule flottante qui peuvent poser problème (entre temps, je me suis procuré plusieurs livres sur la détection de collision, qui traitent entre autres de ce problème :p )

Comme je fais quelque chose qui ressemble aux brushes de Quake, j'ai décidé d'utiliser un éditeur qui a été fait pour Quake et d'autres jeux de la même famille pour faire mes niveaux: Trenchbroom
http://kristianduske.com/trenchbroom/

J'ai fait en sorte que mon moteur puisse lire les .map avec lequel ce genre d'éditeur travaille (pour l'instant, je ne parse que l'entité "worldspawn", pour les connaisseurs). Finalement, j'aimerais bien créer entièrement mes niveaux là-dedans, animations et scripts compris, en forkant Trenchbroom si besoin :p Même si l'idéal serait d'éditer directement dans le jeu (on est en 2018 après tout).

Désolé, pas de nouvelle version ou d'image aujourd'hui :p

[Guntha]

Bonjour!

Quelques images pour montrer un peu d'avancement:







Le décor reste joli tant qu'on le laisse dans le brouillard :p

J'ai commencé ces niveaux avec Trenchbroom. Je ne gère pas l'application des textures - il faudrait que je génère mon propre .wad avec mes propres textures - mais les uv devraient déjà être bonnes, bien que j'ai des doutes.

Maintenant je regrette un peu d'avoir voulu faire un jeu avec des décors naturels; non seulement c'est plus long et plus compliqué à créer, mais ça demande un système de collisions super robuste :p (j'ai encore des bugs difficiles à reproduire...)

[Guntha]

Bonjour,

Je peux enfin appliquer les textures dans le jeu telles que je les applique dans TrenchBroom. Au départ j'avais une solution qui fonctionnait presque, avec quelques hacks, mais comme TrenchBroom permet de "tordre" les textures, en rendant les axes des coordonnées de textures non orthogonaux, j'ai fini par m'aider du code source de TrenchBroom. Et la solution était beaucoup plus simple que tout mon bricolage :p J'ai encore du mal à appréhender toutes les utilisations que je peux faire d'un dot product...

Les textures que j'ai mis pour tester sont pas très adaptées, je me suis contenté de taper "Canyon" dans Google Images :p

Pour l'instant le rendu de la map texturée dans le jeu est fait au plus simple: je fais un draw call par texture différente, je dessine donc toute la map à chaque frame, quelle que soit la visibilité de ce qui nous entoure.
Contrairement à ce que j'avais dit: pas besoin de faire un .wad, je peux mettre toutes les textures dont j'ai besoin dans un .pak (le conteneur le plus simple de la terre, qu'on meut explorer et modifier avec PakExplorer. Attention, plusieurs studios ont créé leur format .pak, qui n'ont pas toujours de rapport avec ceux d'Id :p ). TrenchBroom supporte tout un tas de format d'images, les seules limites que j'ai vues sont qu'elles ne peuvent pas avoir d'alpha et avoir des dimensions en puissance de 2.

Avant ça, j'ai ajouté une spotlight qui part de notre amie la brique, ainsi que l'ombre qui va avec:





Je me suis également occupé de quelques chantiers qui ne se voient pas sur les screenshots, notamment le partitionnement des colliders: je répartis tous les colliders dans une grille dont la taille d'une cellule est fixe, et je coupe en plusieurs morceaux ceux qui chevauchent plusieurs cellules.
J'ai aussi fait en sorte de pouvoir placer les points de départ dans une map ainsi que les zones permettant d'aller vers la map voisine depuis TrenchBroom. Après la "compilation" d'une map, je sauvegarde son mesh et ses colliders dans des formats quasiment identiques à ce qui est en RAM, ce qui me permet de charger le jeu presque instantanément.

Par la suite: je vais mieux gérer les textures de la map dans le jeu, créer un outil permettant de faire correspondre les textures utilisées dans TrenchBroom et celles utilisées dans le jeu sans effort, pouvoir placer le maximum de types d'"entité" depuis TrenchBroom.
J'ai un peu abandonné l'idée de pouvoir exporter une map vers Blender, vu que TrenchBroom est déjà assez souple pour faire tout ce que je veux dans une map, en garantissant en plus la fidélité entre le visuel et les collisions.
Je vais dès que possible m'attaquer à un éditeur visuel pour les "mécanismes", que j'ai longtemps laissé de côté :p
Je devrai plus tard m'occuper d'implémenter des modèles avec animation squelettale dans mon moteur (d'après mes dernières investigations, assimp a encore du mal avec les animations, mais j'avais trouvé un workaround pour passer outre les bugs quand j'importais un modèle Collada...)
Et puis, quelque part au milieu de tout ça, m'occuper d'un système de sauvegarde qui permet de sauvegarder et de charger n'importe où.

Bonne journée!

[Guntha]

Bonjour,

Je peux maintenant placer toutes mes entités dans Trenchbroom:

Je suis revenu sur mes maps de tests, où j'avais déjà mis toutes les features que je supporte, je peux donc directement tester si un changement casse quelque chose.

Les boîtes vertes sont les positions des caméras, et les machineries grises sont des éléments que j'ai ajouté pour compliquer un peu cette salle
Toutes les boîtes bleues sont les petits modèles affichés dans le jeu (les murs de brique, les planches de bois etc.). J'affiche seulement leur bounding box et non leurs modèles car TrenchBroom nécessite de les convertir en .mdl ou en .md2 (des formats où les vertex sont compressés), ce que j'avais commencé à faire, et leurs textures doivent être converties dans un format palettisé, ce que je n'avais pas attaqué parce que je veux éviter d'avoir un résultat visuel trop différent entre le jeu et l'éditeur, et parce que dans les prochaines mises à jour, il est possible que Trenchbroom supporte des jeux plus récents, qui utilisent des formats moins contraignants, et ce n'est pas une urgence.

Avant, les seuls éléments mobiles des maps étaient ces modèles; maintenant, je peux rendre les brushes mobiles aussi, ce qui me permet de les modéliser et les voir directement dans l'éditeur:

J'ai coupé tout un passage où je rejoignais la manivelle qui ouvre la 2ème porte, qui prenait la moitié du gif, qui est déjà gros :p

Je peux choisir de les rendre solides ou non. De plus, à la fin d'une animation, j'update leurs collisions, donc pour ouvrir cette porte par exemple, je n'ai plus besoin de désactiver un collider invisible, ce que je faisais avant.
Dans l'image du dessus, la grille au sol ne s'ouvre qu'une fois que les 2 portes sont ouvertes, quel que soit l'ordre d'ouverture.

Pour l'instant, les scripts et les mécanismes sont toujours écrits à la main dans un fichier JSON imbitable, il faudrait vraiment que je m'attaque à l'éditeur de mécanismes :p Mais d'abord, je dois faire en sorte de compiler entièrement les maps pour les charger instantanément (actuellement, seule la géométrie statique est "compilée"). Dans la structure des maps, j'ai fait en sorte que toutes les données statiques et les données qui peuvent changer soient séparées, pour que la sauvegarde d'une partie ne soit pas plus longue et compliquée que quelques memcpy().

[el_slapper]

Magnifique.

J'ai juste une remarque naïve : je n'ai pas l'impression que les dents des engrenages s'emboitent correctement. C'est une erreur de ma part, ou bien?

[guitz]

Oui l'engrenage entre les 2 roues n'est pas correct