Stage de Pierre Lespingal - ENSIIE Strasbourg - [8/06/15 au 14/08/15]

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 (juin - aout 2015)

Juin

• 10 - Visite des lieux, rencontres avec les occupants
  Compte rendu par Arnaud Steinmetz du travail déjà réalisé
  Lecture de son wiki et du rapport de stage 2014 de Phillipe Gaultier
  A partir de la, le stage prend l'orientation suivante :
  • Amélioration des performances selon les conseils d'Arnaud : Utilisation des Octree ( S'inspirer de Potree) et Web Workers
  • Recherche sur la mise en avant de certain type d'informations, en lien avec une navigation et une interface utilisateur plus robuste ( Colaboration avec Nicolas Buecher )
  • Prise en compte de la dimension temporelle
  • Test sur / configs & plateformes
  • Utilisation de l'Oculus
  • Mise en place d'un affichage multi-vues

• 11 -
  Tentative de mise en place du projet oculus 2014 avec le sdk 1 : l'appli est difficilement déployable, à approfondir plus tard
  Test d'une librairie de gestion d'octree en webgl avec Three.js : threeoctree
  Comme l'avais remarqué Arnaud, celle ci n'est plus mise à jour, et est très mal documentée
  Si l'on souhaite vraiment utiliser une structure d'octree, il faudra vraisemblablement partir from scratch.
  Prise en main du code de l'appli d'Arnaud, quelques tests et modification comme l'ajout d'un effet "fog"
  Début d'une refactorisation du code, en plusieurs modules, pour en même temps en saisir la logique et la structure.
• 12 -
  Suivi de trois pré-soutenance de stage IUT
  Conférence sur l'expension de big-bang et son calcul
  Refactorisation du code, création de module spécifiques
  Assemblage des différents test en un seul projet (qui lit donc différents fichiers)
• 15 -
  Mise en place d'un dépo git, avec de base une démo simple à lancer
  Pour l'instant, la demo tourne à 60 fps la pluspart du temps sur une bonne machine
  L'idée serait donc de faire chuter ces fps en mettant premièrement en place le multivues, pour ensuite améliorer les performances et observer facilement les changements dans le taux d'affichage
  Néanmoins il reste encore pas mal de morceau de code et de fonctionnalitée implémentée à comprendre, comme le raytracing :
  Le raycasting est plus performant sur le nuage de point si celui n'utilise pas de GeometryBuffer, mais le gain d'un buffer face à un tableau d'objet semble plus conséquent. Des tests comparatifs seraient à faire si le raycasting devenait tout de même une composante principale de l'application.
  Par contre, un problème reste à régler : Le controle de type FPS utilise un ordre des matrices de rotations différents de celui attendu par le raycaster de THREE.js, d'ou une erreur sur les intersections...
  les octrees apparaissent de plus en plus interessant, pouvant améliorer hautement le temps de calcul du raycaster : http://threejs.org/examples/#webgl_octree_raycasting
• 16 -
  Pour tester les performances, ajout de switch entre différentes fonctionnalités :
  - Raycasting activé ou non
  - BufferGeometry ou Geometry
  - FustrumCulling ou non
  Le BufferGeometry offre toujours de meilleurs perf, mais ne rend pas aisée la manipulation des données ensuite : calculs lourds pour mettre à jour les position côté CPU, raycasting moins optimisé, difficulté d'implémentation des octree.
  Etape suivante : tester le calcul des positions suivant le temps côté CPU ou GPU, et comparer.
  Tentative d'utilisation de l'oculus sous linux, le SDK1 fonctionne, mais difficile à configurer sous OpenGL : Le tracking necessite une communication avec le casque via un protocole (HTTP), et pour l'instant le rendu stéréoscopique était toujours faux
  Le SDK2 ne fonctionne pour l'instant pas, il faut dire que linux n'est pas une priorité pour le dev d'oculus.
  
• 17 -
  Le calcul des positions côté CPU n'est pas envisageable pour l'instant, les fps chute à 0. Peut être avec des WebWorkers.
  Quelques lectures sur l'optimisation de la mémoire, cach miss, fragmentation, mais rien d'utilisable au final dans le cadre d'une application web
  Idée de gestion du temps & du raycasting, deux modes :
  - Statique : On calcul côté GPU une seul fois les positions pour le raycaster, mais pas d'avancés dans le temps.
  - Animation : Les positions sont calculés à chaque frame dans les shaders, mais pas de Raycasting disponnible
  On switch alors entre ces deux modes. Problème : le retour au mode statique, et donc le calcul côté CPU des positions prend entre 1 s et 1.5s
  Il peut être intéressant de tester le ColorPicking, qui normalement n'est plus utilisé pour faire du picking d'objet car nécessite deux passes graphique pour une seul frame à l'écran.
