Stage de Jérôme Desroziers - IUT Charlemagne Nancy - [4/04/16 au 10/06/16]

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 : contacter André

Sujet

• Proposition de stage

Documents de travail

• ...

Stage (avril - juin 2016)

Avril

• 4: Accueil et visite des différents bâtiments, Journée de présentation des métiers (Astronome, Documentaliste) et services du CDS
  Présentation des logiciels Simbad, VizieR et Aladin
• 5: Réunion de briefing, lecture des rapports et de la documentation laissée par Pierre Lespingal et Arnaud Steinmet
  Installation de WebStorm, lecture de la doc de l'application (+ test de l'application elle même) et étude du code source
  Classes étudiées: View, Scene, DataUIManager (+Script mais points à éclaircir)
  Pour l'instant uniquement étudié aspect mise en forme de l'application i.e. structure simu->view->scene->data + gui + three.js (caméra, rotation, rendering, raycasting... , etc...)
  Le chargement des données n'a pas encore été abordé.
• 6: Etude du code source, faire fonctionner la version actuelle (serveur Web, données, etc.)
  Continué d'étudier le code source: classes étudiées: Menu, TimeLine, Data, Simu, perspectiveCamera
  Puis ai abordé chargement des données ainsi que l'affichage de ces dernières.
  Chargement: via classes data, snapshot, octreeWorker, octree -> notion de webWorker + gestion asynchrone + octree
  Affichage: via classes renderableData, shader, util -> usage avec three.js de ShaderMaterial (http://threejs.org/docs/#Reference/Materials/ShaderMaterial), de PointCloud; raycasting
  + installé firebug, liste de correctifs à ajouter à l'app
• 7: -> utilité des scripts : chargement de fichiers de = formats
  -> fonctionnement des onglets datas/snapshot: superposition de nuages de points, option affichage data, etc...
  Mise en place d'une liste de correctifs/ajouts à effectuer ainsi que d'un planning pour les évolutions futures de l'application:
  Correctifs effectués aujourd'hui:
  *possibilité de déplacer la caméra en utilisant les points fixes des vues des touches 4,5,6,8
  *possibilité de se déplacer à la verticale
  *le redimentionnement de la page ne dérègle plus les rapports de distance entre le curseur et les points d'arrêt sur la timeline
  *lorsque le curseur s'arrête sur le dernier point d'arrêt, il est désormais impossible de le déplacer en dehors de la timeline en "trichant" sur la variable temps
  Reste: ->bug d'affichage en vue multiple lorsqu'étirement maximum fenètre (white screen 2nd fenètre)
  ->pour plus tard: bugs observés lors de la transition d'un état A à un état B (approffondir cf shaders) + bug chargement fichier (?) (cf capture d'écran)
  Feuille de route suite:
  a) terminer correctifs
  b) maj interface data/snaps
  c) import données VisieR (pour b et c, voir feuille de route)
  d) OPTIMISATION (très important)
• 8: Debriefing du travail de la semaine et préparation du travail de la semaine suivante
  Correction de bugs au niveau de l'interface multivue:
  -> correction du changement de vue: redimentionnement se déclenche lorsque appellée
  -> correction du bug de white screen qui dans le mode vue multiples faisait disparaître la seconde vue lorsqu'on
  redimentionnait la page d'une largeur supérieure à celle qu'avait la page au moment de sa création.
  Assisté à la conférence "Tori, disks, and winds — the AGN dust emission at high angular resolution"
  (tenue par Sebastian Hoenig)
• 11: Terminé de mettre à jour l'interface:
  ->La fenètre active est en surbrillance (le cadre des options d'affichage est bordé de rouge)
  Cela sert notamment en multivues, pour que l'utilisateur puisse savoir sur laquelle des 2 vues il est verouillé.
  ->Lorsqu'on passe de la multiview à une vue simple (ou occulus, etc...), c'est fenètre précedemment active dans la double vue qui est affichée.
  (et non plus la vue 0 par défaut)
  ->Lorsqu'un couple data/snapshot est contient des données, il est représenté par une petite galaxie (qui remplace alors l'icône de chargement)
  ->Sur le menu des données chargées, les couples data/snapshot non vides (i.e. image galaxie) des colonnes data actives sont en surbrillance.
  ->En multivue, lorsqu'on passe d'une vue à une autre, les éléments chargés actifs sur cette vue se mettent dynamiqument en surbrillance.
  ->L'utilisateur a maintenant la possibilité de vider la case mémoire courante (cf sélectionnée avec les onglets data/snapshot) via la touche suppr
  Terminé de corriger les bugs liés à l'interface:
  ->Lorsqu'on charge un jeu de données: ce dernier s'affiche directement à l'écran à la fin du chargement.
  (il n'y a plus besoin de passer par le menu et de décocher/recocher la case "Activate data" pour rafraîchir l'affichage des données)
  ->Réussi à corriger le bug qui faisait que chaque jeu de donnée vide de l'application affichait de façon rémanente le dernier jeu
  de données chargées parcouru par l'utilisateur --> maintenant la sélection de données vides n'affiche rien (cohérent avec l'état des données en haut à gauche)
  ->En multivue: le bouton "Activate data" ne modifie l'affichage de l'état des données en haut à gauche que si il appartient à la vue courante.
  (dans le cas contraire il modifie bel et bien les paramètres de la vue, mais cela ne se reflète pas sur l'état des données de la vue courante)
• 12: Discussion avec Thomas Boch sur le fonctionnement de TAP VizieR (notamment au niveau des envois de requètes)
  ->Mise en place de l'interface permettant d'exécuter des ADQL query
  (désactivation de tout les listeners sur le clavier lorsque l'utilisateur clique sur le champ de saisie, ces derniers sont reset lorsque l'utilisateur valide la requète/quitte l'interface)
  Fonctionnement des XMLHttpRequest, pour VizieR le requestHeader doit être de la forme ("Content-Type", "application/x-www-form-urlencoded") (!!!)
  Lorsque l'utilisateur appuie sur entrée, la requète couramment saisie est envoyée à VizieR via un XMLHttpRequest de type POST (cf CORS)
• 13: Finalisé première (?) version du système de chargement de données depuis TAP VizieR
  a)Envoie une requète POST au serveur, contenant la requète saisie par l'utilisateur. -> si requète incorrecte, retourne erreur
  b)Le serveur retourne une url qui permet à l'application de vérifier périodiquement l'état de la requète sur le serveur.
  (une vérification de l'état est effectuée toutes les deux secondes)
  ->informations retournées par le serveur sous forme d'arbre xml, récupérées grâce à fonction dédiée
  c)Lorsque le serveur a fini de traiter la requète, il envoie l'url de téléchargement à l'application
  d)Traitement des données reçues grâce au parseur ->EN COURS
  +Gestion des erreurs: erreur 404 (si l'url donnée par le serveur devient invalide), annulation du chargement si l'utilisateur a changé de vue durant le chargement du fichier.
  +Lorsqu'un fichier est chargé depuis TAP VizieR, le couple (requète, urlTéléchargement) est stocké dans un objet littéral
  (si l'utilisateur effectue 2 fois la même requète, la seconde utilisera directement l'url résultat de la première)
  ->Etude du parseur VOtable; prévu:
  *inclure possibilité de charger fichiers VOtable en local (offre = possibilités à utilisateur, ET plus pratique pour tests)
  *dans votable.js:
  -créer un second constructeur qui prend en paramètre non pas un path mais un buffertxt (car l'analyse du fichier se fera dans script.js, où le contenu du fichier sera transmis sous la forme d'un buffer txt)
  dans app:
  -(pour load depuis VizieR), dans Simu.js: après chargement fichier, appeller fonction load_spe de data.js
  -(pour load depuis VizieR), dans data.js: fonction load_spe: ne prend pas de path mais un buffertxt en parametre et lance directement le script créé
  -script.js: utilise votable.js pour extraire le data du .txt;le transforme dans le format de l'app et le retourne à data.j
• 14: Etude du parseur pour comprendre comment l'implémenter dans l'application
  Réussi à mettre en place la visualisation de données depuis VizieR
  -> Créé un script de lecture de fichiers VOtable: on a donc la possibilité de charger des données VO en local où depuis VizieR (le chargement local est pratique pour effectuer les tests)
  Ce script utilise le parseur votable.js -> important: comme le parseur est fait pour lire des fichiers mais que les données reçues lors du chargement depuis le serveur sont sous la forme d'un objet xml, il a fallu rajouter un constructeur au parseur qui permet de les lire.
  Pour le script en lui-même pour l'instant seule la position est prise en compte
  ->indication pour les couleurs: utiliser différence de rmag et gmag pour situer couleur objet (formule: -2,5log(Fg/Fr))
  Lorsque l'utilisateur charge des données depuis VizieR et change de couple data/snapshot durant le chargement: à la fin du chargement refocus sur le couple d'origine du chargement.
  Le chargement de données depuis VizieR se fait toujours avec le script VOtable, même si ce n'est pas le script courant.
  Objectifs dans l'immédiat:
  - Afficher couleurs réelles
  - Centrer données dans cube
  - Charger gros fichiers xml depuis VizieR (et en local...) -> piste: utilisation des blobs
  NOTES: - visiblement chargement VizieR en local fonctionne avec méthode de split des fichiers (i.e. similaire données simulation) -> à vérifier mais normalement c'est tout bon
  - pour centrer dans le cube: à vérifier mais normalement /2 xyz puis translater de origine vers centre cube dans script pour chaque data devrait marcher
  - pour chargement big data depuis VizieR: poser questions cf chargement querys asynchrones top 100000
  - vérifier au moins pos infos demmandées dans requète (+faire script accepter = jeux données)
• 15: - A)Petites implémentations, corrections de bugs
  -> fait en sorte que le script de lecture VOtable soit utilisé par défaut lors du chargement de donnée depuis VizieR même lorsque ce n'est pas le script courant dans l'application
  -> résolu problème barre d'espace/entrée après avoir chargé un fichier (conflit entre listeners); maintenant touches a et e pour monter/descendre caméra
  -> l'utilisateur peut désormais naviguer sur différents couples data/snapshot pendant qu'un (plusieurs) jeu(x) de donnés sont chargés depuis VizieR (à la fin du chargement, l'utilisateur est directement positionné sur le couple qui contient les nouvelles données)
  -> après suppression d'un couple data/snap: mise à jour automatique de l'affichage
  -> créé bouton pour activer/désactiver l'affichage du repère
  - B) Requètes VizieR
  -> on vérifie avant envoi que les informations obligatoires sont bien présentes (pour le moment: zsp...etc i.e. position)
  (vérifie champs présents sous forme 'zsp' OU "NOM".zsp)
  - C) Centrer données au centre du cube
  -> i) calculer point central des données
  -> ii) calculer dimensions du rectangle englobant les données, déterminer valeur max (longeur ? largeur ? hauteur)
  -> iii) on translate tout les points du centre des données à l'origine du repère
  -> iv) on divise les coordonnées par la valeur max (pour avoir les points à l'échelle 1/1/1)
  -> v) on translate par rapport au centre du cube de visualisation
  - D) Affichage des données assosciées à un point
  -> problème: à l'origine données à afficher sont fixes selon le script (i.e. pas compatible avec querys Votable qui peuvent prendre = jeux d'information)
  -> refonte de la structure de donnée générée par les scripts: un champ pos et couleur, et un champ info qui concentre tout les champs autres et/ou générés par une requète Votable comme ça affichage polymorphe
  Assisté à la conférence "Dark matter detection and cosmological simulations"
  (tenue par Emmanuel Nezri)
