2004-2008 Operating User Interaction System (OUIS)
Moteur IHM OpenGL, GLUT, STL, C, C++, Transplateformes (Windows, Linux, MacOS9)

J'ai développé une demo de ce que j'appel un OUIS
(Operating User Interface System), qui met en place les IHM de base actuelle (écran,clavier,souris) dans des objets très légers, facile et rapide à utiliser. Ce développement est basé sur de précédentes recherches visant à distinguer les objets et modes d'interaction graphique de base, ce qui m'a permis de produire une librairie d'objets IHM en OpenGL.

Le but de cet OUIS est de pouvoir fonctionner sous Linux, sous Unix et sous Windows (m’enfin, sous tout système compatible avec OpenGL et les langage C/c++). L’OUIS doit aussi permettre de développer en quelques heures, puis en quelques minutes des IHM plus ou moins complexes, permettant ainsi au développeur de se concentrer sur l’algorithme qu’il doit développer et non plus sur l’IHM pour la mettre en place.
Un autre collègue s'occupe plus particulièrement d'intégrer cet OUIS à une débian minimale, avec mon OUIS comme unique moyen de vizu.

Pourquoi développé un OUIS : développé une UI libre et indépendante du système sur lequel il tourne, tout en ayant facilement accès à des fonctionnalités avancés de rendu graphique.
plateforme visuel OpenGL : dessin 2D,3D ; effet graphique ; light, texture, fog, blending, alphatest scissors, etc ..
Le choix d'OpenGL permet
1 ) d'avoir un OUIS multi OS. (Unix, Linux,Windows)
2 ) de pouvoir utiliser tout le travail de synthèse graphique et d'optimisation scientifique de la librairie graphique la plus développée et utilisée au monde. Ainsi il n’y a nulle besoin de réinventer la roue et cela permet une compatibilité avec l’existant.

Les deux langages de développement utilisés sont le C et le C++. Utilisation d’une version C des librairies OpenGL. OpenGL est cross plateforme.

La méthode utilisée pour interagir avec l’interface graphique est très simple : On affiche plusieurs passe de rendu OpenGL.
Durant la première passe, on dessine tous les objets sélectionnables avec une couleur unique et identifié pour chaque objet. La couleur du pixel se trouvant sous la souris donne alors l’identifiant couleur de l’objet sélectionné.
Durant la deuxième passe, tous les objets gérant de la transparence, sont redessinés en noir, pour écraser la première passe de rendu.
Enfin, durant la dernière passe, tous les objets graphiques (sélectionnable ou pas) sont affichés.

Bénéfice : Grâce à cette méthode de sélection, on peut :
potentiellement sélectionner jusqu’à 16.7 millions d'objets différents et tous les distinguer les uns des autres. Ce qui évite les problèmes d’identification par coordonnées souris au-dessus d’un objet, ce qui est le mode utilisé dans presque toutes les UI).
Avoir un accès direct à l’objet sélectionné. C’est cet objet sélectionné et pas un autre, qui reçoit les événements/messages clavier/souris. Ceci va grandement simplifier notre OUIS, et la gestion des Interactions entre l’utilisateur et l’objet sélectionné.
Pouvoir selectionner n'importe qu'elle forme d'objet, ou partie d'objet même en animation de façon native
Limitation
la couleur de rendu des objets lors de la première phase doit impérativement être la même que celle de leur identifiant unique. En effet, selon les modes et les types d’affichages, la couleur de rendu peut légèrement différé de la couleur spécifiée pour l’ objet. On ne peut plus alors correctement retrouver l’identifiant d’un objet par sa couleur, ce qui bloque notre méthode de sélection graphique et tous notre OUIS. C’est pour cela que le rendu graphique doit se faire en 24bits ou en 32 bits. Cependant, aujourd’hui la plupart des ordinateurs gèrent des affichages en 24 ou 32 bits et nôtre limitation s’applique plus à de vieux ordinateurs, qu’à ceux actuels.
Pourquoi faire un autre mode de sélection alors qu’OpenGL en met un en place ? Parce que celui-ci est trop limité au niveau du nombre d’objets sélectionnables et que l’on veut faire le plus simple possible.

