Travail 1 (T1)

Pour ce travail, vous avez à prendre le code source de SimpleModeller et le modifier. Avant de le modifier, lisez les fichiers README.html et CLASSES.html qui sont inclus avec le code source pour savoir comment fonctionner le logiciel et pour avoir des indications sur l'organisation du code. Compiler, exécuter, et jouer avec les différentes fonctions du logiciel.

Vous avez à choisir 2 changements de la liste de changements "faciles", et 2 changements de la liste de changements "difficiles" que vous allez effectuer sur le code source.

Vos 4 changements doivent être finalisés dans une seule version du code que vous allez démontrer à un chargé de labo, et soumettre par courriel. Vos 4 changements doivent être actifs et démontrables en compilant votre code une seule fois (c.-à-d. sans changer des constantes internes et en recompilant pour chaque changement différent).

Certains des changements proposés demandent de rajouter une fonctionnalité pour permettre de faire x, sans spécifier si x doit étre fait avec la souris, le clavier, un widget, etc. Dans ces cas, vous êtes libres de choisir la méthode d'entrée.

Vous aurez à faire une démonstration de vos changements lors d'un laboratoire indiqué sur l'horaire sur le site web du cours. Pendant ce laboratoire, vous aurez seulement environ 8 minutes pour convaincre le chargé de labo que vos 4 changements sont bons (c.-à-d. le temps de les montrer et de laisser le chargé de labo les essayer), alors assurez vous que les changements fonctionnent bien avant ce labo!

Vous aurez à remettre, par courriel, deux choses: votre code source (c.-à-d. votre version des fichiers .java), et un document d'une à deux pages. Le document doit contenir les informations suivantes: vos noms, vos codes permanents, la liste des 4 changements effectués, et deux sections. La première section doit expliquer comment faire fonctionner votre interface modifiée; cette explication doit être destinée à un utilisateur imaginaire qui connait déjà l'ancienne interface et veut seulement savoir ce qu'il y a de différent avec le fonctionnement de votre interface. Cette première section peut-être écrite dans le même style que le README.html qu'on vous a fournit avec le code source original. La deuxième section du document doit expliquer brièvement comment vous avez effectué vos changements au code source. Cette deuxième section dira des choses comme: "Pour changement F1, j'ai rajouté un menu "View" dans lequel il y a une case à cocher "Wireframe". La sélection de cette case à cocher est traîtée dans SimpleModeller.actionPerformed(), qui lui appelle sceneViewer.setDisplayMode() pour changer la valeur de sceneViewer.displayMode. La variable sceneViewer.displayMode est ensuite utilisée dans Scene.drawScene pour déterminer comment dessiner les boîtes."

Votre chargé de laboratoire va regarder votre code et votre document, et va peut-être avoir à exécuter et essayer votre code interactivement après votre remise. Donc, écrivez votre document pour expliquer rapidement ce qu'il y a de différent dans l'interface (exemple: le bouton de milieu sert maintenant à faire telle fonction ...) et aussi expliquer rapidement où sont les changements intéressants dans le code, sans trop aller en détail. Votre document ne doit pas dépasser deux pages.

Aussi, ne changez pas des parties du code qui ne sont pas nécessaires à changer, car votre chargé de labo regardera une comparaison de la version originale du code avec votre version, et verra tous les changements surlignés. Si vous faites des changements inutiles, par exemple changer les noms de plein de variables ou changer les espaces, ces changements seront surlignés et vont grandement distraire et faire perdre le temps de votre chargé de labo.

Finalement, dû au fait que tous vos changements au code seront surlignés lorsque votre chargé de labo visualise la comparaison, il sera facile pour nous de détecter des cas de plagiat. Alors, ne partagez pas de copies de vos changements entre équipes! Il est permis que deux équipes discutent comment faire les changements, mais ne partagez pas de copies du code. Chaque équipe doit écrire sa propre version des changements choisis. Si, pour effectuer une partie de vos changements (par exemple pour calculer une rotation de points pour D3), vous utilisez une équation ou un algorithme que vous avez trouvé dans un livre ou sur un site web ou que quelqu'un d'autre vous a donné, indiquer clairement dans le code source et dans votre document la source et la nature de cette partie. De telles parties dont vous n'êtes pas l'auteur doivent former au plus une minorité des changements que vous effectuez au code. Évitez soigneusement toute forme de plagiat, ou même la possibilité de donner l'impression d'un plagiat, car il existe plusieurs moyens pour un professeur et ses chargés de cours de détecter des cas de plagiat, et lorsque ces cas arrivent, c'est une situation grave qui sera traîtée sévèrement.

Bonne chance et amusez vous bien!

Liste de changements "faciles"

F1.

Rajoutez un mode de rendu en fil de fer ("wireframe"). Par exemple, vous pouvez rajouter une case à cocher "Draw Wireframe Boxes" dans la partie de gauche de l'interface pour activer ce mode, et dans Scene.drawScene() appelez drawBox( gl, cb.box, false, true, false ); au lieu d'appeler drawBox( gl, cb.box, false, false, false ); quand la case est cochée.