• 18: - Réunion avec Mr. Schaaf, compte rendu du travail effectué la semaine dernière; mise au point
  (demmandé fonctionnement des querrys "top" pour tenter un mapping lors du chargement des requètes >500000 lignes ainsi que des jeux de données atypiques)
  => jeux de données atypiques: mise à jour de la vérification des requètes (accepte aussi bien z seul que zsp)
  néanmoins la requète fournie ne renvoie aucun résultat -> poser question
  => visiblement impossible de réaliser un mapping sûr à 100% en morcelant les requètes VizieR
  -> visiblement il semble que les blobs soient la voie à prendre
  - Corrections de nombreux bugs:
  -> le problème de masquage du repère orthonormé lorsqu'on a un jeu de donné vide est résolu
  -> un clic dans le vide retire désormais les informations du point précédemment sélectionné
  -> bug de la timeline lorsqu'on sélectionne le dernier snapshot en haut à gauche alors qu'une animation est en cours: résolu
  -> lorsqu'on réccupère des jeux de données grâce à VizieR mais que ces derniers sont vides (i.e. aucune étoile ne correspond aux critères donnés, etc...) alors on force la génération un champ info "vide" dans le script pour ne pas lever d'erreur lors du traitement des données
  -> lorsqu'on supprime les données contenues dans un couple data/snapshot: réinitialisation du tableau info du snapshot assoscié (auparavant causait une erreur si on voulait réutiliser l'espace qu'on venait de libérer OU affichait les données assosciées aux points du snapshot en double)
  - Réussi à corriger bug majeur lié au fait que désormais le nombre de données peut changer d'un snapshot à l'autre:
  (causait une disparition des points à l'affichage des snapshots dont l'id était > au nombre de points des données les plus récemment chargées)
  =>Visiblement la taille des buffers des objets data était mise à jour à chaque insertion de donnée sans vérification de la taille des buffers actuellement dans la colonne (i.e. si mon snapshot no2 a 50000 points mais que je fais une insertion en 3eme position contenant 10000 points, les buffers seront set à une taille de 10000)
