le résumé est mal dit (le but de l'appli). METTRE DES IMAGES , s'appuyer sur les images. (schéma, capture d'écran, dessin) Respecter le droit d'image -> NON, c'est la propriété intellectuelle
au lieu du chemin, accentuer sur le choix et argumenter. Ne pas structurer fonctionnalités par fonctionnalités mais par: On a un but (marquer le cahier des charges, les contraintes explicitement, avant l'état de l'art) et pour résoudre on a fait des choix (question de temps?, effectif? cahier des charge favorisant tel ou tel technique)
Vraiment argumenter, trop verbeux, on parle pour rien dire (on peut lister aussi)
Le plan est à revoir: on ne commence pas par les remerciements, le résumé est trop petit et à revoir pour qu'il soit intéressant. Contexte de l'application (3D etc) Brève mention de projet de 3ème année
Présentation/explication du plan à la fin de l'introduction.
8 pages sans les interlignes doubles.
Etat de l'art trop court, pas assez argumenté, argumenter sur le choix, reprendre ce qu'il y avait dans la présentation anglais.
UCLA mesh creator: écrire qu'on a trouvé cet outil qui fait le café et porquoi il facilite.
L'organisation du travail: faire une partie architecture (schéma?) (on a séparé le dessin on plusieurs sous-parties) et une partie organisation pure (l'organisation est à la fin, il est possible de mettre nos noms ici)
IHM: pas besoin de la version d'unity, dire simplement qu'on utilise les "UI" qui est un outil etc...
dessin: pas de redimensionnement car ...
TOTHINK: Présenter à une personne lambda. Qu'est-ce qui fait que ça va être simple pour l'utilisateur? Quels sont les choix qui font que notre application est orienté tout public? (palette de couleur,...)
Il faut retrouver les idées dans les diapos de décembre.
extrusion: ne pas marquer "édition", juste dire que l'appli est faite pour être utilisée comme appli. Trop négatif sur le UCLA extrusion, des sous-tâches d'extrusion qui expliquent le choix de UCLA. utiliser les images pour l'extrusion ON A GAGNE DU TEMPS.
envoi: l'envoi d'un fichier est censé être simple donc petite partie (on se base sur une bibliothèque tout faite) peut-être que si c'est pas fini, on peut dire qu'on sait ce qu'il faut faire, tout est prêt et il reste à le faire mais pas le temps.
sauvegarde: on a pas eu le temps, mais l'archi est faite pour, et dire comment il faudrait le faire.
objectif: à fusionner avec organisation du travail, si on devait le refaire?
conclusion: c'est ce qu'il y a dans objectif et surtout ce sont les points forts, qu'est-ce qu'on a réussi à faire. ne pas dire de passer moins de temps sur l'état de l'art, mais dire que en utilsant unity en parrallèle on a trouvé des solutions
on peut mettre dans la doc technique: les menus de sauvegarde sont en caché
Biblio: référence bibliographique (vers le site d'unity etc)
pour le tracé des lignes: utiliser la fonction de distance. f(x,y)=|ax+by+c | < e/2
(a,b) est une normale. c'est une équation cartésienne
article wikipédia : http://fr.wikipedia.org/wiki/%C3%89quation_de_droite