Réssite de chargement du joueur principale en se basant sur les informations reçus du serveur,

Nous avons extrait un nouveau Thread qui attend la reception des informations du joueur à partir du serveur 
pour qu'il cède la main au Thread OpenGL principale pour initialiser la caméra qui à son tour se charge de suivre par défaut le joueur.

Dans l'ancienne version la caméra est positionné à chaque Update du Thread OpenGL, pour qu'on obtient l'illusion qu'elle suit le joueur d'une façon continue.

Diffuculté de gestion des matériaux(couleur, texture) qui doivent être appliqués aux objets, on aura besoin d'une nouvelle méthode pour appliquer des matériaux aux objets sur scène.

Pour finir avec le joueur fans ce qui suit on se charge de trouver une méthode pour charger les animations des models 
et puis construir des méthodes pour les exécuter en fonction des interactions avec l'utilisateur et le serveur en même temps.
Nous avons établis une méthode "gestionThread()" relié au Thread principale du jeu
pour bien gérer l'epace mémoire alloué par les threads qui s'exécutent pendant le jeu,

en fait c'est par ce qu'on a remarqué que les thread ne s'arrettent jamais après avoir effectuer leur job
et nécessitent un arrêt manuel, donc on a vu qu'il sera utile au moins de vider leur contenu, en attendant de leur 
attribuer un nouveau contenu (une méthode à exécuter par expl)

Modification des classes reliés au Player pour animer le modèle mais avec la nouvelle méthode de JME3 (channel d'animation).


On signale une difficulté de chargement des modèles md5model et jmex ; JME3 ne supporte que les modèles Ogre3D
peu être on pourra trouver un outil pour les convertir en Ogre3D.

Reste à informer le serveur du déplacement du joueur, régler les bugs du thread OpenGL et ecrire la documentation à propos du Player.
Les positions du joueur sont coimmuniqués au serveur au fûr et à musure, nous serons prêt pour le multijoueur très prochainement. 

Actuellement nous sommes en cours de reglage d'un bug un peu compliqé ;

La façon de mouvement d'un caractère est radicalement différente entre JME2 et JME3,

*Avec JME2: Il est indispensable de mêttre à jour les positions du caractère au cour du temps après avoir la claculé tout en tenant compte de gérer le collisions avec les différents objets présents sur scène,

*Avec JME3: On spécifie un "CharacterControl" pour dériger le caractère du jeu en modifiant sa direction de marcher,
ainsi un RigidBody qui nous pemet de spécifier un poid pour le caractère ainsi un CollideBox pour l'empêcher 
de franchir les objets de la scène, le terrain à son tour est défini par un rigidBody dont le poid=0 (pour flotter à une position définit)

Nous rencontrons un problème qui consiste à déterminer le moment ou le joueur s'arrête 
afin de communiquer ceci au serveur, la méthode OnkeyRelease() du clavier n'est pas définit en JME3.

Nous trouverons une autre solution pour effectuer ceci
réglage du mouvement du Player,

En cours de modification de la classe Map pour supporter les heightMap de JME3.
Adoption de la solution qui consiste à utiliser la classe TerrainGrid de JME3 pour charger les 
heightMap contigues.

il reste quelques bugs !! le terrain est bien chargé, attaché au rootNode mais il n'apparait pas dans le jeu, ceci semble très bizarre! (en cours de traitement).

Le problème c'est que cette classe charge automatiquement les images composants de la heightMap 
tout en exigeant une extention commune pour toutes les images,
ce qui ne nous correspondra pas, puisqu'on a un mélange de heightMap (.png et .raw).

Peut être qu'on doit etablir un convertisseur dans le jeu pour convertir les .raw en png afin de les charger avec les .png.

Ceci semble comme une solution qui complique le jeu, il est meilleur de se baser sur des heightmap convenables(uniquement des .png)
pour produire une meilleure qualitée de la scène.