• 19: -Mise en place de la coloration
  -> Les calculs de couleur sont réalisés à partir des champs umag et gmag pour avoir un dégradé allant du bleu au rouge selon la chaleur de l'étoile
  (cf https://en.wikipedia.org/wiki/Color–color_diagram)
  - Refonte du système de vérification des requètes
  (dû à la grande variété de noms possible pour des attributs sémantiquement identiques dans les requètes)
  -> Désormais le champ de saisie VizieR comporte différent champs: un champ pour la requète, et plusieurs champs pour les attributs clefs (i.e. susceptibles d'influencer le rendu); lorsqu'un utilisateur entre une requète dans l'application, il doit entrer dans les champs des attributs clefs le nom correspondant dans le catalogue consulté (par exemple, si dans le catalogue zsp s'écrit z, alors l'utilisateur doit le préciser en entrant z dans le champ de saisie labellé zsp)
  -> Dans un premier temps on vérifie que les champs correspondants aux attributs RAJ2000 et DEJ2000 sont présents
  (c'est le minimum requis pour réaliser un affichage des points), les autres champs zsp, umag et gmag sont facultatifs
  -> Dans un second temps on envoie au script VOtable les couples clefs/valeurs correspondant aux attributs, et on lance la requète. De cette façon l'utilisateur peut réaliser des requètes sur virtuellement toutes les tables de VizieR
  - Visualisation des données en "sphère"
  Le champ zsp n'étant plus obligatoire, on peut visualiser les données sur une sphère de diamètre 1
  Attention (il faudra le préciser quelque part) lorsqu'on lit en local un fichier au format Votable il faut aussi paramétrer les variables du script Votable; si par exemple ce dernier contient zsp mais que ce dernier a un nom atypique (ex: z), alors avant de lire les données on doit set l'attribut zsp du script Votable sur z (comme dans le cas d'une requète sur VizieR) sinon zsp ne sera pas pris en compte lors de la lecture et on aura un affichage sphérique.
  - Compris source des warnings Error: WebGL: drawArrays: bound vertex... dans le cas PRECIS où l'on charge un fichier sur un emplacement déjà pris => dans ce cas c'est juste l'affichage qui continue de tourner pendant que l'octreeWorker modifie les buffers en asynchrone (donc ne met pas en cause le fonctionnement de l'application)
• 20: -Corrections bugs:
  -> bug qui n'affichait pas les données du couple data/snapshot 0/0 lorsqu'une seule ligne de snapshots était présente
  -> contraitement à ce qui a été dit le 19, la source des warnings Error pouvait causer des problèmes lors du chargement des données; la solution trouvée a été de réinitialiser l'objet currentOctree de l'objet data à chaque chargement (avant d'envoyer le message au worker)
  -Mise en place de la mise en valeur des données selon un attribut précis
  Il se trouve que la précédente version de l'application présentait déjà une telle fonctionnalité, qui permet d'appliquer un filtre de couleurs sur les éléments affichés selon la valeur d'un de leurs attributs
  -> update de la fonctionalité pour être en accord avec les nouvelles données, plus ajout de l'attribut température (la valeur selon laquelle on modifiait automatiquement la couleur du rendu) qui est désormais dans la partie info des données liées au point
  -> mise en place de la désactivation des listeners dans les menus déroulants (auparavant il fallait fermer le menu pour retirer le focus sur les champs de sélection des attributs)
  -Amorcé l'homogénéisation de la mise en valeur des données "info"
  Plusieurs problèmes:
  i) le calcul pour déterminer les bornes de couleurs pour l'affichage de l'attribut ciblé en surbrillance se fait en local pour chaque jeu de données. Ainsi si on superpose 2 jeux de données et qu'on veut mettre en valeur la température, les étoiles bleues de chaque jeu seront les plus chaudes, mais selon l'échelle propre à chaque jeu, et non pas via une échelle commune à ces deux jeux.
  ii) il n'est possible de mettre en valeur qu'un seul attribut à la fois (logique) or ces attributs sont nommés selon le nom qui leur a été donné dans la requète VizieR. Le problème est que 2 noms différents d'attributs (dans 2 catalogues par ex.) peuvent correspondre au même attribut dans l'absolu. Or, si les noms sont différents (car cf Gilles impossible d'avoir accès à toutes les corrélations de noms d'attributs sur VizieR), comment faire pour effectuer la mise à l'échelle du i) ?
  Solution trouvée: mettre dans le menu de gestion des données un champ "merge" que l'utilisateur peut utiliser pour notifier à l'application que les x champs déclarés dans le champ ont la même valeur sémantique...
  Pour le moment, fini de mettre en place l'interface ainsi que la gestion des listeners, etc...
  Reste à:
  -Créer la structure de donnée globale qui permet de centraliser les bornes de chaque attribut pour l'ensemble des données chargées
  - Ces bornes doivent êtres mises à jour dynamiquement lorsqu'un snapshot voit ses données supprimées/remplacées ainsi que lorsque l'utilisateur choisit de masquer les points dans une colonne data.
  -Il faut que chaque vue possède une telle structure (cf en double vue on peut activer/désactiver = jeux de donnés selon la vue)
  -il faut que l'affichage se mette automatiquement à jour en conséquence au changement des bornes
  -Mettre en place la fonctionnalité de merge, et la mise à jour des données qui en résulte
• 21: Mise en place de l'homogénéisation des infos
  - Mise en place de la structure de données:
  ---Pour chaque Vue, on calcules les bornes min et max globales à partir des bornes de chaque data ACTIVE
  ---Pour caque renderableData ACTIVE, on calcule les bornes min et max de chaque info...
  ---Pour chaque snapshot
  ---Pour chaque info contenue dans le snapshot (bornes min et max du snapshot calculées lors du chargement VizieR)
  Ce résultat est stocké dans la vue sous la forme d'un tableau contenant des objets littéraux {nomInfo, min, max}
  La fonction d'homogénéisation doit être appellée
  -lorsqu'une colonne data est activée/désactivée
  -lorsqu'un couple data/snap est chargé/supprimé
  ->correction de bug: pas de mise à jour des infos correspondant au couple data/snap courant lorsqu'on crée une colonne/une ligne
  ->corrections bugs dans interface (décrémentation de l'info sélectionnée après changement de colonne)
  Problème: il faut mettre à jour l'affichage des colonnes adjacentes lorsqu'on effectue des changements sur la colonne courante..
• 22: --- Fin de la mise en place de l'homogénéisation des infos:
  i) Modification de la structure de données
  -> la fonction d'update des bornes de la vue est appellée lorsqu'on change de snapshot dans la même colonne data, ainsi que lorsqu'on ajoute une nouvelle ligne / colonne d'emplacement de données
  -> modification de la fonction d'update, les bornes sont maintenant stockées dans chaque vue et non plus dans la classe Simu uniquement
  (i.e. en multivue chaque vue a donc ses propres bornes min/max en fonction des données qu'elle affiche)
  ii) Mise à jour dynamique de l'affichage, i.e.:
  -> lorsqu'on insère des données
  -> lorsqu'on supprime des données
  -> lorsqu'on masque/active des données
  (auparavant seuls les éléments de la colonne data courante étaient affectés par les changements de bornes; il fallait forcer la mise à jour de l'affichage des autres colonnes en passant par leurs menus)
  iii) Correction de bugs
  -> correction problème mineur de listener dans le menu data
  -> il y avait une erreur dans le code d'origine: lorsqu'on sélectionnait une info à mettre en surbrillance dans un snapshot, que l'on en changeait puis y revenait: l'info sélectionnée (ainsi que l'affichage correspondant) s'était décalée d'un cran dans la liste
  -> lorsqu'on sélectionnait none dans le champ 'info to highlight', cela n'avait aucune incidence sur l'affichage des données (maintenant le champ none n'existe plus)
  --- Mise en place de la fonctionnalité de merge:
  i) Mise en place de l'interface:
  -> elle se trouve dans le menu data propre à chaque vue, les données à entrer doivent être de la forme: nom_actuel // nom_nouveau
  -> lorsqu'on se trouve en double vue: on peut réccupérer les informations contenues dans le champ quelque soit la vue d'origine
  -> gestion des erreurs: vérification de la syntaxe de la requète de merge, impossibilité d'entrer deux fois le même nom d'attribut, cas où le nom à remplacer n'existe pas, cas où l'on tente de changer le nom d'un attribut par le nom d'un autre attribut déjà présent dans le snapshot courant
  ii) Lien avec la fonction d'homogénéisation
  -> fonction appellée lorsqu'un merge est effectué avec succès
  --- Autres ajouts:
  i) Correction de bugs:
  -> lorsque le jeu de données était trop petit (par ex. lorsqu'on chargeait un jeu de 100 points), il était impossible de sélectionner un point pour accéder à ses attributs (cause: les fonctions de collision étaient prévues pour ne se déclencher que si l'octree principal possédait des fils, or dans le constructeur les fils ne sont créés qu'au delà de 1000 points)
  -> erreur de chargement lorsque les données passées en paramètre sont vides (cf star_start), problème corrigé
  -> correction du bug webgl qui causait des problèmes d'affichage lorsqu'on chargeait des données sur un emplacement non-vide
  Visiblement la cause vient du fait que les chargements de données sont asynchrones et le bug provenait durant l'affichage des données en train d'être écrasées.
  Solution trouvée: interdire le chargement de données sur des emplacements non-vides (la fonctionnalité de suppression a maintenant une vraie utilité)
  ii) Modification du menu de chargement des données
  -> désormais chaque type de donnée possède son propre code couleur: rouge pour les simulations, bleu pour les données VOtable sous forme sphérique, et vert pour les données VOtable 3d.
  iii) Création du dépôt git
  Assisté à la conférence "La détection du rayonnement gravitationnel"
  (tenue par L. Blanchet)
• 25: --- Mise en place de l'homogénéisation des données dans l'espace 3d
  i) Mise en place de la structure de données assosciées
  (Comme seules les données Votables 3d sont représentées dans des bornes de dimentions variables, ce sont les seules à être prises en compte par la fonction d'homogénéisation)
  -> Classe Script: l'objet data renvoyé contient un nouveau champ "bornes" qui contient les bornes min et max des coordonnées x,y, et z de l'objet
  -> Snapshot: lors du chargement de données VOtables 3d dans un couple data/snapshot les bornes calculées sont transmises au snapshot
  -> Data: lorsque des données sont chargées: APRES génération de l'objet data par le script mais AVANT remplissage des buffers: mises à jour des bornes de l'objet data regrouppant les snapshots VOtable ainsi que le snapshot en train de charger le fichier (qui n'est pas encore considéré comme contenant des données)
  -> Vue: lorsque des données sont masquées/affichées: mise à jour des bornes de la vue regrouppant l'ensemble des bornes des datas VISIBLES
  -> Simu: lorsque des données sont chargées/supprimées: mise à jour des bornes de CHAQUE vue
  ii) Mise en place de l'affichage
  --> Problème: chaque data est commune à chaque vue: si on modifie en brut la position des points pour une data dans une vue, cette dernière sera aussi modifiée dans l'autre vue (alors que les données affichées dans d'autres colonnes data de cette vue sont différentes de la première ==> PROBLEME)
• 26: --- Mise en place de l'affichage des données homogénéisées dans l'espace:
  -> Idée trouvée: ne pas modifier les coordonnées des points, mais modifier leur affichage (i.e. comme chaque Vue possède ses propres renderableDatas, même si les datas sont communes à toutes les vues, les renderableDatas ne le sont pas)
  -> L'algorythme de recentrage des données dans le cube n'est désormais plus utilisé par le VOtable_Script (car le redimentionnement doit se faire selon les bornes globales de la vue) -> il est néanmoins toujours utilisé dans le cas où la coordonnée zsp est inconnue, car l'affichage sphérique n'a pas besoin d'être homogénéisé.
  -> Dans la fonction resetData de RenderableData, lorsqu'on initialise le buffer de position du pointCloud, dans le cas où le snapshot courant de l'objet data est du type "VOtable_3d", au lieu de directement lui passer en paramètre l'attribut position du snapshot, on en effectue une copie à laquelle on applique l'algorythme de repositionnement (étendu aux bornes de la vue) et on passe cette copie en paramètre à la place.
  -> Le redimentionnement doit s'effectuer:
  *après une suppression/insertion de données
  *après un activation/désactivation d'affichage de data
  Solution: lorsqu'un changement des bornes est effectué dans une vue, la fonction dataHasChanged de sa scène est appellée
  --- Corrections des problèmes générés par le nouveau mode d'affichage
  -> Désormais l'affichage des points de type VOtable_3d ne dépend plus (seulement) de l'objet data et que la position des points affichés diffère de la position des points dans l'octree de data, les calculs de frustrumCulling ainsi que de raycasting sur des données VOtable3d ne fonctionnent plus..
  -> Solution trouvée: dans le cas où une renderableData contient des données 3d, elle stocke en local son propre octree issu des positions modifiées lors de l'homogénéisation des données
  -> C'est cet octree qui est désormais utilisé lorsque l'on veut réaliser des calculs de collision/de rendu
  -> a chaque fois qu'on fait une suppression ou qu'on change de snapshot: il faut recalculer l'octree "secondaire"
