Sortie de Blender 2.5 Alpha 0

Blender, la suite tout en un de création est sortie en version 2.5 [1], qui succède en toute logique à la version 2.49.

Blender est un outil libre dédié à l'infographie. Il embarque de puissants outils de modélisation, de gestion de textures et de matériaux, d'animation et de rendu.
Cette version 2.5 se veut une refonte complète de l'interface et de l'interne du code, mais apporte aussi son lot de nouveautés. Cependant, celle-ci est considérée comme une version de transition, d'où le "alpha" dans le numéro de version.
Sachez donc que vous pouvez vous retrouver face à des fonctionnalités manquantes ou buguées par rapport à la version 2.49. Toutefois, vous êtes vivement encouragés à tester et à rapporter tous les bugs que vous y trouverez.

La suite de cette article est plus ou moins une traduction directe des notes de version agrémentée de nombreux commentaires.

À vos mixeurs ! Nouveautés

• Interface utilisateur
  La plus grande critique de Blender concernait son interface. En effet, ce qui frappe toujours dans Blender, c'est son interface. Quand on le compare à ses concurrents directs (Comme Maya ou 3DsMax), l'interface de Blender semble légère et déroutante. Où sont les boutons ? Comment réaliser telle ou telle action ?
  Blender se veut un logiciel destiné à l'élite qui saura prendre le temps de se former, ainsi la plupart des fonctionnalités ne sont disponibles qu'au moyen de raccourcis clavier, souvent mal/non documentés.
  
  Cependant, cette version 2.5 chamboule un peu tout et ces problèmes devraient disparaître, on l'espère, rapidement. L'interface a été revue et corrigée. Outre sa plus grande logique dans l'agencement des boutons, et le fait que toutes les fonctionnalités soient disponibles par le biais de menus, de nombreuses améliorations visant à simplifier le travail sont présentes :
  
  • Blender gère maintenant l'utilisation de plusieurs fenêtres, facilitant le travail sur de multiples écrans. La philosophie de Blender ne change pas et il reste déconseillé d'ouvrir plusieurs fenêtres sur le même écran.
    
  • La gestion des zones de travail est maintenant totalement dynamique et l'affichage se dimensionne à la volée.
    
  • Le gestionnaire de fichier a subit un petit remodelage et devient utilisable.
    
  • L'intégralité de l'interface graphique et des menus sont dirigés par des scripts Python, ce qui rend l'interface encore plus malléable et peut permettre facilement le développement d'interfaces spécialisées. Blender est utilisé tous les jours dans le monde pour des besoins spécifiques d'écoles ou de laboratoire, et cette souplesse transforme Blender en "framework d'expérimentations 3D" intéressant. Un des apports sympathiques de ce système est que tout clic sur un élément de l'interface peut permettre d'obtenir le nom Python de la propriété (pratique pour les développeurs de scripts) ou un accès direct à la documentation.
    
  • L'intégralité des raccourcis claviers est modifiable à la volée et n'importe quelle combinaison d'évènements peut être associée à une action. Jusqu'alors, les raccourcis claviers n'étaient pas modifiables facilement, donnant lieu à beaucoup de frustration pour certains utilisateurs. La philosophie de Blender étant "une main sur le clavier, une main sur la souris/palette", elle devenait difficilement applicable lors de l'utilisation de dispositions clavier particulières. Maintenant, les utilisateurs de bépo vont pouvoir utiliser Blender ;)
    
  • L'interface est devenue non bloquante. Jusqu'alors, certaines actions, comme le rendu d'une scène et le calcul d'une simulation physique, gelaient l'interface qui devenait non réactive et ne se rafraîchissait plus. Très frustrant, d'autant plus qu'un retour sous Blender lors d'un rendu après un changement de bureau nous donnait une fenêtre grise où seuls les nouveaux éléments calculés du rendu apparaissaient, Impossible donc de connaître l'état de son rendu. C'est chose corrigée et il est donc possible de continuer à travailler alors qu'un rendu est en cours ou d'interagir en temps réel avec les éléments de simulation.
    
  • La plupart des outils ont changé de mode de fonctionnement. Avant, il fallait paramétrer un outil puis l'appliquer avant de voir le résultat, donnant souvent lieu à de nombreux cycles d'essai-erreur-suppression avant de trouver le bon paramétrage. Maintenant, les réglages de tous les outils peuvent se faire avec une vue de l'impact de ceux-ci directement dans la fenêtre.
    
  • De nombreuses améliorations ont été réalisées sur les éléments d'interfaces. Ainsi le sélecteur de couleur semble plus complet et intuitif, les listes (de matériaux, d'objets) permettent une recherche à la volée. L'interface graphique s'est aussi munie d'une fonction de recherche globale pouvant rechercher parmi tous les objets du fichier en cours ou parmi toutes les fonctionnalités. En cas de doute sur un raccourci clavier, il suffit maintenant de taper quelques mots clé dans ce champ pour obtenir immédiatement le nom de la fonction et son raccourci associé. Cela ressemble beaucoup aux lanceurs de bureau comme Deskbar, Katapult, QuickSilver…
    
  • Les modificateurs et contraintes ont leur onglet dédié. Cela permet de ne plus avoir ces dizaines de modificateurs rendant illisible l'interface.
    
  • Le nouvel écran de démarrage (extrait du projet Durian) présent la liste des fichiers dernièrement utilisés, ainsi que quelques liens utiles.
    
  • Blender se voit doté d'une console python avec auto-complétion. C'est dans celle-ci que les messages des scripts s'affichent maintenant et non plus dans le terminal ayant servi à lancer Blender (pour peu qu'il existe ;))
    
  • Le support des VBO ou VertexArray. (NDR: l'option est arrivée dans l'interface, mais je n'arrive pas à savoir si elle est active car chez moi elle ne change rien). Jusqu'à présent, Blender utilisait le mode direct d'OpenGL. Pour chaque point, arête, surface, plusieurs appels au pilote Opengl étaient faits et cela pouvait nuire aux performances sur des maillages de plusieurs millions de polygones. OpenGL propose un moyen de spécifier un tableau de coordonnées et de dessiner des primitives en fonction. Ainsi le nombre d'appels au pilote peut être fortement réduit (un pour initialiser le tableau et un pour lancer le dessin). De plus, ces tableaux (VertexArray) peuvent être chargés dans la mémoire vive de la carte graphique (VBO) pour augmenter les performances en supprimant le temps de dialogue entre la mémoire vive principale et la carte graphique. Cette option devrait donc nettement améliorer la réactivité de l'interface dans le cas de maillages denses.
    
  • Une chose est à regretter, c'est que l'interface suppose des écrans de plus en plus grands. Par exemple la barre d'information principale de Blender ne rentre pas entièrement sur une largeur de 1024 pixels. En espérant que cela soit corrigé bientôt.
  
  
  
• Refonte de l'architecture interne
  L'architecture interne a été totalement réécrite. Pour l'utilisateur final cela ne change pas grand chose, mais cela risque de fortement simplifier le travail des développeurs ou des éditeurs de scripts. En pratique, l'interface Python est maintenant dynamiquement générée. Avant elle était maintenue en parallèle de la version C, pouvant provoquer beaucoup de frustration du fait des fonctionnalités bugées, manquantes ou incohérentes. Cela permet maintenant de fournir au développeur de scripts les mêmes fonctionnalités qu'aux développeurs du cœur de Blender.
  
  L'on doit cette fonctionnalité aux modifications du format interne de Blender. Chaque donnée ou fonction est documentée. Ainsi le binding python se génère suivant cette documentation, l'interface graphique affiche des composants d'interface différents en fonction du type de l'objet (sélection de couleur, curseur, champs texte…).
  
  
• Animation
  Le système d'animation à été entièrement revu. Jusqu'à présent, seules certaines propriétés (position, rotation, échelle) des objets pouvaient être animées. Maintenant toutes les propriétés le sont, permettant ainsi de nombreuses créations impossibles jusqu'à maintenant.
  
  • Les courbes d'animations peuvent être partagées entre plusieurs objets, là où il fallait avant recopier les modifications entre tous les objets.
    
  • Comme les objets, les courbes d'animation peuvent aussi recevoir leur lot de modificateurs. Ainsi il est possible d'ajouter une fonction mathématique ou du bruit à une courbe.
    
  • Entre autres petites modifications, comme la capacité d'appliquer des effets hooks (déformant une géométrie comme si elle était attirée par un crochet) aux os des armatures, il est maintenant possible de forcer les os à suivre les déformations d'une courbe permettant ainsi d'obtenir une animation souple d'objets long et fin (comme une tentacule de pieuvre ou une queue d'animal).
    
  • Il est possible d'ajouter des clés d'animation pour plusieurs propriétés en même temps. L'animation d'une propriété suit un principe très simple. À un instant t celle-ci prend une valeur différentes de l'instant t', les valeurs entre t et t' étant interpolées. Pour modifier ces valeurs t et t', il faut placer la barre de temps à l'instant t, ajouter une clé pour la propriété en question, modifier la valeur et recommencer à l'instant t'. Lorsque l'on fait cela dans la vue 3D, il est tout à fait possible de modifier plusieurs propriétés en même temps, mais il faut toujours ajouter chaque clé une à une, ce qui peut devenir une perte de temps importante dans le cas de lourdes animations. La création d'un ensembles de clés comprenant plusieurs noms de clé peut permettre l'ajout simultané de toutes ces clés.
    
  • Pour finir, chaque propriété, en plus d'être transformable par une courbe, peut l'être par le biais d'un pilote (fonction d'un autre paramètre). Ainsi il est par exemple possible de lier entre eux le niveau de subdivision de plusieurs objets, simplifiant la modification.
  
  
  À ces nouvelles fonctions s'ajoutent une refonte complète de l'éditeur de courbe qui se veut plus simple et plus fonctionnel. (NDR: ne pratiquant pas l'animation, je suis pour l'instant incapable de juger de ces améliorations)
  
  
• Simulation
  Le système de particules a été revu en profondeur et se voit doté d'un simulateur de fumée.
  
  
• Rendu
  Plusieurs améliorations du coté du rendu fort sympathiques. En premier lieu, de nombreuses optimisations permettant au lanceur de rayon de s'exécuter entre 2 et 10 fois plus rapidement. Derrière cela une méthodologie très simple, la segmentation de l'espace.
  
  La complexité d'un lanceur de rayons est proportionnelle au nombre de pixels de l'image (le nombre de rayons à lancer) et au nombre d'objets dans l'image. Pour chaque rayon, il faut trouver l'intersection de ce rayon avec les objets de la scène, ce qui oblige à tester pour chaque objet si celui-ci est sur le trajet du rayon et à prendre le plus proche.
  
  De plus, lorsque les rayons rebondissent, il faut de nouveau effectuer ce test d'intersection. Nous avons donc, pour une image de P pixels et de O objets avec R rebonds, un nombre de tests d'intersections égal à P*O*R. Nous ne pouvons pas diminuer le nombre de pixels de l'image ainsi que le nombre de rebonds, donc la technique d'optimisation cherche à diminuer le nombre de tests d'intersection par objet.
  
  Une technique très simple consiste à placer les objets dans des boîtes englobantes. En séparant l'espace en deux boîtes contenant chacune la moitié des objets et en faisant cela récursivement pour chaque boîte, l'on crée ainsi une hiérarchie de boîtes. Ainsi le test d'intersection devient plus simple, il suffit de tester si cela intersecte avec les deux boîtes englobantes. Si cela n'intersecte pas les boîtes, alors cela veut dire que le rayon n'intersecte pas ses enfants. Ainsi l'on peut facilement supprimer des tests d'intersection.
  
  La méthode mise en place dans Blender consiste en une variation de ce concept. Cette méthode remplace l'ancien octree, technologie similaire mais moins souple et performante.
  
  D'autres optimisations ont été mises en place dans le lanceur de rayon, comme par exemple l'instanciation, qui permet au moteur de rendu de ne pas charger en mémoire des copies d'objets lorsque ceux-ci sont présents plusieurs fois sur la même scène (par le biais du modificateur duplivert par exemple).
  
  
  Ensuite, le moteur de rendu est devenu capable de faire du rendu volumique. Le moteur de rendu de Blender utilise principalement le lancé de rayons. Un rayon est lancé sur les objets, et en fonction de sa trajectoire (rebond sur le miroir, traversée de la surface transparente), il rapporte une information de couleur. Mais ce lanceur de rayons est surfacique, cela signifie qu'il ne considère que la surface des objets comme zone d'interaction, et considère se déplacer dans un matériaux non participant (qui n'a pas d'influence sur le cheminement du rayon lumineux) entre les objets. Si cette approximation est suffisante pour la plupart des matériaux (ceux qui ne laissent pas passer la lumière), elle devient fausse dès que le matériau est transparent. Cependant on s'en contente pour le verre et le plastique qui sont très faiblement participatifs. Dans le cas d'un volume de gaz, on peut aussi se contenter d'atténuer la lumière en fonction de la distance parcourue (comme on le fait pour l'air sur des faibles distances). Cependant le comportement lumineux au sein de certaines matières est trop complexe pour être si simplement modélisé, on a alors recours à une approche volumique. Pour cela le rayon peut être perturbé lors de son trajet dans le volume.
  
  Cette amélioration va permettre d'augmenter le réalisme des scènes, ou simplement d'ajouter de nouvelles possibilités artistiques.
  
  Une des modifications les plus attendues concernant le rendu dans Blender concerne la mise en place d'une interface de programmation pour l'intégration de moteurs de rendu externes.
  
  Jusqu'à présents, les moteurs externes s'intégraient par le biais de scripts Python et n'avaient que peu de contrôle sur l'interface. Maintenant, Blender se voit doté d'un menu déroulant permettant de modifier le moteur de rendu, celui-ci ayant tout le contrôle qu'il désire sur l'interface.
  
  Cela va permettre à des moteurs autres (comme LuxRender, Yafaray, Mental Ray…) de s'intégrer plus facilement avec Blender en leur permettant de modifier l'interface en fonction de leur besoin en ajoutant les options nécessaires.
  
  Mais quel est l'intérêt d'intégrer un moteur externe à Blender alors que le moteur interne existe ?
  
  Le moteur interne est un excellent moteur de rendu, mais il très orienté vers l'animation et le rendu non réaliste. En pratique, de nombreuses concessions ont été faites avec les lois de la physique pour obtenir un moteur capable de générer un film d'animation complet de plusieurs minutes. A titre d'exemple, 30 secondes d'animation représente un mois de calcul si le calcul d'une image ne prend qu'une heure, il faut donc être capable de générer très rapidement des images.
  
  Cependant, il existe de nombreux domaines où la qualité photoréaliste des images est importante, comme l'architecture par exemple. Certains moteurs sont donc spécialisés dans ce type de rendu, au prix de plusieurs heures / jours de calcul. Parmi les solutions libres, Il existe LuxRender [4] et YafaRay [5]. LuxRender visant le rendu le plus réaliste possible sans biais, mais au prix de nombreuses heures de calculs et de bruit dans les images. YafaRay fournit des méthodes biaisées, qui au prix d'un peu moins de réalisme (pas forcement évident à juger), fournit des images plus rapidement.