Dans ce document,le mot objet a autant le sens traditionnelle d'un objet dans la réalité (table,crayon,verre,...), qu'un objet en POO. Dans le reste du texte, on pourra faire le parallèle entre :

Objet Graphique	Objet Réel
Déplacer la souris par-dessus ou sur un objet	Déplacer son bras et sa main par-dessus ou sur un objet.
Sélectionner, interagir avec un objet grâce aux boutons/touches de la souris et du clavier	Prendre, bouger, modifier un objet avec la main et les doigts.

Trois classes d'interactions principales : ces trois classes sont appliquées au graphisme dans cet OUIS, mais peuvent s'appliquer à d'autres canaux d'interactions.

1. Objet sans aucune interaction directe, ou indirecte : Objet (graphique) simple. Un objet qui a la propriété de pouvoir s'afficher, de pouvoir être vu, mais avec lequel aucune interaction directe ou indirecte n'existe. Exemple : fond d’écran, image, poster, tapisserie.
2. Objet avec interaction indirecte : objet (graphique) qui a la propriété d'être sélectionnable par la souris (la main) quand celle-ci passe au dessus de l'objet. Cependant, aucune interaction directe n'existe avec cet objet, mais une interaction indirecte, c'est à dire que l'objet sélectionné est passé à un autre objet, qui lui, va permettre d’interagir avec l'objet sélectionné. Typiquement c'est ce qui est utilisé lorsqu'il y a de multiples objets du même type. (ex : avatar, nombre de corps 65, nombre d'articulation 66).
3. Objet avec interaction directe : objet (graphique) sélectionnable par la souris (la main) quand celle-ci passe au-dessus de l'objet et qui permet une interaction souris, clavier (main,doigt) avec l'utilisateur (cf notion d'engagement d'interaction). L'utilisateur peut alors engager une interaction avec l'Interface ce qui correspond à prendre, déplacer, modifier un objet dans la réalité.

A partir de ces trois classes d'interaction, on peut développer toutes les interfaces WIMP existantes.

Développement : Une premiére étape de développement fut de développer l'OUIS sous windows, puis de faire une version totalement transplateforme, ce qui ne fut pas simple, fut ensuite produite et testé avec succés sous Débian et MacOS9.

Voici, ci-aprés les différents développements de l'OUIS et des démos tournant dessous. Il ya beaucoup de chose et le site est encore en cours d'édition, mais cela donne une bonne idée de ce long projet. En train de réfléchir à faire une 3iéme version, plus aboutie et encore plus simple.

Ces differentes copies d'écran montrent l'OUIS tournant sous Zindows, Débian et Mac.
On peut y voir une visualisation du systéme solaire, un éditeur d'avatar, une loupe, une application de codage OpenGL at runtime, et d'autres choses...
Les images sont grandes, donc faire attention.

Ce fut en faite la premiére démo que je voulais faire et qui m'a poussé à commencer à faire l'OUIS, mais sans avoir le concept de moteur IHM transplateforme. Mon but était de représenter et visualiser le systéme solaire et les lunes majeurs, en utilisant les données scientifiques tirées de mon glossaire d'astronomie, pour se faire une idée, une vision de la taille des planétes entre elles, comparer avec le soleil, voir les périodes rotations entre les planétes téluriques et gazeuses, et puis surtout, visualiser le gradient d'espace temps, pour visualiser si il n'y a pas des sortes de puits d'espace temps, permettant à des objets dans le systéme d'en sortir, ou bien l'inverse.

Ce fut la deuxiéme démo développée sous l'OUIS. J'avais auparavant au cours de mon stage de DEA, développer un modéle simple d'ECA, basé sur des corps et des articulations. Je voulais allez plus loin et faire un éditeur directe et rapide. Il suffit que l'utilisateur passe au dessus d'un corps ou d"une articulation pour que les données de celui-ci ou de celle-ci apparaissent dans le dialogue associé, montrant son nom et les différents paramétres du corps et de l'articulation.
Bien sur on peut modifier l'orientation et la position de l'ECA, ainsi que choisir si l'on veut uniquement visualiser la tête, le bras droit ou gauche ou les deux, les deux main,s ou une seule, les jambes, ou bien l'avatar en entier.

Troisiéme démo développée sous l'OUIS, mettant en jeux uniquement un interface au clavier, et permettant de valider l'API mise en place pour gérer le clavier sous GLUT. C'est aussi faire un vieux jeux PONG, avec un rendu 2D, ressemblant à celui d'origine, mais permettant de pouvoir aussi avoir un rendu 3D, et texturé, avec possiblité de pouvoir modifier la taille du terrain, de la balle, des raquettes, l'orientation du terrain, sa distance ...

Quatriéme démo développée sous l'OUIS, permettant de faire des effets de zoom. Ce n'est en faite qu'une image du rendu prise et plaqué sur une surface, sphére, cone ou disque plat. On peut changer la taille de l'image , l'orientation du plaquage et ainsi obtenir des effets intéressants.
Remarque, cette loupe permet de pouvoir intéragir avec les objets qui sont grossis et permettrent ainsi d'intéragir à travers le "verre" de la loupe.

Demo LG5, permettant de faire du codage OpenGL au sein de l'OUIS.
L'utilisateur à une liste de fonction OpenGL (82 interfacés), qu'il drag'n drop simplement dans l'un des deux dialogues d'exécution de code.
L'utilisateur peut alors intéragir directement avec les lignes de codes exécutées, pour modifier la rotation, la couleur, ou tous autres paramétres des fonctions OpenGL.
Le code peut être visualisé de plusieurs maniéres, style interfaces simple, mixte, interface et texte, et une version C++. Recherche sur la représentation à différents niveaux de complexités des mêmes informations en fonction du niveau de l'utilisateur.
Dans l'exemple ci contre on peut voir un petit bout de code montrant un théiere.
Remarque : le code n'est pas interprété comme c'était le cas dans les éditeurs 3D que j'avais fait, mais une autre méthode est mise en place. Mais cela c'est une autre histoire...

Démo du jeux de la vie, avec la particularité de pouvoir modifier at runtime les differentes lois utilisées dans ce jeux. Permettant d'explorer celles-ci et de recherche d'autres loies de stabilité.
Possibilité de zoomer, de choisir la taille de l'espace de vie, du nombre de cellules vivantes au début, et de sauver, charger, un état du jeux à un moment donné.

Démo de BOIDS, simulant le déplacement de groupes d'animaux selon des régles établies. Possibilités de pouvoir paramétrer toutes les régles. Difficultés de trouver des régles stables pour telles ou telles type d'animaux.
Possibilité d'avoir des obstacles.

Démo d'effet de textures transparentes dupliquées n fois. Effet de brouillard, de nuage, et autres effets intéressants. Possibilité de choisir parmis une 60 de textures différentes.

SkyBox : démo permettant de simuler d'être dans un terrain 3D, à partir de 6 images plaquées sur une boite, d'où le nom.

Un simulateur d'attraction type gravité, simulant la matiére noire aussi (gravité négative).

Une petite démo de générateur de particule, permettant de simuler un jet d'eau, du feu, un réacteur.

Une petite démo, type vers de terre, seule la tête bouge aléatoirement, et tous les autres points suivent à une distance fixe : conclusion, on voit qu'au bout d'un moment le ver semble toujours allez ici et là, et que l'aléoitire ne l'est pas trop : random.