• 27: --- Terminé la mise en place de l'homogénéisation dans l'espace pour les données VOtable3d
  -> bug de frustrumCulling: visiblement il y a un problème lorsque les octrees créés à partir du buffer de position ont une taille > 1000 faute de solution (plus optimisée), ai dû mettre en place un constructeur d'octree qui ne posède aucun fils dans le cas des données VOtable3d
  -> ce problème impactait aussi la détection des points via la souris; la détection fonctionne sans problèmes désormais
  -> corrigé l'origine des erreurs webGl qui causaient une disparition des points à l'affichage lors de chargement / suppression de fichiers et lors de changement de snapshot, etc... Visiblement l'application telle qu'elle était à l'origine avait dans chacun de ses objets "data" des buffers qui contenaient = paramètres liés à l'affichage des points. Or il se trouve que CERTAINS de ces buffers n'étaient mis à jour que lors du chargement du fichier, par exemple en pos 0/0 je charge un fichier de 10000 points, puis en pos 1/0 un fichier de 10 points, lors du 2eme ajout les buffers sont mis à jour et ont une taille respective de 30 et de 10 (pour la position et l'info courante), mais lorsqu'on va revenir sur le snapshot précédent (pos 0/0), seule une mise à jour partielle des buffers n'aura été effectuée et l'application va transmettre à Three.js X buffers supposés ayant une taille de 30000 et 10000 (pour les champs info et pos) mais certains auront des tailles tronquées: d'où l'apparition d'erreurs webGl.
  Corrections: mise à jour lors de l'update du snapshot courant du buffer INDEX, qui est chargé depuis le snapshot courant, ainsi que du buffer INFO; comme il fallait garder une trace du type d'info courante d'un snapshot à l'autre un nouvel attribut a été créé dans ces derniers.
  --- Correction bug mineur:
  -> lorsqu'on appuie sur la touche echap au démarrage de l'application: rien ne se passe (plus de white screen dû à l'absence de vue)
  -> Rendez-vous avec Mr. Schaaff pour déterminer les ajouts prioritaire
• 28: --- Mise en place de l'homogénéisation simple des données étendue à tout les scripts non-VOtable
  Auparavant l'algorithme d'homogénéisation "simple" (i.e. avec calcul de redimentionnement lors du chargement initial des données uniquement) était cantonné aux données VOtable_2d. Désormais les données de simulation en bénéficient également.
  L'algorithme a donc été déplacé dans la classe data (pas de duplication dans les scripts) et a été légèrement modifié afin de calculer les bornes de données chargées à partir de différents fichiers.
  --- Mise en place d'une fonction d'affichage d'un rectangle en fil de fer englobant chaque jeu de données
  -> Mise en place de l'interface (un simple bouton dans l'onglet data de chaque vue )
  -> Mise en place de la structure de données: les données relatives aux dimentions / positionnement du cube sont calculées lors de l'appel à l'algorithme d'homogénéisation dans l'espace; elles sont ensuite stockées dans le snapshot assoscié.
  -> Affichage de cuboids en fil de fer grâce à la librairie Three.js: la structure du cuboid est générée via l'objet BoxGeometry et l'affichage en fil de fer est obtenue en enrobant cet objet dans un EdgesHelper (les 2 objets doivent néanmoins être ajoutés à la scene)
  -> Par défaut l'option est active et l'affichage de la box se fait automatiquement
  -> Le rendu de la box est modifié: a la suppression/insertion (-> si coché) / au masquage/démasquagee des données (-> si coché) ET lorsqu'on active/désactive le rendu de la box
  -> Les bornes des box sont contenues dans chaque snapshot i.e. en multivue les bornes sont "communes" à chaque vue MAIS comme on stocke la référence de l'objet box propre à chaque snapshot dans les renderableDatas de chaque vue, la modification des données relatives à la box dans le snapshot n'impactent que la vue courante (aucun conflit à ce niveau)
  -> Concernant les données VOtable_3d et leur homogénéisation dynamique: un appel à la fonction gérant l'affichage de la box est appéllé à la fin de l'homogénéisation des données
  -> BUG: visiblement les bornes des box sont étranges sur certains jeux de données (la valeur max des largeurs du cuboid n'atteint jamais 1 par ex. sur les jeux de données 10 et 955 du sdss7)
• 29: --- Correction du bug de redimentionnement des box
  Il s'avère que le bug ne provenait pas des algorithmes d'homogénéisation mais d'une erreur assez importante (au niveau de l'affichage) qui était déjà présente dans l'application depuis la V0: l'algorythme de redéfinition de l'index des = points assosciés à un snapshot donné permettant de gérer le niveau de détail ne prenait en compte que le cas strict où le nombre de points était égal à un multiple de 4. (cf les 4 niveaux de détail proposés)
  I.e. lorsqu'on chargeait un jeu de données ne respectant pas cette condition, les 3/4 des points chargés se retrouvaient dotés d'un index à virgule dont la valeur ne correspondait plus a l'indice du buffer de position/3
  (3/4 des points se retrouvaient ainsi aux coordonnées (0,0,0) et on avait un affichage de détail lv1 tout en utilisant les ressources pour un lv4)
  Solution: la taille des 4 sous sections de l'index correspondant à chaque niveau de détail sont égales à l'arrondi supérieur de tailleIndex/4; lorsqu'on tente d'insérer une valeur dans une case de l'index d'indice supérieure à la longeur de l'index: on la stocke dans un buffer, et lorsqu'on tente d'insérer une valeur qui n'existe pas dans une case de l'index: on retire la tête du buffer et on l'insère à la place.
  --- Push de la V9 sur git (merge avec les données et scripts de Nicolas Gillet)
  --- Correction de bugs mineurs
  -> corrigé problème lors du chargement de données "justes" mais vide (star.start)
  -> corrigé bug de redimentionnement lors de la désactivation de l'animation de rotation après redimentionnement de la fenètre
  -> mise en place de la désactivation des listeners claviers (déplacements caméra, affichage hud, etc...) lors de la saisie de valeurs par l'utilisateur dans les champs Point size, Level of detail, time, speed check des = menus.
  Assisté à la réunion Infusion sur Hadoop et Spark
  --- Mise en place de l'animation pour les données VOtable_3d
  -> Mise à jour des buffers d'animation: 2 cas à traiter:
  I) Dans data.js: lorsqu'on charge des données non-VOtable_3d, si les snapshots précédents et/ou suivants sont VOtables_3d, il faut mettre à jour les buffers departure et direction situés dans le parent renderableData (et non pas dans les snapshots adjacents)
  II) Dans renderableData.js: lorsqu'on homogénéise l'affichage des données VOtable_3d: après homogénéisation il faut mettre à jour les buffers direction et departure des snapshots adjacents: 2 cas à traiter:
  i) le snapshot contient des données VOtable_3d: mise à jour des buffers temporaires de renderableData
  ii) le snapshot contient des données non-VOtable_3d: mise à jour des buffers du snapshot en attribut
  III) Comme chaque snapshot contenant des données 3d aura son animation dépendante des buffers contenus dans renderableData après homogénéisation; on est obligé de les stocker sous forme de tableau de buffer (et pas juste sous forme d'un buffer simple comme pour la position)
  -> Dans le cas du buffer departure, ce dernier doit être initialisé (vide) dans renderableData depuis data lors du chargement des données
  -> En multivue: nécessité de transmettre toutes les données contenues dans les buffers des renderableDatas de la première vue à la seconde à sa création (auparavant toutes les données étaient contenues dans data => commune aux 2 vues donc il n'y avait aucun problème)
  -> En multivue: comme les mêmes datas sont liées à plusieurs renderables datas: pour envoyer les informations aux bons buffers (cf I) ), nécéssité de stocker dans data un array des références aux renderableDatas liées

Mai

• 2: --- Mise en place du mode Widget:
  I) Au niveau du html/css:
  i) Si mode normal: il doit juste y avoir la balise <div id:"app"></div> dans le body
  ii) Si mode widget, en plus du contenu normal de la page, la balise "app" doit être contenue dans une div ayant pour id "simuWidget" (et dotée dans son css d'une width et height de mêmes valeurs)
  II) Au niveau de l'application:
  -> Rien à changer au niveau du code si l'on veut passer ou non d'un mode à l'autre (la présence seule de la div "simuWidget" suffit à faire la différence)
  i) App.js: au lancement de l'application, on cherche si ou non app est enrobée par simuWidget dans le dom, et on appelle une fonction d'initialisation spécifique de Simu.js selon
  ii) Simu.js:
  -> mode normal: pas de grosses modifications par rapport aux iterations precedentes, excepté qu'on set dans le css d'app l'attribut position sur "fixed"
  -> mode widget:
  a) on set dans le css d'app l'attribut position sur "static"
  b) on set la width de l'attribut container du dom à 0 (en mode normal égale à la taille de l'écran, sert à corriger le bug de disparition de la deuxième vue en multivues)
  c) on définit un double égal à largeur de la div wrapper / largeur de la fenètre -> (servira à conserver les proportions de la vue lors du redimentionnement de la fenètre en mode widget)
  ++ on set par défaut l'app sur une vue simple en mode rotation, et on désactive les listeners
  --- Petit changement dans les caméras par défaut (maintenant 1 caméra de face)
  --- Bug: pour une raison inconnue: lorsqu'on est en mode widget et que l'on transite plusieurs fois d'un état à un autre, le compteur de fps s'affole et l'animation devient étrange (400fps???)