Une amélioration a été faite du coté du "bump mapping". Celui-ci retourne des résultats bien plus convaincants visuellement qu'avant. Le Bump mapping est une technique utilisée très souvent en infographie qui vise à modifier virtuellement l'orientation d'une surface par le biais d'une texture. Cette technique permet ainsi de faire réagir la surface différemment aux éclairages de la scène, sans toutefois complexifier la géométrie de l'objet, ce qui peut être un gain de temps énorme lors des rendus. Si de près, l'on ne se laisse pas tromper par la supercherie puisque la surface ne possède pas d'effet de volume (et donc pas d'occlusion au d'auto-ombrage), de loin les résultats sont plus que pertinents pour simuler des irrégularités de surface (comme le grain d'une peau ou les rayures d'un bois).

Et ce qu'il reste à venir

Lors de la sortie de Blender 2.49, plusieurs projets étaient en cours. Si certaines de ces améliorations ont été intégrées au sein de la branche principale et sont donc dès à présent disponibles, d'autres sont encore en travaux. De plus, de nouveaux projets ont depuis commencé.

Il faut rappeler qu'une grande partie de ces travaux a été réalisée par des étudiants lors de Google Summer of Code : optimisation du moteur de rendu, de l'interface, nouveau système d'animation, le support de COLLADA (un format de description de scène) et une bonne partie des modifications de l'API Python.

