Projet Infographie
2019-2020

Instructions et calendrier

Le travail est à conduire en C++/OpenGL/GLUT. La plateforme de développement est libre. Le code source produit devra être totalement portable.

Le travail est à réaliser en groupe de 3 étudiants. Un chef de projet sera désigné au sein de chaque groupe.

Le calendrier de travail est le suivant:

• Début du projet, répartition en groupes de travail: Semaine du 9 mars
• Proposition du concept de l'application et répartition des tâches: Semaine du 23 mars
  • Modélisation géométrique
  • Modèle physique et animation
  • Gestion des caméras
  • Lumières, matériaux et textures
  • ...
• Présentation d'un prototype: Semaine du 13 avril
• Présentation finale: Semaine du 11 mai
• Retour final: Jeudi 14 mai à 14h dernier délai

Indications communes à tous les sujets

• Les contrôles implantés seront prioritairement réalisés au clavier. Ils pourront éventuellement être réalisés à la souris.
• Dans une première phase de développement, la modélisation géométrique peut éventuellement être sommaire. Le plaçage de texture est une bonne méthode pour éviter de modéliser géométriquement les objets de façon précise.
• Le projet devra intégrer l'utilisation des fonctionnalités suivantes:
    - modélisation géométrique,
    - gestion des caméras,
    - moteur physique (éventuellement simple),
    - animation,
    - lumière(s),
    - matériels,
    - textures.
• Le projet devra permettre:
    - de switcher entre mode d'affichage fil de fer et mode d'affichage par facettes,
    - d'activer/désactiver l'animation lorsqu'elle est en cours.
• Le projet devra intégrer la possibilité de switcher entre une visualisation à la première personne (avec ou sans avatar) et une visualisation à la troisième personne. On pourra éventuellement utiliser deux fenêtres pour cela.
• Le projet devra être réalisé en programmation orientée objet pour les aspects qui ne relèvent ni d'OpenGL ni de GLUt.

Sujet 1: Une piste de bobsleigh ou de luge

Le sujet consiste à développer un programme permettant d'afficher la course d'un bobsleigh (ou d'une luge) dans une piste de bobsleigh. La modélisation doit être effectuée en 3D. Une "piste" est définie avec lignes droites et tournants, descentes et plats. Un mobile (un bobsleigh ou une luge) se déplace sur cette piste après départ en position haute.
Deux possibilités vous sont offertes pour gérer l'aspect dynamique du déplacement: une simple et une plus complexe.
  - (1) : Le mobile suit étroitement le circuit sans que l'utilisateur du programme puisse le contrôler.
  - (2) : Le mobile est contrôlé par l'utilisateur du programme qui peut ralentir et se déporter à droite ou à gauche dans la gorge formée par le circuit.
Il subit l'accélération due à sa décroissance d'altitude (conversion de l'énergie potentielle en énergie cinétique). En fin de piste, au delà d'une position limite, le mobile stoppe sa course par une décélération linéaire rapide.

Suggestions :
  - L'axe de la piste pourra être modélisé au moyen d'une courbe B-Spline ouverte. La piste elle-même pourra être modélisée par un demi-cylindre courbé d'axe défini par la courbe B-Spline.
  - Un problème particulier devant être géré est la définition de l'axe vertical adopté par le mobile, par l'avatar assis dedans et donc par la "posture" de visualisation de l'avatar. On pourra résoudre ce problème en utilisant une seconde B-Spline 3D dont les "points" ne représentent pas des positions, mais les directions de la verticale du mobile dans le repère de modélisation.

Sujet 2: Un Donkey Kong

Le sujet consiste à développer la partie modélisation géométrique, animation et rendu 3D d'un jeu d'arcade dérivé du jeu Donkey Kong. Le jeu originel est en 2D mais il sera ici réalisé en modélisation 3D.
A minima la modélisation réalisée devra inclure :
  - les rails sur lesquels se déplacent les tonneaux,
  - les échelles utilisées par Mario pour passer d'un rail à un autre,
  - les tonneaux lachés régulièrement par le gorille Donkey Kong,
  - un avatar simplifié pour Mario.
A minima l'animation devra permettre :
  - le déplacement des tonneaux sur les rail,
  - le déplacement de l'avatar de Mario.
On pourra aller plus loin dans l'implantation du jeu par exemple en :
  - détectant les collisions entre Mario et les tonneaux,
  - permettant à Mario de sauter de façon à éviter les tonneaux.

Suivi>Suivi

Les séances de Cours-TD-TP pourront être l'occasion de discutions.

Lors de la séance de TP de la semaine du 13 avril, une présentation d'un prototype exécutable sera réalisée.

Dans tous les cas, le chef de projet sera l'interlocuteur privilégié.

Instructions de retour

Le travail est à retourner sous la forme d'une archive zip (ou d'un autre type) par courrier électronique à l'adresse nicolas.janey@univ-fcomte.fr soit en fichier joint, soit par l'intermédiaire d'un dépot internet dont l'adresse est donnée dans le mail. La dead line est le jeudi 14 mai à 14h.
L'archive zip devra s'extraire dans un répertoire créé automatiquement à cette fin. L'entête du courrier électronique devra contenir précisément la chaîne "ProjetIG20192020" suivie du nom des 3 étudiants.

L'archive zip devra contenir un fichier readme.htm où seront indiquées toutes les informations jugées nécessaires à la bonne compréhension du travail réalisé. Ce fichier inclura un descriptif des techniques employées pour réaliser le travail ainsi que la répartition du travail au sein du groupe de développement. Il inclura aussi la liste des fichiers sources nécessaires à la compilation.lation.

L'archive zip ne devra contenir que les fichiers strictement nécessaires (sources, solution, projet, makefile ou équivalent, ressources, textures, ...) et en tout état de cause occuper moins de 5 Mo. ATTENTION, en cas de retour de l'archive par mail, les fichiers .exe et autres types d'exécutables (.dll, .bat,...) ne devront pas être inclus dans l'archive faute de quoi votre mail sera rejeté par le serveur de mail de l'université.

Un accusé de réception sera envoyé par mail à l'expéditeur du mail et à tous les destinataires annexes lorsque l'archive aura été récupérée et extraite.

Critères d'évaluation

Les critères d'évaluation seront les suivants:

• Respect des directives
• Respect du sujet de projet
• Qualité du fichier readme.htm
• Qualité et facilité d'exploitation des codes sources
• Qualité de l'affichage
• Qualité de l'animation
• Qualité de la programmation GLUt
• Qualité de la programmation OpenGL
• Diversité des fonctionnalités OpenGL utilisées
  • Caméras
  • Lumières
  • Matériaux
  • Textures
  • ...

La liste ci-dessus n'est pas exhaustive et n'est pas triée par ordre d'importance des critères.

Questions, remarques, erreurs
nicolas.janey@univ-fcomte.fr