Début mai de cette année, j'ai débuté un nouveau projet, consustant au design et au développement d'une technologie de streaming géographique à base de donnée satellitaire, qui dans les grands principes peut ressembler à GoogleEarth™.

Cependant, la ressemblance s'arrète très vite : ici, l'objet se raproche beaucoup plus du moteur de jeu vidéo que d'une « simple » affichage de carte 3D.

Une autre particularité, c'est que le but de ce projet est de pouvoir jouer en temps réel sur un mobile de troisième génération.

Phase I : GIS et rendu temps réel à haute performance

J'ai attaqué le module de rendu côté serveur : Le serveur possède une base de 60 Gb représentant le département des Alpes Maritimes à une échelle de 4 pixels par mètre carré. Les données d'altitude d'une résolution de 50×50m sont intepolés avec des patch bicubiques.

Le moteur de rendu est implémenté en Java et openGL et utilise des NIO pour un usage maximisé de bande passante. Le rendu intègre un système de LOD dynamique, la tesselation est faite en temps réel, à la volé.

Les images de rendu sont capturées à la volée et stokées sur le serveur.

Phase II : Stream vidéo

Les images générée sont compressée pour être expédiée via une connection TCP au téléphone mobile 3G. Ce projet ayant pour but de démontrer les capacité des tout nouveau réseaux 3,5G (HSDPA) qui offre un débit de downlink de 1Mb/s !

Cependant l'application est scalable, et peut se contenter d'un simple réseau UMTS.

Phase III : Le client j2me

Le téléphone mobile possède un client J2me réalisant la décompresison du flux vidéo, et procède à l'affichage de la vidéo en background.

Le vaisseau spacial est affiché en temps réel au dessus du layer vidéo, ainsi que les ennemis et les cercles bonus qu'il doit traversser.

Le joueur peut se déplacer « librement » à l'interieur du couloir aérien, mais dans cette phase, il n'est pas entièrement libre : il ne peut pas, par exemple, faire demi-tour, ou emprunter une trajectoire quelconque. Sa liberté se limite au couloir aérien.

Phase IV : Liberté, liberté chérie

Il s'agit ici de libérer totalement le vaisseau du joueur. Il peut alors explorer comme il le souhaite l'intégrlité du département.

Les actions du joueur sont expédiées vers le serveur via le uplink TCP. Le moteur de physique interprète les déplacement côté serveur et positionne la caméra correctement pour générer les nouvelles images.

La grande difficulté ici est lza latence induite par le stream vidéo : en effet, pour que la vidéo soit suffisament fluide, un buffers de 4 à 5 secondes de vidéo est réalisé sur le client; de facto, cela imprime une latence de 5 secondes sur la perception des images par le joueur. Ce problème doit être compenssé localement chez le client en corrigeant la posture de la caméra par rapport au monde et au vaiseau...

En attendant d'adresser la phase IV, l'effort est essentiellement mis sur la partie serveur, et les perfomances de rendu.

A suivre avec des images dans quelques jours...