• 18 -
  Mise en place du ColorPicking :
  - le rendu supplémentaire semble enlever de 10 à 20 fps (Le calcul est effectué à chaque frame), alors que le raytracer en enleve entre 20 et 40 lorsque la souris est en mouvement. ColorPicking WIN ?
  Reste à le faire fonctionner correctement pour en être sur, pour l'instant la texture récupérée n'est pas la bonne... mis de côté, à revoir demain.
  - Le calcul côté CPU ne met plus que 15ms en moyenne. Apparement un dépassement de mémoire aurait causé le problème, bien que la console chrome n'indiquait aucune erreur. C'est bien mieux car la sortie du mode annimation se fait désormais instantanément,
  mais on ne peut pas non plus calculer côté CPU à chaque frame, puisque l'on souhaite afficher une frame touteS les 15ms justement.
• 19 -
  Debrief avec Arnaud pour parler de tous ce qui est encore à faire, comparer notre vision des choses.
  - tentative de résolution du raycasting, la valeur du treshold est jusqu'ici arbitraire et ne prend pas en compte l'attenuation due à la distance à l'objet. Resolution avec une valeur arbitraire, mais qui donne de bon résultat.
  
• 22 -
  Rajout de balise html en surimpression sur la particule sélectionné, ou l'on pourra y afficher quelques infos.
• 23 -
  Debrief avec Andre, ainsi qu'avec Nicolas Deparis.
  Nicolas souhaitait changer l'aspect des particules, on utilise donc maintenant un sprite avec transparence pour avoir un effet de blending lumineux.
  On devrait pouvoir bosser avec des cubes de données plus volumineux prochainement, de l'ordre de 16M de particules.
• 24 -
  Avancés dans les travail de refactorisation du code. Nicolas commence à réflechir à l'interface, il faudra donc travailler à deux sur le code, celui-ci doit être clair et maintenable.
  On peut maintenant ajouter ses propres script pour charger les fichiers.
• 25 -
  On souhaite pouvoir faire en sorte de charger de 1 à plusieurs snapshot au sein de la même appli. On a donc des tableaux de buffer pour les snapshot, et une indication pour savoir entre quel et quel snap on se trouve.
  Utilisation de async.js pour charger les multiples fichiers de manières asynchrone, puis traiter le tout lors de la fin d'exécution de toutes les taches.
  Gros problèmes de performances, possiblement lié au fait que les variables sont de plus en plus embriqués dans des objets, des tableaux et des espaces de nom. Il faut bien penser le projet pour assurer maintenabilité ET performance.
  Découverte du métier de documentatliste au CDS, au travers du fonctionnement de Vizier, Simbad et Aladin.
  On peut désormais charger n'importe quel type de fichier, du moment que le script et bien configuré. Reste tout de même à gérer les erreurs possibles (fichier mal formatté, snapshot de tailles diffèrentes, etc)
  Reste à corriger certaines erreurs d'indices, mais les problèmes de perf sont peut être aussi du à l'utilisation du debugger, qui doit gérer beaucoup de variables et d'objets en mémoire. Sans le débugger, les fps sont très correctes.
• 26 -
  Réunion infusion, avec présentation de SVG, Canvas et WebGL. C'était l'occasion de montrer un peu les premières démo de l'application.
  Conférence sur la théorie des spin supérieur (hight-spine), théorie unificatrice de la relativité et de la théorie quantique des champs.
  On peut désormais charger plus de deux snapshots, et lire l'ensemble de l'animation. Reste à mettre en place une interface convivial pour se balader entre les différents snap.
  On peut lire différents fichier, mais on ne recupere pour l'instant que les positions.
  Il faudrait trouver un moyen de connaître le nombre de particules à l'éxecution, pour construire des buffers correspondants.
• 29 -
  Test de performance suivant le nombre de passe graphique effectués : On peut choisir le nombre de drawCalls à faire pour afficher l'ensemble des données du cube. Aucune différence apparente entre 1 et 100 drawcalls.
  Ces tests sont assez encourageant pour la mise en place des octrees.
  Problèmes de performances sur Firefox, 20fps que l'on affiche le pointCloud ou non, le profileur incrimine la fonction renderer.clear, mais pas de précédents sur le web.
  Plusieurs amélioration légère qui ne sont pas disponnible via three.js :
  - Entrelacer les données envoyées au GPU
  - Envoyer les couleurs sous forme d'octet non signé (0 - 255) plutôt que float
  On calcule désormais le nombre de particules à l'éxecution, on peut choisir le script via dat-gui.
• 30 -
  Début de travail sur les octrees : construction de l'octree à partir du tableau de donnés de positions
  Ajout de quelques fonctionnalités funky :
  - Barre de chargement
  - zoom progressif lors du double clic
  Découverte d'outil de profiling du GPU propre à Chrome : http://learningthreejs.com/blog/2013/04/05/debugging-with-chromes-canvas-inspection/