• 3: --- Finalisation du mode Widget:
  -> Le css de l'élément "app" a été déplacé dans app.js (et n'a plus à se trouver dans un .css extérieur à l'application), i.e. désormais le fait que l'application soit en mode widget ou non dépend uniquement de la page html contenant l'application.
  -> Correction du bug des fps qui s'affolent: (lié au fait qu'en widget mode, le fait de réinitialiser la vue à chaque passage vue pleine / vue widget crééait un nouveau renderer sans supprimer le précédent)
  --- Continué le travail de correction des bugs:
  -> bug d'animation dans le cas des VOtable_3d (la première fois qu'on lance une animation, cette dernière est aberrante, et semble se "corriger" ensuite)-> le buffer directions n'est pas mis correctement à jour?
  Explication: lorsqu'on charge des données VOtables_3d, on set les buffers pos, dir, et departure DU snapshot, puis on update les buffers direction et departure des snaps adjacents SAUF QUE l'homogénéisation des données de chaque snapshot se fait au moment où l'on veut afficher ce dernier, I.e.:
  i) j'insère une donnée A en position 0
  ii) j'insère une donnée B en position 1 -> homogénéisation de B (SEULEMENT), maj du buffer direction de A (qui n'est PAS homogénéisé)
  iii) je me replace sur A -> homogénéisation de A MAIS PAS DES BUFFERS DIRECTION !!!!!!!!!!!!!!!!
  i.e. il faut non plus homogénéiser un snapshot donné quand celui est sélectionné pour l'affichage, mais les homogénéiser à l'avance dès qu'une nouvelle donnée est insérée....
  -> auparavant: lors d'un changement de bornes globales:
  i) on mettait à jour les bornes de chaque renderable data
  ii) on mettait à jour les données AFFICHEES de chaque renderable data
  (i.e. maj de position PUIS maj de direction et departure selon snaps adjacents)
  -> maintenant:
  i) on met à jour les bornes de chaque renderable data, puis, pour chaque renderableData
  A) premier loop (les 2 loops sont successifs et non imbriqués)
  ii) on met à jour les données de CHAQUE SNAPSHOT dans renderable data (UNIQUEMENT LA POS)
  B) second loop
  iii) on met à jour les buffers directions de CHAQUE SNAPSHOT dans renderable data
  -> pour cela: modifié fonctions setLocalyModifiedOctree, updateNext/PreviousSnapshotPosition pour qu'elles acceptent des ids (si pas d'id: prend currentId par défaut => sinon: prend l'id)
  --- Entretien avec Mr.Schaaff et Nicolas Deparis && Gillet: définition des objectifs
  -> mise à jour du log des bugs
• 4: --- Correction des bugs:
  -> résolu le bug de chargement des données VOtable (qui ne fonctionnait plus): l'erreur venait de l'attribut bornesOfView de renderableData, qui n'était jamais initialisé (cause: updatePositionBornes n'était pas appellé lors de l'éxécution de la fonction de chargement des données VOtable_3d dans la classe data)
  -> résolution du bug d'animation entre les données non-VOtable_3d:
  i) dans la fonction setCurrentSnapshot de data: if('!='"VOtable_3d") devait être un '=='
  ii) dans la fonction computeAbsolutePositionBornesOfRenderedData de view: les 2 boucles d'update sur les buffers des données ne doivent s'effectuer QUE si le snapshot traité est de type Votable3d (une condition a été rajoutée)
  -> concernant le bug sur les données "star_end", où 3000+ points ont des positions nulles, le problème vient en fait des données elles-mêmes qui attribuent plusieurs fois le même id à des points différents (cf calcul simultané sur différents processeurs...)Le problème est que l'id d'un point est rémanent d'une simulation à une autre: si on essaie d'attribuer des ids uniques et arbitraires aux différents points, la fonction d'animation donnera des résultats aberrants.
  La solution qui a été trouvée est de signaler à l'utilisateur (via un alert) que ses données comportent des ids dupliqués lorsque c'est le cas.
  -> bug de suppression des données en multivue: seule 1 vue avait son affichage mis à jour (corrigé)
  -> résolution du bug de positionnement des box lors de l'animation en multivue: il était lié au fait que les données relatives aux boîtes de l'animation courante étaient contenues dans leurs snapshots respectifs... Or comme c'est le cas pour les buffers d'animation (position, departure, direction...) ils sont mis en commun pour chaque vue et lors de la mise à jour lors du passage d'un snapshot à l'autre seul le dernier est sauvegardé.
  Solution trouvée: stocker les informations relatives à la box des données VOtable_3d dans leur renderableData
