Nouveautés Archives

Le Logiciel de Rendu/Modélisation Minds Eye

Avant-Propos

MindsEye est actuellement au début de son développement. Beaucoup de travail est effectué au-dessous de l'interface. Ce qui veut dire que si vous l'essayez maintenant, les parties fonctionnelles peuvent varier de jour en jour. Nous sommes persuadés qu'un bon design d'interface est important avant de donner aux utilisateurs de bons jouets pour s'amuser.

Qu'est ce que Minds Eye?

De nos jours le marché de la modélisation et du rendu d'images 3D est dominé par de couteux logiciels commerciaux. MindsEye est (ou sera) la réponse freeware (GPL) qui pourra concurrencer ces versions commerciales. Prenant le meilleur de ces deux mondes tout en ajoutant de nouvelles techniques innovatives, MindsEye essaiera d'être une grande plateforme pour tous les besoins en graphisme 3D.

Histoire

Il y a à peu près 2 ans, lorsque Linux n'était encore qu'un environnement utilisé par les hackers, surgit l'idée de commencer à travailler sur un programme de rendu/modélisation/animation pour Linux. Inspiré par ce qui avait été fait par l'équipe de Gimp, nous nous mîmes au travail pour voir s'il était possible de coder un tel monstre. Pendant près d'un an nous avons joué avec quelques idées de design. Cela a commencé très mal au début. Nous avions posté des avis dans des groupes de discussion pour voir si des personnes étaient intéressées pour nous rejoindre. Nous avons eu beaucoup de réponses et il a semblé qu'il n'y aurait aucun problème à démarrer ce projet. Son nom était Free-D. Un nom qui fut changé plus tard car il pouvait causer la confusion avec le Free3D library project. Le projet prenait forme très lentement. Tout au long du chemin il y'avait toute sorte de pièges qui n'avait rien à voir avec le projet. Par exemple, des gens avaient une idée spécifique de ce qu'ils voulaient voir implémenté. Donc sur notre liste de diffusion, nous voyions fréquemment des batailles d'arguments sur des aspects du design. En fait produire du code nous prit plus d'un an.

Design

La partie la plus intéressante de MindsEye est son design. Tous les éléments sont modulaires, du plus petit jusqu'au plus gros tel le modeleur. Au coeur du programme, il y'a ce que nous appelons le noyau de MindsEye. C'est un morceau de logiciel qui est incapable par lui-même de faire n'importe quel travail graphique. Au lieu de cela, il gère tous les modules et plugins. Vous pourriez l'appeler un gros programme de gestion de ressources. C'est aussi dans celui-ci qu'est gardée toute la structure de données. Il y'a une nette différence entre un module et un plugin dans MindsEye. Un module est un code dynamique dont le noyau est conscient, il sera chargé puis enlevé par le noyau. Lorsque nous disons "est conscient", cela veut dire que le noyau connait quelque chose des modules. Par exemple un module de réseau est un passage qui connecte plusieurs noyaux. Le module de réseau peut être vu comme un dummy module (NDT: module "mannequin") qui remplace un des autres modules. Nous avons d'ores et déjà défini une panoplie de modules basiques qui sont:

Réseau

Editeur de modélisation

Editeur d'animation

Editeur de Materiaux

Module d'Entrées/Sorties (IO)

Alors, à quoi ressemble actuellement la fenêtre d'entrée du programme?
A ceci:

L'un de nos modules est celui d'animation. C'est principalement un éditeur 3D spécialisé dans l'animation. Il utilise notre gestionnaire de vues qui à son tour utilise notre code correspondant à une vue générique. Tout notre code est modulaire et peut être utilisé dans d'autres parties du programme. Par exemple, vous pouvez voir plus bas dans la capture d'écran une version grossière de notre animateur, avec quatre vues.