Juillet

• 1 -
  La construction d'un octree à partir des positions fonctionne, reste à tester avec un raycaster.
  Decouverte des fonctionnalité d'HTML5 vis à vis des capteurs de smartphone : http://www.html5rocks.com/en/tutorials/getusermedia/intro/#toc-gettingstarted
  Le raycasting sur l'octree fonctionne à peu de chose près, lorsque l'on est en dehors du cube principale, on arrive à isoler l'octan voulu.
  Il reste :
  - Regler les cas à l'intérieur du cube
  - Tenir compte de l'indexation et des autres attributs (Le tableau des positions est trié, mais pas le reste)
• 2 -
  On peut maintenant isoler tous les octans traverser pas le rayon.
  Il existe deux façons de construire l'octree :
  - Par itération arbitraire
  - Par nombre de points maximum par octans
  L'affichage en fil de fer des bounding box permet de se rendre compte facilement de la construction de l'octree. ce dernier met un temps à charger ( entre 5 et 10 secondes ), mais le raytracing s'en retrouve nettement amélioré.
• 3 -
  Découverte du planetarium.
  Le raytracing fonctionne au poil.
  Test sur le frustum culling, celui ci fonctionne, mais pour les données actuels, le calcul des parties cachées est plus long que de tout afficher directement.
  Dans l'idée, il faudrait effectuer nombre de tests pour déterminer l'équilibre entre :
  - Taille de l'octree
  - Nombre de test pour le raytracer
  - nombre de parties cachées detectées
  - nombre de drawcalls
• 6 -
  Amélioration du calcul de l'octree, on passe de 3,5s à 2s, ce qui reste beaucoup.
  Pour le raytracing, on passe à 60fps avec le "fait maison" pour 30fps avec celui par defaut.
  A voir : https://vimeo.com/97329154
  recherche sur SIMD, asm.js et webworkers
• 7 -
  Modification de l'algo de frustum culling, mais il reste quelques problèmes (nottament de clipping).
  Reflexion sur les prochaines étapes :
  - Multi-vues
  - Visualisation personnalisé (représenter l'age par couleur par exemple)
• 8 -
  test avec des cubes 512 : La carte graphique ne peut pas tout charger via un seul buffer
  utilisation de webWorker pour la construction de l'octree, résultat satisfaisant, mais il reste un bug pour des données trop grande, la construction plante. On peut encore optimiser les WW, en utilisant des transferable.
  Il peut être interessant de jouer manuellement sur le far de la caméra pour l'occlusion.
  Les données étants très paquées, il faudrai faire un tris : par exemple, si l'on est assez loin, n'affichez qu'un point sur deux. Problème : comment discriminer les bon points ?
  problème lié à la mémoire de l'ordinateur : la construction de l'octree nécessite la construction de nombreux tableaux intermédiaires, trop volumineux : changer l'algo de tri
• 9 -
  Nombreux tests de construction de l'octree :
  Comme c'est le cas en algo de tri, pour avoir un algo rapide il faut prendre beaucoup de mémoire ( donc l'appli crash pour 10M+ de points), et un algo peu gourmand en mémoire met 30s à s'exécuter.
  Solution intéressante : ne calculer que sur les index des points -> passage de 3.6s à 1.4s pour le cube 128.
  Pour 128 fichiers du cube 512 : 12s vs crash
  Pour 50 fichiers du cube 512 : 4.5s vs 13.7s
  Pour les 1024 fichiers : crash :/
• 15 -
  On laisse un peu de côté les recherches sur les performances, pour se concentrer sur l'interface et l'utilisation de l'application.
  Puisque l'on souhaite en faire une bibliothéque ou un plugin rapidement intégrable, le code doit être refactorisé sous forme de classe et d'objets.
  Dans l'optique du multivues, on a donc des classes Views.
  Des classes Data permettent de stoquer les données ( les array buffer ).
  Les Views comportent alors des RenderableData associés aux datas. Cela nous permet d'afficher les même données sur plusieurs vues mais avec des caractéristiques différentes (ex : couleur des points )
• 16 -
  Mise en place d'un element d'interface qui permet d'organiser les upload de fichier de données : Un tableau avec les type de données et les snapshots pour ces données.
  On peut alors charger le snapshot voulu.

Sauvegardes

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

Liens

• ...

Versions testables

Testé sur ...

Documentation

• Rapport de stage: pdf
• Présentation :

Informations/travaux divers

• ...

Travail post stage éventuel

Liste des améliorations à envisager

Bugs connus

• PresentationStage.odp: PresentationStage.odp

• Presentation-2.odp: Presentation-2.odp

• Presentation-2.pdf: Presentation-2.pdf