• 6: -- Correction des bugs:
  -> corrigé le bug d'animation lorsqu'on la stoppait puis la relançait, où les points prenaient des directions aberrantes.
  Cause: dans renderableData, lorsque departure est INITIALISE avec les valeurs de position:
  this.modifiedDepartures[idVar] = this.modifiedPositions[idVar];
  on ne copiait pas les valeurs mais une REFERENCE de position cf effets de bord, i.e. on doit utiliser slice soit this.modifiedDepartures[idVar] = this.modifiedPositions[idVar].slice(0)
  -> bug du positionnement du curseur dans la timeline: 2 causes: depuis la V0, dans certaines conditions t doit être égal à 0,0001 sec, et dans d'autre, 0,00001 sec (corrigé); de plus le léger décalage à la pause/démarrage a été corrigé avec un simple -10px.
  -> corrigé bug des points qui disparaissent (cf avec un jeu de 10 points seuls 8 sont visibles): après avoir effectué des tests il s'avère que c'est encore une fois le niveau de détail qui en est à la cause.
  Le problème vient de la fonction computeCulling de renderableData; et plus précisément de:
  var start = this.drawCalls[i].start / levelOfdetailMax + j * this.data.snapshots[this.data.currentSnapshotId].index.length / levelOfdetailMax;
  var count = this.drawCalls[i].count / levelOfdetailMax;
  car (comme pour le cas de l'index trié selon le niveau de détail), lorsque le nb de points
  n'est pas divisible par 4, on a des nb à virgules i.e. des variables du tableau qui ne sont jamais lues
  (et comme ce morceau de code est appliqué à chaque octree, même en ayant un jeu de donné de départ divisible par 4, dès qu'on a plus de 1000pts ces derniers sont répartis entre les octrees, i.e. il est très improbable que le nombre de points qu'ils contiennent soit toujours divisible par 4)
  -> corrigé petit bug de rotation en mode widget: si on lance la rotation en mode plein et qu'on repasse en mode widget, ce dernier affiche toujours les données en rotation
  -> corrigé petit bug d'affichage du repère: lorsqu'on chargeait des données qui prenaient toute la taille de la boîte:
  le repère, s'il était visible, était recouvert par la boîte: corrigé
  -> problème de compatibilité sur chrome et chromium: dû au fait que les webworkers ne peuvent pas être run en local sur ces navigateurs, normalement si l'application est utilisée depuis un serveur il ne devrait y avoir aucun problème.
• 9: -- Continué la correction de bugs:
  -> Correction du bug de déformation des données adjacentes lorsqu'on charge des données; et durant l'animation.
  Cause: comme certais points des simulations sont cycliques (i.e. dans leur déplacement ils passent d'un côté du cube de données à un autre), la solution qui était mise en place depuis la V0 était, lors du chargement de nouvelles données (i.e. la mise à jour des buffers déplacement) de "téléporter" les points qui avaient à parcourir une distance>0.5 de l'autre côté du cube (grâce à la méthode cyclicPosition de snapshot).
  Le problème est que ce déplacement des données n'était pas très fin (par exemple, si un point se trouvait en x=0.8, si suite au chargement d'un autre snapshot sa destination avait un x=0.2, la position du point dans le premier snapshot se retrouvait avec un x= à 0.8-1= -0.2, i.e. il se trouve en dehors du cube de données, d'où le fait que ce processus ai pu passer pour un "bug")
  La solution trouvée a été de ne pas modifier le buffer position des points de la simulation à t=0; mais plutôt d'effectuer dynamiquement le changement de coordonnées durant l'animation, seulement dès que l'une des coordonnées xyz devient >1.
  Le positionnement des points à la pause durant une animation est géré par la méthode computePosition de Data; mais leur position durant l'animation est gérée par le shader parametric.animated.vertex, qu'il a fallu modifier.
  -> Il y a un bug assez important qui cause la "disparition" / "apparition" de certains points lorsqu'une animation passe d'un snapshot à l'autre (présent aussi depuis la V0). Il semblerait que ce soit dû à une mauvaise initialisation des buffers déplacement, et que ce soit lié à l'index de l'octree lorsque ce dernier contient plus de 0 fils.
  (lorsqu'on set la taille de chaque octree à 10 milions de points, aucun problème de transition n'est observé)...
  -> Il est fort probable que ce bug soit lié à un autre bug découvert aujourd'hui (et visiblement aussi présent depuis la V0): lorsqu'on charge des données dans un snapshot puis qu'on en charge d'autres dans le snapshot directement au dessus, l'animation est très étrange et ne correspond absolument pas à l'animation qu'on aurait obtenue entre les mêmes données mais insérées dans l' "ordre" normal. (sûrement liés vu que 2 bugs ont pour origine les buffers direction...)
  -- Création du script trian pour la visualisation de données médicales
  -> script assez simple à réaliser; néanmoins comme les seules informations contenues dans les fichiers .trian sont des coordonnées xyz, on ne peut qu'afficher les données (pas de possibilité de mettre en valeur un paramètre donné, etc...)
• 10: -- Continué la correction de bugs:
  -> Demmandé à Nicolas Gillet jeu de donnée part de 17 points répartis sur 4 fichiers, pour pouvoir effectuer des tests à petite échelle
  -> Il s'avère que le bug d'animation étrange selon l'ordre d'insertion des données et le bug de disparition des points sont deux bugs totalement distincts
  -> Correction du bug "d'animation étrange": après avoir effectué des tests il s'avère que la cause est un peuplement erroné des buffers de déplacement (qui ne sont donc pas à l'origine du premier bug).
  En effet l'index des points que l'on réccupère après chargement des fichiers est envoyé à l'octree qui le réarrange selon l'ordonnancement des points dans l'espace. Comme on met à jour les buffers de déplacement selon la présence d'un autre snapshot plus haut / plus bas, le problème est que comme l'agencement des données change d'un snapshot à l'autre, la position des indices dans le buffer des index aura changé et on donnera aux points la direction d'un point d'un id différent dans l'autre snapshot. La raison pour laquelle ce bug n'a pas été mis en évidence plus tôt est que le peuplement des buffers se fait de la manière suivante:
  i) Des données sont présentes dans le snapshot précédent
  => on met à jour le buffer direction du snapshot précédent à partir du snapshot courant
  ii) Des données sont présentes dans le snapshot suivant
  => on met à jour le buffer direction du snapshot courant à partir du snapshot suivant
  Le fait est que cette mise à jour des buffers était appellée dans le snapshot courant avant l'appel à la fonction d'homogénéisation de l'index pour le niveau de détail; ainsi dans le cas i) on la direction du snapshot précédent réccupère les bonnes directions, et ensuite l'index du snapshot courant est trié selon le niveau de détail, mais dans le cas ii) le snapshot suivant a déjà eu son index trié selon le niveau de détail et le snapshot courant réccupère les mauvais index
  Correction: création d'un buffer supplémentaire qui permet d'effectuer la correspondance entre les tableaux d'index
  (i.e. sa case 0 contient le no de case de l'index "0" dans le buffer des index) qui permet à deux snapshot de se transmettre leurs coordonnées sans erreurs.
  -> Commencé à étudier le bug de disparition des points...
  Il s'avère qu'un bug "intermédiaire" a été découvert: la méthode de gestion du niveau de détail que je pensais avoir corrigée le 6 ne fonctionne pas (ce n'est pas visible à grande échelle, mais sur le jeu de test de 17 point c'est très visible)-> visiblement l'algorythme est faux et n'arrive pas à gérer le fait que chaque octree peut contenir un nombre de points non divisible par 4.
  Le nombre total de points dessinés est bel et bien égal au nombre de points affichés (ce qui fait qu'en se basant sur cette information l'algorythme semblait juste) mais en fait dès que l'on essaie d'afficher les points en effectuant des recoupements par octree les points situés à des index divisibles par 4 sont affichés plusieurs fois, et d'autres jamais...
  Il faut donc réexaminer l'algorythme de tri...
• 11: -- Continué la correction de bug
  -> Remaniement de l'algorithme de tri: après avoir effectué de nombreux tests (notamment la mise en place d'octrees de taille 8 et l'allouement de 8 cases complètes de buffer index pour chaque octree "feuille" -les vides ayant pour valeur -1- afin de pouvoir effectuer des recoupements justes en divisant par 4 pour le niveau de détail) il s'est avéré qu'il est impossible (ou tout du moins cela nécéssiterait beaucoup plus de temps dans la mesure où il faudrait complètement toute l'organisation des buffers) de gérer le niveau de détail en se basant sur l'algorythme d'origine (qui consistait à morceler les index de chaque octree sur les 4 moitiés du buffer index).
  La fonction de morcelage n'est donc plus utilisées et on utilise désormais l'index post-octree comme base (i.e. les ids sont chaînés par ordre d'appartenance aux octree feuille) et la l'algorithme d'affichage opère de la façon suivante: lorsqu'un octree est à l'intérieur du champ de vision, on réccupère directement son start et son count, et on envoie au drawCall les index situés à start et au nombre de 1/4*count, situés à start+1/4*count+1/4*count, etc... (et du coup le dernier niveau de détail n'affiche pas 1/4 de points supplémentaires, mais le nombre égal au quart des points moins le nb de points équivalents au reste de la division par 4 du nombre total de points)
  -> Correction du bug des points qui disparaissent:
  L'origine du problème a été trouvée: en fait tout vient de la fonction qui permet de gérer l'affichage de manière optimisée.
  Lors de la création de l'octree, chaque octree se voit attribuer un objet "box" qui contient ses bornes de définition.
  Sauf que lorsqu'on lance une animation, les points vont se déplacer, mais l'octree tel qu'il a été défini lors du chargement des données ne changera pas. Ce qui veut dire que si un point qui à t=0 n'est pas dans le champ de la caméra va à t=0.5 se retrouver à une position qui devrait le faire apparaître dans le champ, le fait est qu'au niveau des calculs d'optimisation ce point sera considéré comme étant dans un octree dont les bornes (correspondant à celles de t=0) ne se situent pas dans le champ de vision. Le point ne sera donc pas affiché.
  Et lorsque l'animation se terminera et que le changement d'octree s'effectue: l'algorithme de calcul du niveau de détail prendra comme référence les box du nouvel octree, et de ce fait les points qui précédemment n'étaient pas affichées auront leurs octree avec des box de nouveau cohérentes, et seront affichés.
  Correction: le problème est qu'il n'est pas du tout optimisé de mettre à jour les box des octree de façon dynamique lorsque l'animation est en cours (fonction réccursive, gourmande), la solution qui a été trouvée est:
  i) Lorsque l'animation est en cours, afficher la totalité des points sans calcul de précision (à cause de la position cyclique des points qui peut les faire passer d'une borne à l'autre du cube, il n'est même pas possible d'effectuer une optimisation grossière)
  ii) Mettre en place une fonction de mise à jour de l'octree, mais de l'appeller uniquement lors du changement de snapshot ET lors de la mise en pause de l'animation. Ainsi il n'y a plus aucun problème d'affichage de points, et lors de la pause on optimise bel et bien l'affichage tout en affichant les points en tenant compte de leur position réelle dans le temps.
  -> Bug du niveau de détail avec le nouvel algorithme de tri:
  Le problème est que l'index des octree n'étant plus morcelé, à la précision 4 tout les points sont bel et bien affichés, mais lorsqu'on passe aux niveaux 3,2 et 1 l'affichage des points n'est pas réparti de façon homogène dans le cube. (i.e. au niveau 1, tout les points affichés seront dans le quart bas gauche du cube).
  Correction: lorsqu'un octree est entièrement situé dans le champ de la caméra, au lieu d'ajouter au drawCall son start et son count, on va aller chercher réccursivement le start et le count de chacun des octree feuilles qu'il contient.
  Le problème qui aurait pu être posé par cette méthode est que, si le niveau de réccursivité est trop grand, cela impacte les performances. Comme cette méthode fonctionnait sans affecter les fps sur les simulations part (contenant +2 millions de points) sachant que la taille des octree est set depuis la VO à 1000; cette taille fixée à 1000 a été remplacée par une taille qui s'ajuste dynamiquement selon le nombre de points total dans l'octree. Comme cette taille est proportionnelle au nombre de points, le rapport de taille entre les octree feuilles et l'octree principal est suffisament élevé pour que l'homogénéisation du niveau de détail soit totalement uniforme pour l'utilisateur, tout en étant suffisament bas pour que le nombre d'appel réccursif ne dépasse jamais une certaine limite.
• 12: -- Fin de la correction des bugs:
  ->Effectué série de tests afin de vérifier qu'aucune erreur ne reste / n'a été induite par les modifications
  ->Modification de la méthode d'intersection entre la souris et les points
  (cette dernière ne fonctionnait plus car basée sur l'ancien algorithme de tri)
  ->Corrigé petit bug: le repère passe en priorité par rapport aux box lorsque l'on change de snapshot
• 17: -- Amélioration de l'affichage
  -> Comme le nouveau mode de tri d'index est "trop" régulier, il a été légèrement modifié afin que sur les niveaux de détail <4 le rendu soit homogène.
  I.e. lors de la création de l'octree chaque feuille se voit dotée d'un index de la forme [2,3,1,0] dont les éléments sont ordonnés de façon aléatoire, de telle sorte que lors de l'affichage la sélection des points par feuille se fasse de la manière suivante:
  *pour chacun des 4 niveaux de détail n; pour i allant de 0 à n
  *si index[i]=n avec i tel que i<niveau de détail actuel=> affichage du quart d'index correspondant
  *sinon le quart n'est pas affiché
  -> Il a fallu modifier à nouveau la méthode de sélection de point via la souris (cette dernière ne devant permettre de sélectionner que les points affichés selon le niveau de détail)
  -- Petite correction
  -> Les données VOtable_2d sont toutes normées selon des bornes [0-1] (ainsi = jeux superposés recouvrent la même sphère)
  -- Initié la mise en place de l'outil de zoom
  -> A mettre en place:
  i) Au niveau du menu, prend la forme d'une checkbox présente dans le menu d'options de la vue qui active ou désactive l'outil, changer de mode de vue ou décocher la case fait revenir l'application à son état initial
  ii) Outil de sélection au niveau de la vue d'origine:
  1) cube semi-transparent qui doit apparaître / disparaître dans la vue lorsqu'on active / désactive l'option
  2) cube muni d'un repère dont les 3 axes peuvent êtres sélectionnés par l'utilisateur afin de déplacer le cube
  3) cube doit pouvoir être aggrandi/réduit, mais pas plus que la taille des données d'origine
  iii) Lien entre le cube et la seconde vue...
