Lanternes en vidéo

Une lanterne posée sur le sol, c'est rigolo, mais une lanterne qui tombe du plafond, c'est encore mieux ! Voici un rendu rapide (enfin, c'était la modélisation qui était rapide, le rendu, lui, a quand même pris 6 heures) de la lanterne du post précédent qui chute et rebondit sur le sol. Il a suffi de laisser faire le moteur physique de Blender, et le tour était joué. On admirera les effets de lumière sur le sol quand la lanterne le percute.

Fembots and fast vehicules

C'est à partir de concepts plus virils que d'habitude que je me lance dans mon prochain projet d'animation avec Blender. Au menu, voici une tentative de modélisation de visage avec lequel j'essaie de créer une androïde.

J'ai également modélisé un petit véhicule rapide pour se déplacer dans le désert, nom de code "fennec".

Puisque l'on parle de désert, le défi principal sera d'en modéliser un qui ressemble à quelque chose. J'ai commencé à créer plusieurs modèles de cactus pour peupler un peu tout ça.

Bonne année !

Je cherchais à faire un terrain herbeux qui soit joli, histoire d'installer Fluttershy dans une scène un peu sympa. Mais maintenant que j'ai de l'herbe (merci le tuto BlenderBrit), je me surprends à vouloir en mettre partout. Voici donc un petit message de nouvelle année, car je sens qu'elle va être longue et dure.

Un trilobite - Deuxième partie

Défiant toutes les idées préconçues sur l'anatomie de ces charmantes petites bêtes, j'ai muni mon trilobite d'une colonne vertébrale en plus de son exosquelette. Mais que les paléontologues se rassurent, il s'agit juste de fournir les outils pour animer mon trilobite plus fossilement (ah ah!).

Bon, et puis, il a fallu lui donner de la couleur. J'ai donc opté pour une chitine mouchetée du plus bel effet, avec un aspect rugueux très années -250M.

Vous avez peut-être vu sur mon feed Twitter (c'est à droite de l'écran, là) ma scène sous-marine. Je pense que vous voyez où je veux en venir !

Un rocher !

Je continue à construire les objets dont je vais avoir besoin dans ma scène. Voici un rocher, lourdement subdivisé, et lourdement déplacé à coups de textures de bruit, de marbre et de voronoi (j'ai suivi ce tutoriel).

J'aime beaucoup la manière dont ces 3 textures travaillent à différent niveaux de détail, donnant de la profondeur et un aspect plaisant au rocher. Le tutoriel explique ensuite comment accélérer le rendu en faisant un "bake" des textures et en les appliquant à un objet low-poly. Pour l'instant, je le garde comme ça!

Carreaux

J'ai plein d'idées de scènes, mais pas vraiment les skillz, alors je continue à faire des choses hyper simples pour me faire la main. Voilà par exemple un sol carrelé, créé en utilisant les modificateurs "bevel" (pour biseauter le bord de chaque carreau) et "array" (pour carreler toute la salle à partir du même objet). Pour le matériau, on aura fait très simple en combinant simplement le shader diffus avec un shader glossy.

La nouveauté, ce sont mes tentatives au niveau du compositing. J'ai tenté de combiner le vignetage (assombrissement des bords), de bidouiller la mise au point, ainsi que le contraste.

Peut-être maintenant devrais-je faire quelque chose avec ces murs ?

Vase - Animation

Voilà, l'animation est complète ! J'ai rajouté un écran de texte, des fondus au noir, et de la musique. Le tout a un intérêt artistique plus que limité, mais c'est la confirmation que j'ai une solution complète à ma portée. Reprenons.

Tout d'abord, l'animation en elle-même. Cela a plutôt pris 5 heures que 6, mais ce fut quand même une bonne partie de la nuit avec le GPU tournant à fond. J'ai fait un rendu vers du PNG, pour éviter de perdre en qualité.

Ensuite, la musique. Il s'agit d'une retranscription plutôt hasardeuse de la ligne de batterie de Joe Morello dans Take Five de Paul Desmond. C'est donc en 5 temps, et c'est composé en utilisant le logiciel Hydrogen, avec lequel il est facile de composer des motifs et de les combiner. En tout état de cause, il aurait été intéressant de travailler un peu plus la musique avec Audacity, par exemple, pour y ajouter des effets d'écho ou d'assourdissement du son. J'exporte en Flac, toujours dans l'optique de ne pas perdre en qualité.

Enfin, le montage vidéo proprement dit, avec l'éditeur de Blender. Une fois compris les principes de base, il est vraiment aisé d'intégrer ses rushes, de faire les coupes, d'ajouter la musique, et de faire les fondus au noir. J'aurais pu faire le montage au sein du même projet que l'animation du vase, et effectuer le rendu d'un coup, mais j'ai préféré séparer, parce que je ne voulais pas attendre 5 heures de plus. Donc, nouveau projet, et import de mes 125 images.

Je fais un rendu en HD, vers le format QuickTime, en utilisant le codec vidéo H264 et le codec audio AAC. Les détails pour faire un rendu compatible avec Youtube sont là.

Feuille de route

Plus à usage personnel qu'autre chose, voici ma feuille de route.

Serveur de logs
La base est faite, l'on peut envoyer ses logs sous le format par défaut
- Ajouter la possibilité de créer des formats spécialisés
- Ajouter un visualisateur de logs

Serveur de listes
Les structures de base pour les listes sont à peu près correctes.
- Ajouter des tests unitaires
- Développer le serveur en lui-même
- Ajouter les mécanismes d'acquisition de verrous sur les listes
- Ajouter les mécanismes de signalement de changements
- Créer un éditeur de listes

Serveur d'authentification
Le code est plus ou moins là, mais complétement épars.
- Créer le serveur d'authentification
- Ajouter des systèmes fins de permissions
- Ajouter un éditeur de comptes

Serveur de jeu
Tyrion a démarré sur les chapeaux de roues avec le système de magie. Il va falloir fournir un cadre solide via des APIs vers les autres sous-systèmes, pour permettre un développement aussi aisé que possible.

Accès concurrent aux listes de propriétés

Je n'allais quand même pas laisser de côté un tel sujet! Récapitulons. Nous avons:



- Une base de données contenant les listes
- Un serveur de listes (unique), qui fournit l'interface vers la base
- Les serveurs, qui communiquent avec le serveur de listes pour récupérer et sauver les listes
- Les clients
- L'interface d'administration Web, qui cause directement à la base de données.

Les clients ne doivent pas modifier les listes directement, mais indiquer leurs actions aux serveurs, qui modifient les listes en fonction. Les serveurs possèdent un cache des listes, et récupèrent auprès du serveur de listes celles dont ils ont besoin. Tentons de dérouler un exemple pour voir comment tout ceci peut fonctionner.

Le Roi Minablos se connecte sur un serveur. Le serveur récupère auprès du serveur de listes l'ensemble des listes dont il aura besoin, c'est à dire la liste du personnage, les listes parentes, les sous-listes référencées dans la liste (par exemple l'inventaire), et ainsi de suite (encore un diagramme, je suis chaud sur Dia, là!).



Les premières fois, l'on aura probablement une bonne partie du monde à télécharger depuis le serveur de liste, mais, le cache aidant, les serveurs seront rapidement à jour. Pour chaque liste, le serveur détermine s'il a besoin d'un accès en lecture seule, ou d'un accès en écriture, en différenciant les listes correspondant à des objets réels, qu'il gère (le Roi Minablos, une bouteille d'huile d'olive), et les objets virtuels, qui correspondent à des attributs et des propriétés générales du monde (ainsi, la liste "huile d'olive", dont dérive la bouteille, contient les propriétés générale de l'huile d'olive, et n'est accessible qu'en lecture seule).

Le Roi Minablos se saisit d'une bouteille d'huile d'olive, et envoie la requête correspondante au serveur. Le serveur modifie la liste du Roi Minablos, en y référençant la bouteille, et sauve les nouvelles listes auprès du serveur de liste.

Plus compliqué: le Roi Minablos fait pousser un olivier. C'est un cas à part, puisque le serveur doit créer une nouvelle liste. Plutôt que de gérer un long appel au serveur de listes, l'idée est pour le serveur de demander au démarrage un grand nombre de listes vides, dont il peut user comme bon lui semble, et d'en demander d'autres, de manière asynchrone, quand sa réserve s'épuise. Dans le cas de notre olivier, le serveur assigne une de ses listes vides, la fait dériver de l'objet olivier, lui met le Roi Minablos comme propriétaire, puis la référence auprès du serveur de liste.

Encore plus compliqué! Le maître de jeu gère une malédiction lancée par un sorcier maléfique, qui a rendu toutes les pommes empoisonnées. Il modifie dans son interface d'administration les propriétés des pommes. L'interface modifie la base, qui réveille le serveur de listes, lequel rafraîchit ses listes, et envoie des notifications à tous les serveurs qui avaient dans leur cache la liste des pommes. La prochaine fois qu'un joueur voudra croquer dedans, ça fera mal aux gencives!

Trading

Petit aperçu de ce que va donner la GUI de trading



L'idée est de permettre au joueur de choisir lui-même la disposition des éléments d'interface, à travers l'utilisation du wxAuiNotebook de chez wxWidgets. Pour l'instant, il n'existe que deux types de composants: la liste des marchandises, et l'inventaire. Je vais y ajouter le carnet d'ordres, et enfin la visualisation des prix du marché en temps réel.

Le serveur est séparé du serveur de jeu AdH, ce qui me permet d'être plus léger, et d'identifier les composants partagés pour les mettre dans une bibliothèque à part. A terme, je devrais avoir migré de nombreux composants, rendus génériques, vers cette bibliothèque, ce qui devrait permettre de créer très facilement des serveurs spécifiques, voire de monter des clusters. Mais pour le moment, j'essaie de trouver un gameplay sympa pour la partie trading. Je compte bien que ça soit le souk, dans le sens premier du terme!

Création dynamique des îles

C'est fait, l'on peut maintenant créer les îles dynamiquement! Dans la console, l'on tape par exemple:

/island create here 1457 Minos

et l'île Minos, créée à partir de la racine 1457, apparaît sous vos pieds.

Il me reste cependant à gérer l'UTF-8, car pour l'instant, l'on ne peut pas créer l'île de Ré!

Rhaaaaa!

C'est le cri primal du programmeur qui a passé de trop nombreuses heures à traquer des bugs stupides.

C'est en effet le pompon: en 3 jours, pas moins de 3 bugs majeurs qui sont venus tout bousiller. Reprenons dans l'ordre:

- Tout d'abord, ce stupide état OpenGL qui me cassait la couleur de mes îles et leur réflexion, décrit dans le post précédent

- Ensuite, le plan de clipping qui commençait à faire des siennes, coupant mon décor de manière différente en fonction de la taille de la mer (je ne vois toujours pas le rapport!), qu'il a fallu calmer à coups de osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR

- Enfin, un bug encore plus stupide: j'ai voulu charger dynamiquement les îles en threadant le calcul des altitudes et des normales, parce que cela prend un bon bout de temps. Mais surprise, les performances étaient épouvantables! Après un bon moment et beaucoup de recherches, j'ai fini par me rendre compte que tous les threads restaient sur le même CPU, et que cela était dû à OpenSceneGraph qui force l'affinité des threads graphiques, c'est à dire indique à chaque thread quel processeur utiliser, améliorant les performances de l'ordonnanceur du système d'exploitation qui n'a pas à se poser de questions. Mais là où tout part en vrille, c'est que les threads fils du thread principal se retrouvent avec la même affinité, et tout le monde se retrouve sur le même CPU, délaissant totalement les autres!

Ces bugs sont résolus, mais de nombreux problèmes subsistent. En premier, l'agrandissement de la zone d'eau cause maintenant une pixelisation excessive de la texture de reflet, ce qui, plus simplement, veut dire que c'est moche. De toutes façons, mon eau, si elle rendait plutôt bien à courte distance, est bien trop réfléchissante lorsque l'on prend de l'altitude. Ce ne sont plus des îles en Méditerranée, ce sont des tas de farine sur un miroir!

Archipels

Pfiou! Il a fallu se battre avec OpenSceneGraph, mais voilà enfin un archipel digne de ce nom.

Tout d'abord, il semblerait que charger un fichier 3D mette la machine à états OpenGL dans une configuration bizarre, qui me cassait à la fois mes couleurs et ma réflexion. Après de longues batailles, j'ai fini par contourner le problème en m'assurant que tous mes objets "spéciaux" seraient affichés en premier.

Ensuite, il m'a fallu me battre avec mes îles, et la taille de la grille pour les accueillir.

Mais bon, on s'approche de la création dynamique des îles, et bientôt, les Dieux feront surgir des îles fertiles des océans furieux!

Permissions

Je viens juste d'ajouter un petit système de permissions, afin de contrôler les commandes des joueurs.

Comme créer un éditeur de monde me semble au dessus de nos forces, la création du monde se fera en temps réel à partir du client, à travers certains avatars possédant des pouvoirs supplémentaires, tels des dieux, des demi-dieux, ou autres créatures magiques. La première commande permet à l'avatar de savoir où il se situe dans les coordonnées du monde:

/where

renvoie par exemple:

1@-57.446,-418.098,66.9607

pour l'avatar possédant la permission "locateSelf".

Plus tard, il sera possible de créer des îles en définissant ses coordonnées et quelques paramètres de base, et tous les joueurs de la zone devraient voir apparaître le nouvel archipel.

Une update de l'updator

Je me suis concentré ce week-end sur la vérification et le téléchargement des fichiers, et l'ensemble commence à ressembler à quelque chose.

Au moment où l'utilisateur tente de se connecter à un serveur, l'updator télécharge un fichier XML dont l'adresse lui a été indiquée par le serveur. Ce fichier XML contient la liste des ressources, et leur signature SHA1.

L'updator regarde alors les fichiers présents localement.

- Si le fichier est présent en distant, mais pas en local, il le télécharge.
- Si le fichier est présent en distant et en local, il calcule le SHA1 du fichier local et la compare avec la signature du fichier qu'il est censé recevoir. Si les signatures diffèrent, il télécharge le fichier distant et écrase le fichier local.
- Enfin, si le fichier est présent en local mais pas en distant, il le supprime.

Voilà par exemple ce que pourrait voir l'utilisateur lors de la première connexion:



L'utilisateur se connecte pour la deuxième fois, et tous les fichiers étant déjà là, le processus est beaucoup plus rapide, il suffit de vérifier les signatures.



Allons donc bidouiller le fichier cannon.obj, par exemple en supprimant une ligne. A la prochaine mise à jour, l'updator détecte que les signatures sont différentes, et télécharge à nouveau le fichier.



Le tout est fait dans un petit thread d'arrière plan, qui envoie régulièrement des messages à la GUI pour mettre à jour les logs et la barre de progression, avec l'aide des "custom events" de wxWidgets.

A priori, il est possible d'obtenir la taille du fichier avant téléchargement, ce qui me permettra d'ajouter une autre barre de progression pour chaque fichier, avec pourquoi pas la vitesse de téléchargement.

Il faudra probablement se battre un peu pour que tout cela tourne gentiment à la fois sous Linux et sous Windows, mais une fois que ce sera fait, il deviendra possible de faire une vraie release d'AdH!

Updator - Graphismes et fonctionnalités

Dites bonjour à l'updator! Tyrion avait bien commencé le back-end, chargé d'aller télécharger les ressources sur un serveur afin que le client soit toujours à jour, et aujourd'hui, comme mes tentatives de donner une GUI digne de ce nom au client ont lamentablement échouées, je me suis dit que j'allais lui donner une petite GUI multi-serveurs et connecter la chose. Maintenant, l'updator peut donc obtenir les informations du serveur, incluant celles visibles sur la capture, mais aussi par exemple l'URL pour la mise à jour.



En jouant un peu avec les threads, j'ai obtenu une GUI répondant comme je le souhaite, avec des informations qui se mettent à jour rapidement. L'on voit très vite si des joueurs sont en train de se connecter, et si la connexion tombe, l'updator va réessayer jusqu'à ce que ça marche.

Maintenant que tous les bouts sont disponibles, il ne s'agit plus que de brancher la partie qui retrouve les informations du serveur avec la partie qui met à jour les données, et l'updator première version sera prêt!

Ça bouge!

Grâce aux efforts redoublés de Tyrion, le build Win32 est bien avancé, et en dehors de petits soucis avec les fontes et certains formats d'images, utilisable. Entre temps, nous sommes passés à SFML, ce qui m'a forcé à débloquer le taux de rafraîchissement. Ceci dit, c'est probablement mieux pour nos tests de savoir à quelle vitesse on tourne!

Bien sûr, envoyer sa nouvelle position à chaque image a fait exploser la bande passante, chaque client mangeant 120 kB/s. Un petit changement pour envoyer sa nouvelle position seulement 10 fois par secondes, et nous sommes revenus à un 3 kB/s beaucoup plus raisonnable. Le mouvement des autres entités devient un petit peu saccadé, mais ce n'est que partie remise, un poil d'interpolation et il n'y paraîtra plus!

Tyrion barbote

Et maintenant?

Je suis assailli par le doute.

Jusqu'à présent, le but était clair: faire un chat 3D (je parle du canal de discussion, pas du félin). Bon, bah ça y est, on peut causer, bouger, et voir les autres bouger.

Et maintenant, il y a tellement de directions à prendre que je ne suis pas sûr de laquelle choisir!

- Développer le combat? PvP ou PvE?
- Ajouter des fonctionnalités d'artisanat, de commerce?
- En rester là pour l'instant sur le code, et créer un monde plus étendu, avec plus de décors, que le joueur va avoir envie d'explorer?

Mhh!

Les avatars

Aujourd'hui, étape importante: il est enfin possible de voir les autres avatars se balader dans le monde! Il a fallu gérer une quantité importante de concepts:

- Le client doit tout d'abord demander au serveur quelle est son identité, afin de ne pas s'afficher lui-même lorsqu'il reçoit les mises à jour des positions
- Une fois l'identité reçue, le client indique au serveur qu'il est prêt à démarrer
- Le serveur enregistre la position du client, et lui envoie les informations de tous les avatars dans la zone. En même temps, le serveur envoie à tous les avatars de la zone les informations du nouveau client
- Quand le client se déplace, tous les avatars de la zone sont notifiés
- Enfin, si le client quitte la zone (par exemple en se déconnectant), les avatars de la zone sont notifiés que le client a disparu



Sur la capture, 3 autres avatars sont représentés par des ULM (le quatrième ULM, c'est juste de la déco). Lorsqu'un ULM se déplace, les autres clients le voient se déplacer. L'on envoie la matrice de position, donc l'orientation de l'avatar est correctement représentée.

Maintenant, il reste à correctement gérer l'identité des avatars, afin d'afficher leur nom. Enfin viendra la gestion des actions, mais ce ne sera pas pour tout de suite!

Sélection

Voilà, l'étape suivante est achevée: l'on peut maintenant sélectionner les objets du monde, qui s'en retrouvent entourés d'une belle boite jaune. C'est la première étape vers l'interaction avec le monde: une fois que le système de sélection sera pleinement opérationnel, il sera trivial alors de récupérer la liste des actions possibles sur cet objet, ce qui nous approche d'autant des possibilités d'aller enfin se battre!