Pour ce qui est en préparation :

• Une refonte du moteur de sculpture. Celui-ci permet de travailler sur un maillage subdivisé que l'on déforme avec différentes brosses sans changer la topologie (l'agencement général des faces/arêtes/points). Ce type de travail est très intuitif comparé à la modélisation polygonale classique où l'on travaille en ajoutant les faces une à une. Cependant elle nécessite un fort niveau de subdivision qui met rapidement en difficulté la mémoire vive, le processeur et la carte graphique. De nombreuses optimisations dans ce domaine sont en cours. Ces modifications se basent sur le principe simple que la sculpture ne modifie pas la structure du maillage sculpté. Ainsi tout ce qui peut être nécessaire en structure de données dans le mode d'édition polygonal pour simplifier l'ajout et la suppression de géométrie est inutile en mode sculpture. Des premiers résultats montrant d'importants gains de mémoire apparaissent progressivement.
  
• Une refonte du moteur de multi-résolution. Très proche de la sculpture, la multi-résolution permet de travailler à différents niveaux de subdivision d'un maillage, chaque modification à un niveau se répercutant sur les autres niveaux. Des travaux sont faits dans ce domaine pour pouvoir éviter de charger en mémoire tous les niveaux de subdivision lors de l'édition d'un unique niveau, et devraient arriver prochainement dans le cœur de Blender.
  
