AlexandreWeiler < Stages

Tags: , view all tags

Stage d'Alexandre Weiler - IUT Charlemagne Nancy - [9/04/12 au 15/06/12]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage :

Stage d'Alexandre Weiler - IUT Charlemagne Nancy - [9/04/12 au 15/06/12]
Sauvegardes
Travail post stage éventuel

Sujet

Proposition de stage

Documents de travail

Stage (avril - juin 2012)

Avril

9, jour férié !
10, Installation et découverte des services du CDS et de l'observatoire, découverte de WebGL et premiers tests 3D avec la librairie Three.js (particules en mouvement)
11, création d'une sphère en 3D et tests sur l'iPad
12, recherche sur comment ajouter des textures et étude de l'algorithme Healpix avec Anaïs (comprendre le découpage des images)
13, création de la sphère suivant l'algorithme HealPix grâce au fichier JavaScript de Thomas. Pour chaque losange, une face en 3d est crée. A la fin de la journée, j'avais la sphère healpix en 3d.
16, !! problème de texturage de la sphère HealPix (qui n'est pas une "vraie sphere" mais un ensemble de faces indépendantes positionnées de telle sorte qu'elles forment une sphère). S'il avait s'agit d'une sphère géométrique, une seule image aurait suffit. Ici, chaque face a sa propre texture, il donc autant d'images que de losanges sur la sphère. Le problème vient de l'importation des images et une erreur se produit "Cross-origin image load denied by Cross-Origin Resource Sharing policy."
17, !! toujours le même problème. Demande d'aide sur le forum officiel de la librairie Three.js. On peut désormais voir la sphère de l'intérieur comme de l'extérieur. Le problème a été résolu en ajoutant au raccourci de Chrome l'option "--allow-file-access-from-files". Une autre erreur la remplace "Resource interpreted as Image but transferred with MIME type text/html.", Il semblerait que créer une texture directement avec l'url de l'image ne convienne pas.
18, Problème du texturage résolu. Le problème a été contourné en créant un objet Javascript Image(), en lui affectant l'url et en utilisant cet objet pour la texture.
19, Problème du rendu avec le canvas qui donne lieu à des bugs de disparation de certaines faces. De plus, il y a problème d'affichage des textures sur iPad (propre à Apple apparemment).
20, Plusieurs bugs résolus, notamment un problème de faces disparaissant en vue externe de la sphère (avec le rendu Canvas) + problème de la camera qui ne donnait plus d'image à partir de certaines coordonnées. En fait avec le rendu Canvas, un bug est lié à l'élimination des faces cachées c'est-à-dire hors du cône de vue (frustum view) . La solution résidait dans la désactivation de cette option (object.frustumCulled = false;). Se pose la question de la gestion du zoom et du chargement des autres images selon le niveau de granularité.
23, création des sphères de plus bas niveaux (4 et 5) avec le .jar de Thomas
24, Recherches sur comment détecter le losange exactement en face du point de vue de la camera. Il semblerait que l'on puisse faire cela avec un système de détecter de collision offert par la librairie.
25, Tests de collisions. Il faut en fait créer un "Ray" qui a pour origine la camera. Il possède une méthode qui retourne les objets qu'il rencontre sur son passage (les faces qu'il percute).
26, La face centrale est bien détectée (il faut bien prendre la première ie la plus proche car le rayon détecte aussi la face centrale mais de l'autre coté de la sphère). Sa texture est enlevée lorsqu'elle est au centre et elle lui est restituée lorsqu'une autre face prend sa place au centre de l'écran.
27, Chargement de la bonne texture du niveau inférieur et stockage des textures chargées (de niveau 4 pour l'instant) dans un tableau pour éviter de les recharger à chaque fois.
30, Réunion avec André et Thomas pour déterminer l'orientation à prendre : à quel public serait destinée cette application? Doit-on faire une app grand public, ludique, interactive sur iPad et esthétique ou un portage d'aladin pour une petite communauté de professionnels en mettant l'accent sur l'aspect fonctionnel? Il a été décidé que l'application serait destinée aux professionnels, donc en laissant tomber pour l'instant le support sur iPad. La priorité : faire tourner l'application sur pc. J'ai demandé à Thomas s'il pouvait me fournir le moyen de calculer les faces voisines de la face centrale pour déterminer une zone entière plutôt qu'un seul losange pour laquelle il faut charger les textures de plus bas niveau.

Mai

1, jour férié
2, Un détail d'ergonomie réglé, la sphère se déplace au clic de la souris et non plus en suivant directement son mouvement (mouseMove). Un problème se dévoile. Je ne savais pas encore qu'il allait être un point majeur du développement : les performances. En effet à l'heure actuelle, l'application consomme toutes les ressources du CPU et explose la mémoire en moins d'une minute. En effet 1) le canvas est rafraîchit 60 fois par seconde et la quantité astronomique (sans jeu de mots) d'images à charger sature le cache du navigateur avant de la faire planter purement et simplement.
3, J'essaie de comprendre d'où peut venir la fuite de mémoire. J'examine longuement le comportement du navigateur avec Google Map, Google Sky, Maps Nokia.. Je règle le problème du CPU en ne rafraîchissant la canvas que lorsque la souris bouge et que le dernier rafraîchissement s'est fait plus de 30 ms auparavant (ce qui laisse une fréquence de 30fps et donc un affichage assez fluide). Demande d'aide à un ancien professeur, professionnel des technologies du web.

Je réfléchis dans le train prends du recul et tente une approche différente du problème : ne faisant plus confiance au garbage collector, pourquoi ne pas allouer un nombre fini d'objets Image (quelques dizaines) et les réutiliser pour afficher d'autres images en en changeant la source/le path? Ainsi je ne manipule que quelques objets même si j'affiche une infinité d'images..

4, Il me donne une piste et me conseille de supprimer du DOM les images inutilisée. Pendant toute la journée je teste, j'examine le comportement du navigateur, je charge des centaines d'images, les supprime ensuite, je fais des recherche sur comment libérer la mémoire en javascript. Malheureusement il est basé un système de garbage collector, je cherche donc comment est gérée la portée des variables locales. Je découvre au bout d'un certain temps qu'il existe en JavaScript des fuites de mémoire liées à des références circulaire entre les objets JavaScript et ceux du DOM. Soucis, je ne lie pas mes objets au DOM, ce sont des variables locales mises à null une fois utilisées et donc en théorie libre d'accès au garbage collector. Il s'agit d'un problème des plus subtiles de la gestion de la mémoire par JavaScript. Je décide de suivre mon intuition de la veille et tente quelque chose de nouveau : créer un tableau de textures réutilisables à volonté, sans en créer de nouvelles à chaque chargement. L'algo est assez complexe et me prend beaucoup de temps.

5, Samedi je cherche dans cette direction, la gestion de la mémoire des images dans les application web pour iphone/ipad. Je tombe sur deux articles extrêmement intéressant. Il parlent du problème du chargement des images dans des applications qui manipulent des "infinte carrousels" ou des "infinite scroll" pour l'un et du chargement des textures dans un jeu en wegbl pour l'autre. Tous deux révèlent la même solution : allouer de la mémoire pour quelques images et changer le SRC pour en afficher d'autres. Mon intuition semblait se confirmer. J'ai effectué un test très rapide sur mon travail de la veille. Je réutilise les textures inutilisées pour afficher de nouvelles images mais les indexes ne correspondent pas bien et il y a un problème d'ordre (algo vraiment complexe -.-'). Mais en regardant le graphe de la mémoire, elle ne semble pas "s'envoler" comme j'avais déjà pu le constater. Est-ce ma machine, le fait que je charge peut-être toujours les mêmes textures ou est-ce un début de solution à mon problème? Un début de solution serait le bienvenu car ce soucis de mémoire commence à devenir vraiment pesant et je ne trouve personne capable de m'aiguiller vers la sortie de cette impasse. Pourtant Google et Nokia l'ont fait, c'est donc possible! Reste à découvrir comment...
6, Dimanche Je cherche d'où peut provenir ce problème d'ordre dans les index. Je reprends une nouvelle fois mon algo depuis le début.
7, Solution trouvée pour le problème des textures ne se mettant pas à jour. Il faut spécifier à chaque m.à.j "materialNeedsUpadte = true;". Il y a encore un bug dans les faces que je récupère en calculant les voisins. Certaines ne semblent pas être reconnues dans l'ensemble des faces. Après plusieurs heures de debug je découvre qu'en fait il y à des indices à "-1" dans le fichier des voisins que Thomas m'a donné.
8, Férié
9, Je règle quelques soucis d'ergonomie notamment ne supprimer les textures n que lorsque les texture n+1 ont fini de charger (évite d'avoir des trous dans le sphère). Je cherche également comment ajouter un effet de halo autour de la sphère pour simuler une "atmosphère", en vain...
10, Je me renseigne auprès d'André et d'Anaïs pour savoir comment est géré le zoom dans Aladin, s'il dépend d'une échelle arbitraire où s'il est calculé. Je réfléchis sur tous les moyens possibles (avec plusieurs Ray pour calculer le nombre de faces visibles, à l'écran, calculer la taille des face et la comparer à la taille réelle de l'image...). Thomas m'accorde que la solution la plus simple est d'établir une échelle "à vue d'oeil". Un gros problème se profile (à nouveau), comment généraliser le passage du niveau N au niveau N+1? Que doit-on afficher à l'écran, quelles faces de quel niveau?
11, Réunion avec Thomas pour lui montrer l'avancement du projet. Je discute du problème de la veille avec Thomas. La solution la plus simple pour gérer les différents niveau de résolution serait de calculer au début toutes les sphères et de n'afficher qu'une partie de la sphère correspondant au niveau de zoom actuel. Le soucis, c'est que c'est impossible. Rien que pour charger et calculer la sphère 5, il faut 10sec de plus. Je n'ose pas imaginer ce que cela donnerait au niveau 10... Alors comment déterminer les faces à afficher, comment savoir lesquelles doivent être de tel ou tel niveau? Je m'embrouille assez vite avec ces questions, j'essaie d'éclaircir tout cela en faisant une liste des possibilités des avantages et des inconvénients. Et sans la librairie HealPix en javascript, les calculs sont limités au point que l'on va très sûrement devoir dépendre d'un service web calculant les infos depuis la libraire en Java pour me le renvoyer en Javascipt. Cette solution ne me plaît pas beaucoup mais nous n'avons visiblement pas le choix...
12, Samedi Après mûre réflexion, je décide d'une nouvelle stratégie. Au niveau le plus haut (disons 2), on aperçoit toute la sphère avec les textures compressées pour une manipulation fluide. Lorsque la sphère est proche je remplace ces texture par d'autres moins compressées, la navigation reste fluide et l'état de la mémoire reste raisonnable. Une fois que l'on ne voit plus les contours de la sphère, on n'affiche que 25 tuiles de niveau 3 compressé et les 9 centrales en niveau 3 originale. Et ainsi de suite pour les niveaux supérieurs. Je choisis de ne gérer que 25 tuiles de niveau N plus 36 de niveau N+1. Ainsi je ne suis pas dépendant des niveaux inférieurs et de la sphère de niveau 3. Lorsqu'on se déplace, je crée dynamiquement les nouvelles tuiles en écrasant les anciennes (plus visibles). J'espère que manipuler 61 faces maximum à la fois répondra à mes exigences car je ne vois pas d'autre solution pour gérer à la fois l'affichage fluide tout en ménageant la mémoire.
13, Dimanche j'écris à l'avance un "FaceManger" capable de mettre à jour les 25 tuiles N et les 36 tuiles N+1.
14, lundi tests et débug de mon facemanager
15,
16, incorporation des .positions et .neighbours
17, requêtes ajax
18,
21, lundi
22,
23,
24,
25, vendredi J'ai enfin une lentille à 2 niveaux testée avec MellingerRGB. Le soucis c'est que je ne vois aucune différence entre le niveau 3 et 4. Je me demande donc s'il est vraiment utile d'afficher 2 niveaux sur une même lentille.
28, lundi réécriture complète du code (affichage de la sphère)
29, mardi réécriture complète du code (adaptation à tous les relevés)
30, mercredi l'appli peux afficher n'importe quel relevé (bien qu'il reste quelques bugs)
31, jeudi today