F2.

Dans l'interface actuelle, on voit quelle boîte est sélectionnée, mais on ne voit pas quelle face de la boîte est sélectionnée. La face qui est sélectionnée détermine l'emplacement de la nouvelle boîte créée lorsqu'on on appuie le bouton "Create Box". Alors, afficher un retour visuel quelconque pour montrer quelle face est sélectionnée sur la boîte sélectionnée. Pour savoir quelle face est sélectionnée dans le code, regardez les valeurs de SceneViewer.selectedPoint et SceneViewer.normalAtSelectedPoint.

F3.

Dans l'interface actuelle, lorsqu'on appuie avec le bouton gauche de souris, la boîte en dessous du curseur est sélectionnée avant le relâchement du bouton. Cela permet à un utilisateur de placer le curseur par dessus une boîte qui n'est pas sélectionnée, et d'appuyer le bouton gauche et de glisser la souris pour sélectionner et déplacer la boîte sans avoir à appuyer le bouton une deuxième fois. Par contre, le bouton droit de souris ne fonctionne pas comme cela. Pour changer la couleur d'une boîte avec le menu radial, l'utilisateur doit d'abord sélectionner la boîte avec le bouton gauche, et ensuite utiliser le bouton droit pour accéder au menu radial. Modifiez alors le fonctionnement du bouton droit: lorsque le bouton droit est appuyé (SceneViewer.mousePressed()), sélectionnez la boîte en dessous du curseur, et ensuite afficher le menu radial comme fait l'interface actuelle. Cela vous permettra de sélectionner une boîte et de changer sa couleur en un seul coup. (Question à vous poser: voyez vous un désavantage avec ce changement à l'interface?)

Liste de changements "difficiles"

D1.

Rajoutez une fonctionnalité qui permet de changer la couleur et la valeur alpha de la boîte sélectionnée. (La valeur alpha est stockée dans ColoredBox.a, et elle est utilisée dans le rendu semi-transparent activé avec la case à cocher "Enable Compositing".)

D2.

Rajoutez une fonctionnalité qui permet de sélectionner plusieurs formes en même temps et les déplacer ensemble ou bien les supprimer d'un coup. Notez que la classe ColoredBox a déjà une variable booléenne isSelected qui vous sera probablement utile.

D3.

Rajoutez une fonctionnalité qui permet de faire des rotations de boîtes. (Ceci pourra être plus difficile pour ceux qui ne sont pas familiers avec le OpenGL et/ou à l'aise avec l'algèbre linéaire.)

D4.

Rajoutez une fonctionnalité de undo qui permet de défaire une suite de translations et de redimensionnements à différentes boîtes.

D5.

Rajoutez un widget, par exemple dans la partie gauche de l'interface, qui montre une liste des boîtes dans la scène, et qui permet de sélectionner une boîte soit via la liste ou bien via la vue 3D. Synchroniser l'état de sélection et le retour visuel entre la vue 3D (SceneViewer) et le widget montrant la liste.

D6.

Permettez à l'utilisateur de sauvegarder des vues de caméra et de remettre la caméra dans un état sauvegardé précédemment. C'est semblable à l'idée de pouvoir faire des "bookmarks" de pages web pour revenir à une page qu'on a déjà vue. Permettez à l'utilisateur de sauvegarder au moins 3 vues de caméra. Pour chaque vue sauvegardée, il faut sauvegarder au moins la position, la cible, et l'orientation de la caméra (Camera3D.position, Camera3D.target, Camera3D.up).

D7.

Dans l'interface actuelle, vous pouvez faire afficher des axes montrant le système de coordonnées global avec la case à cocher "Display World Axes". Malheureusement, les axes qui sont montrés sont fixés à l'origine (0,0,0) et ne sont pas visibles si la caméra n'est pas orientée vers l'origine. Alors, lorsque la case à cocher "Display World Axes" est sélectionnée, dessiner plutôt des axes par dessus la scène 3D dans un coin du SceneViewer, d'une manière semblable à l'interface montrée ici. (Vous n'avez pas besoin de dessiner les étiquettes de texte "x", "y", et "z"; vous pouvez simplement dessiner l'axe des x en rouge, l'axe des y en vert, et l'axe des z en bleu.) Les axes devraient toujours apparaître dans le même coin du SceneViewer, quelque soit la position et l'orientation de la caméra. Pour ce faire, vous allez peut-être trouver utile de regarder dans le code de RadialMenuWidget.java pour voir comment le menu radial est dessiné en 2D par dessus la scène 3D, en appelant OpenGL2DInterface.pushProjection() (et certaines routines OpenGL) avant de dessiner, et en appelant OpenGL2DInterface.popProjection() (et d'autres routines) après avoir fini. (Ceci sera peut-être plus difficile pour ceux qui ne sont pas familiers avec le OpenGL, mais votre prof pourra vous donner des indices.)