• 18: -- Mise en place de l'outil de sélection
  -> Ce dernier prend la forme d'une boîte munie d'un repère, incluse dans le cube de données, qui apparaît lors de l'activation du mode de zoom
  (pour le modéliser les objets cylinder, cube et sphere de three.js)
  -> Chaque axe du repère est muni d'une pointe; si l'utilisateur clique sur cette dernière et effectue un drag end drop, il déplacera le repère dans l'espace par rapport à l'axe qu'il aura sélectionné (les mouvements de la caméra sont désactivés durant le processus)
  (si 2 pointes se superposent, la pointe sélectionnée sera la plus proche de l'utilisateur)
  -> De la même manière, l'origine du repère, représenté par une sphère, peut être utilisée pour modifier la taille de la boîte, en l'agrandissant à partir de son centre. (on utilise la propriété scale qui permet d'agrandir uniformément les objets; néanmoins pour les axes du repère comme les objets sont convertis sont convertis sous forme de vecteurs après leur insertion dans la scène, il est impossible de modifier une de leur propriété seule -comme la longeur-, on est donc obligé de retirer les axes de la scène pour les remplacer par de nouveaux à chaque opération d'agrandissement)
  -> Il est impossible de déplacer l'outil en dehors des bornes du cube de données, et il est impossible de lui donner une taille débordant de ce dernier.
  -> Le fait de pouvoir sélectionner des parties de l'outil via la souris utilise les fonctions de raycasting de three.js; on différentie les objets réccupérés via le nom qu'on leur a donné avant de les insérer dans la scène (l'appel à la fonction de raycasting se fait de pair avec la méthode qui gère le clic sur les points; si un élément de l'outil de zoom est sur la trajectoire du rayon, alors l'interraction avec ce dernier passe en priorité et les informations liées au point ne s'afficheront pas)
• 19: -- Terminé la mise en place de l'outil de sélection
  -> le fait de cocher/décocher le bouton de zoom fait désormais apparaître/disparaître l'outil de sélection
  -> lorsque l'utilisateur sélectionne un élément de l'outil (axe, centre du repère) ce dernier apparaît en surbrillance le temps de la manipulation (en utilisant un MeshBasicMaterial ayant BackSide comme attribut side)
  -> la manipulation d'un des axes du repère entraîne l'apparition de la droite selon laquelle on peut translater ce dernier
  -> Gestion de l'activation/désactivation du mode de zoom:
  * si l'utilisateur est en mode zoom et qu'il change de snapshot/appuie sur echap/ajoute un nouveau snapshot: désactivation de l'outil de zoom
  * si l'utilisateur est en mode zoom et qu'il lance une animation/qu'il déplace le curseur sur la timeline ou encore si il manipule la variable temps dans les options: désactivation de l'outil de zoom
  (le fait de lancer une animation n'est pas pris en compte si l'utilisateur est sur le dernier snapshot)
  -- Correctifs:
  -> fait en sorte que l'on a toujours un couple data/snap vide d'instancié au chargement de l'application
  ->correction de bug: lorsqu'on clique sur un emplacement data/snapshot vide, si la colonne data de cet emplacement n'était pas la colonne courante à l'instant précédant le clic: erreur dans le chargement des données.
  origine de l'erreur: mauvais positionnement d'une ligne dans la fonction brows de simu.js
• 20: correction de bugs (normalement, là tout marche)
  -> bug d'affichage (visiblement présent depuis plusieurs versions -depuis la V6-):
  Ce bug n'est rencontré que sur des jeux de données VOtable_3d; plus le nombre de données chargées devient important, plus le nombre de points affichés est démultiplié
  (par exemple en chargeant 500 points dans un emplacement, puis 200 dans un autre: 1700 points d'affichés)
  Le problème était dû au fait que lorsque l'on effectuait une mise à jour l'octree suite à une modification de l'affichage, l'appel à la fonction createOctreeFromPos (contrairement à ce que son nom indique), rajoutait seulement à l'octree une arborescence créée à partir des points passés en paramètre.
  Ainsi au premier appel de fonction, on passait d'un octree vide à une arborescence de 8 points, tandis qu'au 2ème on réinjectait 8 points dans l'arborescence, mais sans supprimer la précédente: l'octree a alors 16 enfants (!!!)
  Correction: on réinitialise l'octree avant l'appel à la fonction dans renderableData
  -> bug d'affichage (vieux problème de frustum sur les données VOtable_3d):
  Ce bug causait de gros problèmes d'affichage lors des calculs d'optimisation via le champ de la caméra pour les données VOtable_3d.
  (il n'avait pas été résolu; c'est pourquoi jusqu'à maintenant pour des données VOtable_3d tout les points étaient systématiquement affichés sans prise en compte de leur position par rapport au champ de la caméra)
  Correction: cela venait d'un problème de tri, quand on calcule les champs position homogénéisées dans renderableData il faut d'abord réarranger le buffer selon l'index que l'on obtient à partir du nouvel octree (c'est pour cela que l'on a pas besoin de passer l'index en paramètre en tant que buffer)
  for (var i = 0; i < size; i++) {
  position[3 * i] = snap.position[3 * snap.index[i]];
  position[3 * i + 1] = snap.position[3 * snap.index[i] + 1];
  position[3 * i + 2] = snap.position[3 * snap.index[i] + 2];
  }
  -> bug de correspondance entre le niveau de détail et les points que l'on peut cliquer à la souris (bug conernant les données VOtable_3d):
  Par exemple sur jeu de données VOtable de 500, à l'origine du flux: en niveau de détail 2.5: les points visibles ne sont pas détectés tandis que ceux invisibles le sont
  Correction: l'erreur venait de la condition || this.data.snapshots[this.data.currentSnapshotId].metaType=="VOtable_3d" à la ligne 1119 de renderableDatas.
  ->bug d'affichage (sur les données VOtable_3d seulement, visiblement lié à la correction des bugs précédents):
  Après insertion de plusieurs jeux de données, la fonction d'optimisation de l'affichage des points via la position de la caméra ne fonctionnait plus.
  (par exemple un jeu de 955 points est correctement affiché, mais après l'insertion d'un jeu de 500 points, le premier jeu n'est visible que si l'utilisateur a l'octree complet dans son champ de vision)
  Origines du problème (2 sources d'erreur):
  i) lors de l'initialisation de l'octree: l'index n'est pas data.currentIndex mais data.snapshits[idVar].index
  ii) l'attribut modifiedOctree n'est pas adaptée à l'homogénéisation jour des données VOtable_3d lors de l'appel à la mise à jour des = données (des optimisations sont possibles et seront testées après mise en place de l'outil de zoom)
  De plus en multivues il faut désormais vérifier que modifiedPositions n'est pas undefined et l'initialiser dans la fonction de création de l'octree au besoin
  (pour éviter les effets de bord on utilise .slice() lors de la création de la 2ème vue par simu)
  ->Assisté à la conférence "Understanding accretion onto black holes using X-ray spectral-timing"
  (tenue par W. Alston)
• 23: ->Implémentation du zoom dans l'interface
  Comme la fonctionnalité de zoom est prévue pour être utilisée sur la vue courante; il faut qu'elle soit utilisable en vue simple mais aussi en multivues.
  Il a donc été décidé de faire en sorte que l'activation du zoom s'opère de la manière suivante:
  i) la vue sur laquelle on active le zoom -la vue maître- se retrouve munie de l'outil de sélection et se retrouve affichée à gauche de l'écran
  ii) la seconde vue -la vue esclave-, normalement utilisée en multivue, se retrouve à droite de l'écran (et a son menu entouré de bleu)
  Ce choix résulte du fait que la 2ème vue de l'application (celle sur laquelle on n'applique pas le zoom) ne serait de toute façon pas affichée tant que le zoom est actif.
  Plutôt que de créer/supprimer un nouvel objet vue à chaque utilisation du zoom, on utilise cette seconde vue comme support en la rendant dépendante de la première.
  AInsi son menu dispose de moins d'options -comme la fonctionnalité de merge, ou encore le bouton d'activation du mode de zoom- (car ces dernières sont gérées depuis la vue maître)
  Si l'utilisateur effectue l'une des actions qui désactive le mode de zoom (comme changer de snapshot, presser echap, etc...) l'application revient à l'état précédant le déclenchement du mode de zoom.
  (par exemple si l'utilisateur était en vue simple, alors on repasse en vue simple)
  Pareillement le fait d'avoir le focus sur la vue esclave ne la fera pas passer prioritaire au moment de désactiver le mode de zoom.
  (il est aussi impossible d'insertion de nouvelles données tant que le zoom est actif)
  -> Correctif dans l'animation des données Votable:
  Le fait d'avoir l'affichage des données VOtable optimisé grâce au frustumCulling a permi de mettre un jour un problème dans l'affectation des directions et des departures (uniquement sur les données VOtables), qui a été corrigé.
  Le problème était aussi lié au fait que la mise à jour dynamique de l'octree durant l'animation ne prenait pas en compte le cas où les positions des points par rapport auxquelles on modifiait l'octree provenaient de l'octree modifié stocké dans renderableData (toujours dans le cas des données VOtable).
• 24: -> Implémentation de la réccupération des points présents dans l'outil de zoom (et leur mise en forme)
  La mise à jour des données de la vue esclave doit être effectuée:
  i) Lorsque la fonction de zoom est activée
  ii) Lorsque l'utilisateur relâche la souris après avoir déplacél'outil de zoom ou modifié sa taille
  Cette mise à jour se déroule en 2 étapes:
  1) Le stockage des points présents dans l'outil de zoom et leur formatage
  2) L'affichage de ces points par la vue esclave (seul le point 1) a été complété pour le moment)
  Explication du point 1)
  Lorsque i) ou ii) se produisent, une fonction réccupère le centre et la largeur de l'outil de sélection de la vue maître, et les envoie à chaque renderableData que la vue maître possède, et réalise pour chacune d'entre elles un appel à la fonction de réccupération/formatage des points.
  Algorithme:
  I) Initialisation
  1) On calcule les coordonnées des 8 points du cube de zoom, ainsi que ses bornes min et max xyz
  2) On initialise les buffers slavePosition et slaveInfo (où slaveInfo contient les mêmes champs que les données courantes dans le snapshot courant de l'objet data lié au renderableData)
  3) 3 sous fonctions sont utilisées par l'algorithme principal:
  a)une fonction permettant de déterminer si le cube de zoom contient (partiellement ou complètement) un oct passé en paramètre (en se basant sur le nombre de points)
  b) une fonction permettant de déterminer si un oct passé en paramètre englobe complètement le cube de zoom
  c) une fonction permettant de déterminer si un point donné est contenu par le cube de zoom
  II) Algorithme principal
  C'est une fonction d) récursive qui reçoit un oct en paramètre (à l'initialisation: l'octree du renderableData)
  Si l'oct contient plus de 0 points:
  | Si a(oct)==0
  | | Si le volume de l'oct est > au volume du cube de zoom ( )
  | | | SI l'oct a des enfants
  | | | | On appelle d) sur chacun de ses fils
  | | | Sinon si b(oct) est vrai
  | | | | Pour chaque point ayant son index dans oct
  | | | | | Si c(point) vraie alors on ajoute le point et ses informations à slavePosition et slaveInfo
  | Si a(oct)==8 (l'oct est complètement englobé par le cube de zoom)
  | | Pour chaque point ayant son index dans oct
  | | | On ajoute le point et ses informations à slavePosition et slaveInfo
  | Si a(oct)!=0 et a(oct)!=8
  | | Si oct a des enfants
  | | | On appelle d) sur chacun de ses fils
  | | Sinon si b(oct) est vrai
  | | | Pour chaque point ayant son index dans oct
  | | | | Si c(point) vraie alors on ajoute le point et ses informations à slavePosition et slaveInfo
  Après avoir calculé slavePosition et slaveInfo, on les stocke ensuite dans l'objet data lié au renderableData traité (ainsi chaque objet data contiendra les points englobés par l'outil de zoom issus des données initiales)
  () Attention: on réalise la comparaison par volume car, si l'oct est plus grand que le cube de zoom, alors ssi son volume est plus grand que le cube de zoom il se peut qu'il englobe ce dernier.
  De plus, durant une animation l'octree est modifié (cf correction du problème de frustumCulling) et les boîtes des octs ne sont plus nécéssairement des cubes; il faut donc réaliser le calcul du volume à partir de la longeur maximale de la boîte.
  II) La vue esclave peut réccupérer les buffers depuis les objets datas (auxquels toutes les vues ont accès)
  (point II) en cours)