Pour notre sortie 3D nous utilisons OpenGL. Les makefiles supposent que vous utilisez MesaGL si vous travaillez sous Linux. Le kit d'outils GUI que vous voyez en action est celui de la librairie QT disponible chez
TrollTech ( http://www.troll.no ). Nous avons choisi cette bibliothèque d'outils car elle disposait des éléments dont nous avions besoin et qu'aucune autre ne procure (en tout cas pas sous license GPL). Lorsque nous avons commencé, Gtk n'en était pas à un point où nous pouvions avoir confiance en lui. Donc nous avions des souhaits particuliers pour le GUI que Gtk était incapable de réaliser et Qt vint.

Tout comme les autres logiciels commerciaux, MindsEye comportera un éditeur de matériaux. Comme toutes les autres parties, le code de ce module est basé sur d'autres codes. Par exemple les fenêtres de vue qui affichent les matériaux seront les mêmes pour les boîtes de dialogue des sources de lumière. Elles sont dérivées du code de base qui affiche une sphère OpenGL avec plusieurs propriétés. Les fenêtres de vue sauront gérer toutes les propriétés. L'éditeur de matériaux aura donc seulement à faire la gestion de tous les matériaux et des données disponibles. La philosophie dans toutes les parties du programmes est:
diviser toutes les parties dans leur forme la plus élémentaire. C'est à dire suivre le chemin qu'Unix a pris pour devenir ce qu'il est maintenant.

Pour la sortie du rendu nous utilisons... tout ce qui peut être possible de trouver. Plusieurs moteurs vont être utilisés de façon interne comme le moteur SIPP, d'autres le seront comme des programmes externes. Cela dépendra de la nature et complexité du système de rendu ciblé. Si le moteur de la sortie est interne, alors il sera simplement chargé comme plugin. Le module de rendu saura comment le gérer et lui passera une structure de données et un tampon pour stocker l'image rendu avec quelques paramètres. A l'heure actuelle nous nous tournons vers SIPP, POVRay et Renderman comme moteurs de rendu mais des développeurs peuvent lui brancher ce qu'ils veulent. Comme toutes les autres choses dans MindsEye, les interfaces auront une API bien définie.

Technologies Futures

MindsEye se veut un programme très solide du point de vue architecture logicielle. Des tas de nouvelles technologies seront implémentées et le programme pourra très bien fonctionner comme un banc de test pour les nouvelles techniques de rendu et modélisation. L'une des fonctionnalités que nous avons prévu d'intégrer est:

le RCS pour les mondes

Il y a des chances pour que, dans un futur proche, les scènes deviennent de plus en plus grosses et plus complexes. Gérer ces énormes mondes est une tâche en soi-même. MindsEye veut faciliter une manière de travailler sur une scène avec plus d'un modeleur en même temps. Etre capable de faire cela économise du temps d'intégration et diminue le temps total de rendu. Une façon de le faire est d'implémenter une sorte de RCS (Revision Control System) pour les scènes/mondes. Par exemple, un modeleur peut travailler sur un petit ensemble de données d'une énorme scène. Ces données seront verrouillées pour ce modeleur. d'autres personnes peuvent travailler sur d'autres parties sans déranger les modèles qui seront verrouillés par d'autres modeleurs.

Programmation façon LEGO®

Chaque noyau MindsEye n'est rien de plus qu'une tâche et un gestionnaire de ressources. Si vous voulez faire tourner n'importe lesquels des modules vous avez besoin du noyau. Un avantage d'avoir un système basé sur un noyau est que l'ensemble fonctionne plus ou moins comme un jeu de LEGO ©. Comment ce concept fonctionne-t-il dans la vie réelle? Et bien supposons que vous ayez une compagnie d'animation nommé Paxir. Vous êtes en train de travailler sur un nouveau film et vous avez décidé d'utiliser MindsEye comme plateforme principale de développement. La compagnie a l'habitude de travailler sur une kyrielle de modeleurs avec un poste de rendu principal. Mettre au point un tel système avec MindsEye serait relativement aisé. Sur chaque machine, peu importe sa plateforme ou son but, un système minimal de MindsEye serait installé. Suivant le rôle de la machine, des modules sont ajoutés. Un groupe de modeleurs devrait possèder le noyau et un module de modélisation avec un module de rendu et un plugin de pré-visualisation. Le poste de rendu principal d'autre part aurait le noyau et le module de réseau avec le plugin de rendu final. Chaque noyau comprendrait son rôle et agirait de concert avec les autres.

Rendu Transparent sur Réseau

Comme nous l'avons expliqué dans la dernière section, le rendu en réseau devrait être beaucoup plus flexible avec MindsEye. Ce qui ressort de tout ça, c'est une chaine de noyaux MindsEye qui se chargent chacun d'une part du rendu de l'animation. En effet chaque noyau est responsable de sa tâche à travers le module de rendu et le plugin de rendu effectue en fait le travail. Au travers du design entier et du travail d'ingénierie du programme, le décomposition modulaire est gardée à l'esprit. Beaucoup d'idées et de concepts sont gardés à l'esprit pendant la programmation de ce projet. La capacité à fonctionner en réseau n'en est qu'une petite partie mais, comme vous avez pu le voir, elle est au coeur de ce que veut représenter MindsEye.

Usage

Pour le moment MindsEye est un programme très intéressant du point de vue des développeurs. Pour le grand public il n'est pas très utile. Nous sommes en train de travailler dur pour que la base du programme soit très bien faite. Lorsque cela sera fait, il y a des chances pour que les fonctionnalités arrivent à un rythme accéléré. Vous pouvez voir une capture d'écran ci-dessous de l'actuel setup du modeleur. C'est une vue de MindsEye-0.5.19 sur un bureau Enlightment. Dans le modeleur vous pouvez voir que la scène chargée s'appelle rings5.nff. MindsEye a la possibilité de charger de multiples scènes. Bien que peu de formats de fichiers soient supportés pour le moment, le code qui dirige le chargement et la sauvegarde est très flexible. Des protocoles sont en train d'être conçus pour ajouter dynamiquement des types de fichiers. Chaque type est chargé par son plugin approprié. MindsEye sera capable de scanner les plugins actifs. Cela veut dire que des composants peuvent être ajoutés ou enlevés à la volée.