• Le moteur de logique et d'action du moteur de jeu pourrait quitter sa forme de brique et prendre une forme nodale comme les nœuds d'édition de texture / matériaux / composition. On rappelle ici que le moteur de jeu de Blender est un puissant outil pour coder la logique d'un jeu sans écrire une seule ligne de code. Le jeu Yo Frankie! en est un bon exemple.
  
• Le nouveau format de structure de données pour Blender, nommé Bmesh. Ce format va donner un petit coup de jeune à la manipulation des maillages et permettra ainsi de grandement simplifier certains modificateurs ou même d'en créer d'autres qui étaient impossibles jusqu'à présent. Mais une des fonctions qui sera le plus visible pour l'utilisateur sera la possibilité de créer des Ngons, des polygones ayant un nombre de sommets quelconque, généralement supérieur à 4.
  
  En pratique, cela pose de grands problèmes techniques. Un triangle (le polygone avec le moins de sommets) possède une propriété géométrique très intéressante : tous ses sommets sont dans le même plan. Ainsi, il est fort simple de remplir un triangle. Lorsque l'on prend un quadrilatère, c'est à dire un polygone à quatre sommets, tous les points ne sont pas forcement dans le même plan, mais il est fort simple de se ramener au cas de deux triangles, en séparant le quadrilatère par la diagonale. Pour un polygone à plus de quatre sommets, cela peut devenir très complexe d'arriver à remplir le polygone. L'utilisation de Ngons est donc à éviter au maximum, sauf dans les zones planes.
  
  Alors quel est l'intérêt des Ngons ? Il permettent de simplifier la géométrie. Imaginez que vous réalisez une modélisation d'une maison (rappelez-vous, Blender est utilisé dans l'architecture), vous avez un mur, qui est un quadrilatère. Vous voulez percer une ouverture dans ce mur ; cette ouverture a une forme particulière comportant plusieurs sommets. Avec le Blender actuel, qui ne permet que des quadrilatères, il va falloir transformer votre mur en ensemble de quadrilatères reliés les uns aux autres. Il y a fort à parier que la subdivision de votre mur risque de nécessiter un remaniement des faces adjacentes au mur et, récursivement, d'une grande partie de votre maillage. Faites cela pour plusieurs fenêtres et votre maillage peut rapidement devenir très complexe et difficilement maintenable.
  
  Grâce aux Ngons, votre mur peut avoir plusieurs sommets, et ainsi l'insertion d'une ouverture ne nécessitera pas l'ajout d'autant de sommets.
  
  C'est donc une précieuse aide à la modélisation d'objet non naturels qui sera mise à disposition des artistes.

Durian

Le durian est un fruit à la chaire délicieuse, mais avec plein de piquants et qui a une très forte odeur (!?), mais c'est aussi le symbole du nouveau projet de la Blender foundation, qui se veut magnifique mais avec du caractère, à l'image du fruit.

Le projet a pour but la production d'une œuvre intégralement libre, dans la directe lignée de ses grands frères que sont Elephant Dream [6], Big Buck Bunny [7] et Yo Frankie! [2], l'intégralité des ressources nécessaires à la production seront disponibles. Un autre des buts du projet est de montrer les capacités de Blender et dans le cas particulier de Durian, d'essayer en situation réelle la version 2.5.

Les artistes travaillent depuis plusieurs mois à Amsterdam, et certains morceaux du film commencent à voir le jour.
Je vous renvoie au site/blog du projet pour plus d'informations [3].


[2] http://www.yofrankie.org/
[3] http://durian.blender.org/
[4] http://www.luxrender.net/
[5] http://www.yafaray.org/
[6] http://www.elephantsdream.org/
[7] http://www.bigbuckbunny.org/

En images sur le BlenderClan
http://blenderclan.tuxfamily.org/html/modules/news/article.p(...)

Aller plus loin

• Note de version (17 clics)
• Obtenir Blender (36 clics)