• 25: -- Mise en place des buffers depuis la vue esclave
  Après le traitement des points par la fonction précédente, on repositionne chaque point récupéré afin qu'il soit à l'échelle du cube de données et non plus de l'outil de zoom.
  On génère ensuite les buffers que l'on stocke dans chaque data des renderableDatas traités, ainsi que l'octree qui servira de base pour les calculs de frustumCulling de la vue esclave.
  Il est très important de noter que les buffers doivent être sous la forme de Float32Array, qui sont des typedArray et dont la taille est définie à la création (il est impossible de réaliser sur eux des opérations de type push), ce qui peut être contraignant lorsque l'on veut remplir les buffers au fur et à mesure que l'on parcours l'octreee.
  Il a donc fallu modifier les différentes fonctions de renderableData relatives à l'affichage des points de telle manière à ce qu'elles utilisent les buffers précédents lorsque la vue est en mode esclave, et plus précisément la fonction rafraîchissant l'affichage ainsi que la fonction de frustumCulling (il faut utiliser l'octree esclave pour gérer la détection des points).
  L'outil de zoom permet donc de restituer dans la vue esclave les différents éléments contenus dans le cube de zoom, qu'ils proviennent de différents jeux de donnés ou non.
  Il faut maintenant effectuer toutes les modifications nécéssaires afin terminer l'intégration de la fonctionnalité de zoom dans l'application.
  Modifications à apporter:
  1)Gestion du menu:
  -Lorsqu'on passe ne mode esclave
  i) Sauver tout les paramètres du menu actuel ( )
  ii) Supprimer menu normal et générer menu esclave
  -Lorsqu'on quitte le mode esclave
  i) Supprimer le menu esclave et générer le menu normal
  ii) Reset les options sauvegardées en ()
  2) Gestion des boîtes et de l'état du repère: similaire à 1)
  3) Il faut aussi garder une trace des renderableData actives ou non avant le passage en mode esclave
  (i.e. lorsqu'on quitte le mode esclave, on reset l'état d'affichage des données tel qu'il était sauvegardé)
  4) Il faut corriger la fonction de détection des points (qui ne fonctionne plus à ce stade)
  5) Il faut effectuer un rafraîchissemement de l'affichage de la vue esclave lorsqu'on:
  - active le zoom
  -modifie la position/taille de l'outil de zoom
  -désactive le zoom (cf le 3) )
  -active/désactive l'affichage de données VOtable_3d dans la vue maître (car l'affichage ou non de ces dernières change la position des points cf homogénéisation spatiale)
  6) Il ne doit pas être possible de supprimer des données tant que le zoom est actif
  7) Il doit être impossible d'ajouter des colonnes data / des lignes snapshot dans le DataUIManager tant que le zoom est actif
  8) Doit être impossible d'effectuer le chargement des données depuis les serveur VizieR
  (si le zoom est activé alors qu'une requète de chargement a été envoyée au serveur: alors lorsque l'application reçoit les données, il faut désactiver l'outil de zoom)
• 26: -- Mise en place des modifications définies le 25:
  Mise en place de 1)
  Mise en place de 5)
  Mise en place de 6),7),8)
• 27: -- Fin de la mise en place des modifications définies le 25:
  Mise en place de 2) et 3)
  Mise en place de 4)
  
  + LES INFOS NE CORRESPONDENT PAS
  GROSSE ERREUR: ne correspondent pas:
  -> sur données VOtable
  -> sur données Simu
  -> sur données de Zoom
  BUG CORRIGE SUR VOTABLE ET SIMU
  => EN MODE ZOOM, LES INFOS TRANSMISES DE VUE MAITRE A ESCLAVE SONT COHERENTES
  
  + vérifier comportement pour la mise en valeur d'un attribut particulier
  + problème dans la gestion du frustumCulling sur mode de zoom (parfois flash: données disparaissent pendant 0.5sec...=> vérifier comportement lorsque zoom sur animation en pause (t!=0))

Juin

• 2: mis en place la possibilité de positionner le cube de sélection par rapport à un point en appuyant sur la touche t; la taille actuelle du cube de sélection est conservée, sauf si le point est situé aux extrèmes du cube de données, auquel cas:
  i) La taille de l'outil de zoom est réduite mais le cube est toujours centré autour du point
  ii) La taille de l'outil de zoom devient minimale et il n'est pas centré autour du point (il colle à la paroi du cube de données)
  Présentation PowerPoint du stage
• 3: fini de mettre en place l'outil de zoom, la fonctionnalité info to highlight fonctionne désormais sur la vue esclave

Sauvegardes

• à définir au cas par cas suivant le sujet du stage

Liens

• ...

Versions testables

Testé sur ...

Documentation

• Rapport de stage: Rapport (pdf), Rapport (docx)
• Présentation: Presentation (pptx), Presentation (pdf)

Informations/travaux divers

• ...

Travail post stage éventuel

Liste des améliorations à envisager

Bugs connus