Un petit mot de Kevin : flux webcam et réseau, problèmes et solutions
Posté par : Caro - Le Lundi 7 Juin 2010 à 14:42
Kevin, l'un des deux programmeurs du projet, a décidé de concocter un petit billet pour revenir sur quelques difficultés rencontrées en début de production de notre projet étudiant.
Pour des raisons de facilité de développement, le logiciel Unity semblait le plus approprié pour un projet de courte durée et une équipe aux effectifs réduits puisqu'il permet de rassembler les assets du graphiste et du sound designer avec le code des programmeurs assez facilement. Néanmoins, le développement de cOma n'a pas été aussi calme que prévu...
Le choix d'Unity permettait à la base de concevoir plus rapidement notre jeu (pour procéder au prototypage de notre jeu par itération).
Le principe de cOma reposant sur l'utilisation de la webcam, l'intégration de cette feature était l'enjeu majeur du projet. Il a donc fallu se pencher sur l'aspect technique dès le début afin il de trouver une solution adaptée au gameplay du jeu. De plus, nous devions également prendre en compte la mise en place de la gestion du réseau entre deux machines pour le déroulement de la version originelle de cOma (nous revenons sur ce point plus bas dans ce billet).
Le problème étant qu'Unity ne prend pas en charge l'utilisation de la webcam au sein du logiciel à l'origine, et que l'utilisation de ce procédé en réseau ne s'est jamais encore fait avec cet outils, il a fallu trouver des alternatives. Plusieurs solutions se présentaient alors à nous :
- Coupler Unity et Flash CS4 ce qui aurait servi à faire uniquement le traitement de la webcam et d'envoyer les données de la webcam à l'intérieur du client Unity.
- Utiliser en parallèle un serveur de streaming avec un client dédié au streaming, chargé de récupérer les données de la webcam, les mettre au format OGG theora (ndb : OGG est un format audio alors que OGG theora contient à la fois de la vidéo et de l'audio et est utilisé pour le streaming sur certaines applications).
Ces deux premières solutions ont ensuite été écartées car nous avions une préférence par le fait que tout soit géré à l'intérieur d'un seul executable Unity. Pour faire simple, disons que nous désirions éviter d'avoir à lancer plusieurs logiciels simultanément lors du lancement du jeu et préférions davantage que tout soit géré en un seul processus par Unity.
Nous nous sommes donc penchés sur de nouvelles recherches pour trouver une alternative plus simple. Nous avons trouvé une librairie (image grabber) permettant de récupérer directement sous Unity le flux d'image en provenance d'une webcam. et s'en servir pour afficher les images webcam (ou "texture webcam" même si ce terme n'est pas tout à fsur un plan dans Unity.
La mise en place de cette solution semblait assez simple de prime abord mais cela s'est complexifiée lorsqu'il a fallu envoyer les textures webcam sur le PC du 2e joueur à travers le réseau. Ceci étant principalement dû au volume des données qui était trop important à gérer alors qu'Unity n'utilise des fonctions de communication réseau prenant en charge des types de données légers (des strings, des int, des byte array, des vector3 etc c'est à dire des chaines de caractères, des entiers etc...).
La première réaction face à cette difficulté a été de diminuer la résolution envisagée pour la webcam de 640x480 à 160x120 et d'encoder le flux en format d'image PNG via la méthode "Encode To PNG" d'Unity. Cela permettait d'envoyer des paquets de données à taille fixe au serveur afin que celui-ci décode l'information sur le plan vidéo pour reformer l'image envoyée par le client au lieu d'envoyer le flux brut (trop coûteux en bande passante).
Cette méthode nous a fait rencontrer des problèmes de stabilité du réseau traduite par une saturation du buffer du serveur qui n'arrivait pas à traiter en temps réel les paquets d'image entrants. Cela provoquant des "freeze" d'image intempestifs et une saturation trop importante de la mémoire du PC destinataire au bout de quelques minutes de jeu.
Nous avons donc voulu mettre en place une logique d'accusé/réception entre les deux machines afin de synchroniser le traitement et l'envoie des paquets de données en temps réel et façon correcte (c'est-à-dire que l'on voulait une version jouable du jeu qui soit fluide malgré la perte de certaines données).
Malgré tout, des latences entre le client et le serveur persistaient car la décompression du format PNG à la réception de la machine destinataire était trop coûteuse en CPU (ndb : ressources processeur).
Suite à l'identification de ce problème, nous avons procédé à un nouveau test en réseau en envoyant directement le flux webcam en données brutes au destinataire. Mais comme on pouvait s'en douter, les applications mettaient plusieurs dizaines de secondes à se synchroniser car le volume de données était inadapté à la bande passante.
Comme nous avions perdu 1 mois à trouver des solutions pour mettre en place le jeu en réseau mais qu'aucune solution n'émergeait, nous avons du nous rabattre sur une solution de secours afin de respecter les délais impartis pour terminer le développement du projet.
Nous nous sommes donc réunis avec l'équipe et avons décidé faire fonctionner le jeu en local sur une machine commune reliée à deux écrans distincts, la difficulté ne résidant désormais plus sur une économie de bande passante ou l'encodage de PNG, mais plutôt sur deux applications avec un rendu 1280x720 sur une même machine.
A ce jour, sur une machine performante, l'application se synchronise en quelques secondes et semble pouvoir traiter les images en temps réel pendant une durée (testée) de 2 heures.
Cette solution, nous ayant parue bien engagée pour la suite du développement du jeu, elle constitue aujourd'hui celle qui sera effective lors de notre passage devant le jury qui se déroulera du 24 au 25 juin.
Nous traiterons dans un prochain billet des autres problèmes rencontrés au cours de la production de cOma et de la mise en place de solutions plus ou moins "bricolées" pour parvenir à nos fins. Car développer un jeu de l'envergure de cOma en 3 mois seulement, c'est un peu comme faire travailler un programmeur avec un clavier suisse :-D
Publicité :
Billets similaires | Tagsprogrammation unity webcam |
Commentaires 4 commentaires
farwarx le 09 Juin 2010 à 12:26
Le PNG est un super format mais les fichiers sont bien plus lourd que du JPEG.Peut être qu'en mettant une limite sur le buffer... enfin, je ne suis pas programmeur ;)
Et sinon, créer un flux vidéo comme pour la TV par ADSL? Mais il faudrait encoder le flux sur le poste serveur...
Comment les 2 joueurs pourront-ils jouer avec un seul clavier?
Seb le 09 Juin 2010 à 13:01
Le PNG était la seule méthode de compression fournie avec les objets textures dans Unity3d. C'est surtout à l'encodage que la baisse de performances se faisait sentir.Question buffer c'est là que nous perdons le contrôle, le moteur réseau d'Unity n'est tout simplement pas conçu pour véhiculer ce type de données, ni ces quantités.
Pour balancer un flux oui il aurait fallut (avec du recul ça aurait été la bonne solution, mais trop coûteuse en temps de toute façon pour notre projet) de faire notre propre socket avec encodage/decodage du flux vidéo.
Sur les deux joueurs un seul des deux interagit avec l'univers, le second joueur n'est que spectateur, avec un point de vue opposé et plus complet (il voit des éléments du décor que le premier joueur ne vois pas). Son rôle consiste à donner ces informations au joueur 1 au travers de la webcam. On avait envisagé qu'il puisse déclencher des évènements ou plates-forme à distance mais ça n'a pas été retenu faute de temps.
farwarx le 09 Juin 2010 à 13:42
C'est vrai qu'en réseau, avec 2-3 actions à recharger pour le ghost, ça aurai pû être pas mal ;) Et les coéquipiers seraient en communication avec oreillettes ;)Il sort quand sur PS3? ^^
Courage pour cette fin d'année scolaire!!!!!
Caro le 20 Juin 2010 à 23:45
Merci :)