Depuis le début de l’année 2014, les améliorations et les nouveautés se sont succédé pour le moteur de rendu Octane. Il est donc grand temps pour moi de faire le bilan des derniers ajouts. Bien entendu ce ne sera qu’un instantané, tant les versions s’enchaînent à un train d’enfer chez Otoy, mais ça devrait vous donner un bon aperçu du présent et du futur proche de ce moteur. Attachez vos ceintures, ça décoiffe.

Merci à Cécile, ma compagne, pour ses suggestions et relectures.

Le passage de la version 1.5 à la version 2.0

Après la publication de la dernière version de la série 1.xx, à savoir la version 1.55, avec déjà des améliorations de taille comme :

• Le support des fichiers au format Alembic et le rendu d’animation
• Les scripts LUA
• Le flou de caméra
• Les propriétés d’objet (visibilité caméra, visibilité ombres et visibilité globale)
• Les projections UV
• Les améliorations d’interface
• L’introduction du format ORBX

Otoy est passé aux versions 2.xx offrant un autre lot d’améliorations très attendues et tout à fait décoiffantes en terme de rapidité de rendu. En voici une liste non-exhaustive :

• Le déplacement sous-polygonal
• L’OpenSubdiv de Pixar
• Les flous de mouvement d’objets et de vertex
• Les cheveux et fourrures
• Une base de données locale
• Le rendu en réseau
• Les couleurs aléatoires sur des instances
• Le rendu de régions
• Les angles arrondis
• Les améliorations de kernels comme le clampage de l’illumination globale, le mode cohérent, etc
• Les passes de rendu

Avec cette liste, on constate qu’Octane est passé de l’état de moteur de rendu post-expérimental à l’état de moteur de rendu de production. Il ne manque quasiment plus rien pour concurrencer les autres moteurs du marché. Du moins sur le papier…

Soyons honnête, pas mal de ces fonctions sont encore en phase de correction (on ne peut plus parler de phase Beta, mais il reste des petites choses à ajuster). Il faudra donc sans doute encore attendre quelques semaines ou quelques mois, selon les fonctions, pour que tout soit totalement bétonné. Il n’en reste pas moins que ces fonctions sont tout à fait utilisables à ce stade moyennant un peu d’adaptation de la part de l’utilisateur.

N’oublions pas non plus que nous sommes dans un environnement de développement très différent de ce qui se fait d’habitude en calcul CPU. Certaines fonctions qui seraient simples à développer sur CPU sont très difficiles à implémenter sur GPU. Il faut également jongler avec la relative pauvreté des infos transmises au GPU, avec la relative exiguïté de l’espace mémoire, etc. Donc cela reste parfois un peu expérimental ; cela continue de demander à l’utilisateur un effort d’adaptation et certaines concessions. Mais la vitesse de rendu d’Octane pour un faible coût matériel est vraisemblablement à ce prix.

Les améliorations en quelques mots

Voici en bref les limites et particularités de ces différentes améliorations :

Le support des fichiers au format Alembic et l’animation : c’est une fonction surtout intéressante pour ceux qui veulent travailler en animation avec la version standalone du moteur de rendu. Elle permet l’importation de maillages animés au format Alembic (http://www.alembic.io/). Outre le maillage lui-même, ce format, du moins à partir de Cinema 4D, permet l’exportation d’informations telles que les cheveux, les données Hyper-Nurbs, les instances, etc. Il ne permet pas par contre d’exporter des données d’animation, de matériaux ni de quelconques informations de textures.

Certains utilisateurs ont développé un workflow basé sur une première importation de la scène globale au format OBJ pour le développement des nœuds de matériaux puis une importation de l’animation en plusieurs scènes (le décor fixe, les instances, les animations par transformation, les PLA, etc). C’est d’ailleurs globalement comme ça que fonctionne également le plugin Octane pour Cinema 4D en interne (excepté qu’il n’utilise pas le format Alembic).

Conseil d’utilisation : je n’ai pas de conseil particulier à vous donner pour l’export Alembic si ce n’est de bien gérer les priorités et les caches des cheveux ainsi que la nomenclature des objets et des matériaux avant l’exportation.

Les scripts LUA : limités pour l’instant à la version standalone, les script LUA permettent de piloter la quasi-totalité du logiciel à partir de scripts. Il permet aussi d’écrire des scripts de shaders par exemple ou des fonctions complexes d’animation, etc. C’est le complément indispensable à l’import d’animation Alembic pour le pilotage des animations de paramètres comme les matériaux, les caméras, les imagers ou les renderTargets. Par exemple, le rendu d’animation est désormais piloté par un script LUA fourni avec le logiciel. Avec la version plugin pour Cinema 4D, les scripts LUA sont inutiles puisque tout est pilotable directement dans Cinema 4D. Le seul intérêt dans ce cas serait le support de shaders personnalisés. Cela semble être en projet mais inexistant pour le moment.

Conseil d’utilisation : l’exploration des script LUA est un monde en soi. N’oubliez pas de vous référer à l’espace dédié sur le forum Otoy (http://render.otoy.com/forum/viewforum.php?f=73).

Le flou de caméra, les flous de mouvement d’objets et de vertex : dans la dernière version 1.5 d’Octane, seul le flou de déplacement de caméra était supporté. Avec la version 2.xx, les flous tant de caméra que d’objets et de vertex sont supportés. Le tout avec une rapidité de rendu qui décoiffe… Pas grand-chose à dire là-dessus, si ce n’est que ça fonctionne, tout simplement. Dans Cinema 4D, il faut utiliser les tags OctaneObject pour piloter ces fonctions.

Conseil d’utilisation : dans la version plugin pour Cinema 4D, il faut ajouter un tag OctaneObject aux objets animés pour pouvoir gérer le flou de mouvement d’objet. Pour le réglage du flou lui-même, tout se trouve dans le tag OctaneCameraTag à l’onglet Motion Blur. Il ne faut pas non plus oublier d’activer le Motion Blur dans les réglages de rendu d’Octane. Le sous-paramètre Time Sampling per frame doit être réglé plus haut s’il y a des objets à mouvement rapide (comme une hélice d’avion par exemple).

Les projections UV : depuis la version 1.5, tous les nœuds de textures ou de bruits intègrent des sous-nœuds de projection et de transformation des UV. Ces nœuds sont paramétrables texture par texture, ce qui permet, en combinaison avec des nœuds comme les mixTexture, Multiply, etc, des mélanges hautement paramétrables ! Seul bémol : comme les transformations sont liées à l’échelle de l’objet, il est fortement déconseillé d’en modifier la taille après le paramétrage des textures. Bien entendu, on peut toujours utiliser les fonctions de projection intégrées à Cinema 4D sans modifier les nœuds de transformation des UV et de projection. Dans Cinema 4D, ces nœuds sont inactifs par défaut.

Les améliorations d’interface : cela ne se voit pas fort mais l’interface a été entièrement réécrite avant la version 1.5. C’est ce qui a permis aux développeurs d’avancer plus vite depuis. Quelques petits changements sont visibles, comme les sliders ; dans l’ensemble on s’y retrouve vite. De nouveaux nœuds sont apparus ou ont été améliorés comme le nœud « scene » ou le nœud « node graph ».

L’introduction du format ORBX : avec la version 1.5 a été introduit le format de fichier ORBX. Il permet l’exportation et l’échange de matériaux avec intégration des textures mais aussi l’archivage de scènes complètes avec intégration des objets. Ce format de fichier se veut être plus qu’un simple format spécifique à Octane, à savoir, un format de fichier 3D universel (http://render.otoy.com/newsblog/?p=453). Il a été développé en collaboration avec Autodesk et Mozilla.

Conseil d’utilisation : il peut être intéressant de définir le chemin de la base de données locale de la standalone au même endroit que la base de données propre au plugin pour Cinema 4D. Cette dernière ne peut pas être déplacée ou définie par une préférence mais elle peut ouvrir les matériaux générés par la standalone.

L’OpenSubdiv de Pixar : complément logique à l’importation d’animation via Alembic, Octane intègre depuis la version 2.xx les bibliothèques OpenSubdiv de Pixar (http://graphics.pixar.com/opensubdiv/overview.html) qui permettent une subdivision à la volée (un peu à la manière d’un Hyper-Nurbs de Cinema 4D, mais en mieux) sans grosse augmentation de la consommation GPU. Cette fonction permet donc d’exporter une animation au format Alembic avec l’Hyper-Nurbs désactivé et une subdivision calculée au niveau du GPU sans grosse perte de mémoire ! Cette fonction est tout aussi utile avec le plugin pour Cinema 4D puisqu’elle permet de remplacer avantageusement la subdivision Hyper-Nurbs (et donc de réduire la quantité d’information à envoyer au GPU à chaque frame).

Conseil d’utilisation : dans la version plugin pour Cinema 4D, il faut ajouter un tag OctaneObject aux objets que l’on veut subdiviser dynamiquement dans Octane. Attention, avec les objets Nurbs (peau, révolution, extrusion contrôlée,…) ce tag peut générer des plantages.

Les couleurs aléatoires sur des instances : les instances sont supportées depuis longtemps dans Octane mais il n’était jusqu’alors pas possible de définir des couleurs aléatoires pour ces instances. Ce qui est désormais chose faite à l’aide d’un nœud « random color texture » qu’on peut associer par exemple au paramètre « amount » d’un nœud de dégradé. En changeant les couleurs du dégradé, on contrôle le spectre de couleurs aléatoires. Simple et efficace.

Conseil d’utilisation : au lieu d’utiliser l’entrée amount d’un simple dégradé, on peut également utiliser l’entrée amount d’un mixTexture ou de tout autre nœud de type floatTexture ou imageTexture, donc par exemple l’entrée power d’un noeud pourrait être utilisé pour faire varier la luminosité d’une texture d’une instance à l’autre aléatoirement.

Le déplacement sous-polygonal : attendu depuis longtemps, le déplacement sous-polygonal a été intégré à Octane. Il ne supporte que des fichiers bitmap (8, 16 ou 32 bits) et rien d’autre. Dans le cas de fichiers RVB, c’est la couche rouge qui est utilisée. Dans Cinema 4D, à l’aide du plugin il est possible d’utiliser les surfaces et les bruits natifs de C4D puisqu’ils sont convertis à la volée en fichiers bitmap. La fonction est très puissante et très rapide mais pas toujours simple à maîtriser, surtout avec des maps générées à partir de Mudbox, Zbrush ou la sculpture de Cinema 4D. Comme les valeurs de déplacement sont absolues (et non relatives à un gris 50% par exemple), il n’est pas toujours facile de maîtriser les creux. Mais pour des déplacements plus simples comme un pavement, un terrain ou du motion graphic par exemple, cette fonction est époustouflante. Otoy y travaille toujours.

Conseil d’utilisation : pour des raisons de performance, le développeur du plugin n’a pas intégré automatiquement le nœud Displacement dans l’onglet ad hoc du gestionnaire de matériaux sous Cinema 4D. Il faut donc l’ajouter manuellement. Et c’est à l’intérieur de ce nœud qu’on ajoutera la texture ou le shader C4D, pas à la racine de l’onglet. Bon à savoir…

Les cheveux et fourrures : loin des fonctions étendues du module Hair de Cinema 4D comme les fourrures, les plumes, les gazons architecturaux, les extrusions de splines (les cheveux ne peuvent être que circulaires), etc, les cheveux d’Octane sont tout de même extrêmement puissants ! Le rendu est très rapide. L’intégration se fait soit via une exportation Alembic (seul format capable de fournir à Octane les splines nécessaires au rendu des cheveux dans la standalone) soit directement dans Cinema 4D. Concernant C4D, il n’est pas possible d’afficher directement les cheveux dans le Live Viewer (les calculs de préparation prendraient trop de ressources en temps réel) ; il faut nécessairement passer par le visualiseur et quelques réglages spécifiques (expliqués dans le manuel) pour pouvoir voir la chevelure complète. On peut toutefois visualiser les guides dans le Live Viewer, ce qui permet de gagner du temps sur la préparation des matériaux. Ce module n’est pas le plus abouti de la version 2.xx d’Octane ni le mieux intégré à Cinema 4D mais avec un peu d’astuce il y a déjà moyen d’en sortir beaucoup, et tout ça en illumination réelle et à grande vitesse… C’est déjà formidable.

Conseil d’utilisation : je vous recommande chaudement de lire le manuel à propos des cheveux. Cela vous fera gagner pas mal de temps.

Une base de données locale : il est désormais possible d’enregistrer ses matériaux dans une base de données locales au format ORBX avec une prévisualisation. À partir de la standalone, on peut enregistrer sa base de données n’importe où (le chemin est défini dans les préférences), ce qui permet de la partager sur le réseau ou de la partager avec l’équivalent du plugin pour Cinema 4D.

Conseil d’utilisation : on peut trouver le chemin vers le dossier de la base de données du plugin pour Cinema 4D en ouvrant la palette DB et choisissant le menu File > Open LiveDB storage. Le lien exact s’affiche dans la barre d’information en bas de la palette.

Le rendu en réseau : depuis la version 2.xx, Octane intègre une fonction de rendu en réseau à l’aide d’un daemon. Il est possible d’associer jusqu’à 12 GPU. Un réseau en Gigabits est fortement recommandé. Malheureusement, pour l’instant il est indispensable de disposer d’autant de licences standalone qu’il y a d’ordinateurs à partager sur le réseau, Otoy n’a pas encore publié une version de type nœud de rendu à un prix plus concurrentiel. À signaler, pour ceux qui voudraient essayer d’utiliser leur licence Standalone sur un deuxième ordinateur en combinaison avec leur licence plugin, que ça ne fonctionne pas. Il faut nécessairement une deuxième licence. Donc je ne peux pas dire grand chose sur cette technique puisque je n’ai pas eu l’occasion de la tester mais d’après les retours du forum cela semble très bien fonctionner.

À préciser que la version plugin Cinema 4D est également compatible avec les fonctions de réseau ou de batch de C4D. Le plugin intègre d’ailleurs sa propre fonction de rassemblement de projet pour ce faire.

Le rendu de régions : il est supporté tant dans la version standalone que dans la version plugin. Ça fonctionne, tout simplement… Je ne peux pas en dire grand-chose car je n’utilise pas beaucoup cette fonction mais elle semble remplir son office comme il se doit.

Les angles arrondis : il s’agit une petite fonction qui n’a pas reçu un accueil particulièrement enthousiaste de la part de la communauté mais qui recèle toutefois quelques avantages non négligeables. Cette fonction permet, via le gestionnaire de matériaux, d’ajouter de légers chanfreins aux angles sans devoir pour autant biseauter le maillage. Ce n’est pas une fonction spectaculaire comme le déplacement ou le flou de mouvement mais elle peut faire gagner pas mal de temps dans la modélisation d’objets simples. Cela dit, il n’y a pas de secrets, elle donnera de meilleurs résultats avec une modélisation propre et ne remplacera pas un vrai chanfrein sur les objets vus de près. Par contre, pour chanfreiner l’angle entre un mur et un plafond ou les bords d’une table sans effort, c’est idéal. Il vaut mieux utiliser des valeurs très basses.

Les améliorations de kernels comme le clampage de l’illumination globale, le mode cohérent, etc : petit à petit, au fil des versions de test, de nouvelles fonctions d’accélération du kernel apparaissent, comme le clampage d’illumination globale pour réduire les bruits parasites dans les rendus en Pathtracing et PMC avec des éclairages difficiles, le remplacement du système aléatoire (roulette russe) d’arrêt des rayons par le système de « Path term. Power » (Path termination strategy), qui permet un meilleur contrôle du bruit dans certaines situations, ainsi que le coherent mode, qui permet une accélération du rendu en mode Pathtracing et Directlighting (mais qui provoque des sauts d’images durant le rendu et qui est plutôt à réserver aux rendus définitifs de plus de 500 samples).

Voici les explications d’un des développeurs (http://render.otoy.com/forum/viewtopic.php?f=33&t=42564) : « We also implemented a new path termination strategy, which is a bit tricky to explain: In the past the there was this ominous pin « RR probability » which in most cases only worked good when set to 0. With the new algorithm we try to provide a system where you can tweak render speed vs. convergence (how fast noise vanishes). Increasing the value, will cause he kernels to keep paths shorter and spend less time on dark areas (which means they stay noisy longer) but may increase samples/second a lot. Reducing the value will cause kernels trace longer paths in average and spend more time on dark areas. The current default of 0.3 works good in most scenes, but play with it. For example, in two interior test scenes it actually payed off to set the value to 0.5 – 0.6 which increases the samples/second a lot and then just to render more samples.
The direct lighting and path tracing kernels also have a new option « Coherent mode », which increases the render speed, but causes some « flickering » during the first samples/pixel and should be mainly used for the final rendering and if only if you plan to render 500 samples/pixel or more. »

Conseil d’utilisation : il ne faut pas hésiter à adapter les paramètres du kernel. Par exemple, pour une scène d’extérieur éclairée par un soleil et rendue en Pathtracing, il est inutile de conserver les valeurs par défaut de Diffuse depth et de Specular depth qui sont trop hautes dans ce cas. Si on fait un rendu en DirectLighting > Ambiant occlusion, adapter le paramètre AO Distance (qui est à 3 mètres par défaut) changera parfois radicalement les choses en mieux. Si on n’utilise aucune transparence alpha dans les matériaux ni aucun matte et qu’on a pas activé le Fake shadows pour l’un ou l’autre matériau specular, il est inutile de conserver cochée la case Alpha shadows. Ça vous fera gagner de précieux samples/s. Et caetera.

Les passes de rendu : enfin, après l’introduction de la passe d’occlusion ambiante dans la version 1.5 (en plus des passes déjà existantes), la dernière fonction de cette liste – mais non des moindres – pour la version 2.xx est l’implémentation des passes de rendu, telles que : les réflexions directes et indirectes, la réfraction, les émetteurs, les couleurs diffuses directes et indirectes, l’environnement, le SSS (Sub-surface Scattering), la transmission et les effets de post-production (glow et flares). Cette fonction est encore largement en chantier et les développeurs ont fait appel à la communauté pour améliorer les passes fournies afin de mieux coller à la réalité du métier comme des impératifs de production, mais les résultats actuels sont déjà très utilisables. Attention toutefois car ces passes prennent pas mal de place en mémoire GPU et demandent du temps à calculer ; il faut donc les utiliser avec parcimonie et selon les besoins.

Conseil d’utilisation : par moment, les passes obtenues peuvent sembler déroutantes (en regard de ce qu’on aurait été en droit d’attendre avec les passes équivalentes Cinema 4d par exemple) mais sont en général cohérentes et permettent pas mal de choses en compositing pour peu qu’on ait expérimenté et identifié les passes nécessaires aux altérations voulues. Pour plus d’explications sur le sujet, je vous renvoie au fil de discussion dédié sur le forum Otoy : http://render.otoy.com/forum/viewtopic.php?f=9&t=42622

À savoir : j’ai constaté que dans la version plugin pour Cinema 4D les passes enregistrées au format TIFF pouvaient poser problème. Il vaut donc mieux pour l’instant préférer d’autres formats de fichier comme le PSD ou le EXR. Ce n’est pas un gros handicap mais autant le savoir pour ne pas perdre de temps…

Rendu principal

Passe de réflexion directe

Passe de réflexion indirecte

Passe d’occlusion ambiante

Passe de diffusion directe

Passe de diffusion indirecte

Conclusion

Avec ce dernier point, j’en ai terminé pour les grosses nouveautés d’Octane 2.xx à ce jour. À savoir que, dans la majorité des cas, le développeur du plugin pour Cinema 4D fait un travail extraordinaire et ne met pas plus de quelques jours pour implémenter (en tout ou en partie) toute amélioration de la version standalone. C’est suffisamment rare et exceptionnel pour être signalé. Vous pouvez donc vous orienter vers la version plugin sans crainte de retards excessifs : le développement est entre de bonnes mains.

Toutefois, je remarque que sur sur le forum dédié au plugin Cinema 4D, de plus en plus de questions concernent davantage la version standalone que son implémentation. Ce qui signifie que les nouveaux utilisateurs ne gardent pas un œil sur le développement du moteur de rendu proprement dit mais uniquement sur son adaptation à Cinema 4D. C’est selon moi une erreur car, ce moteur de rendu étant assez atypique, il est indispensable de garder un lien avec la logique de fond du moteur pour bien comprendre les choix du développeur du plugin quant à l’intégration dans Cinema 4D. Un utilisateur averti en vaut deux…

Bien entendu, n’hésitez pas à me laisser un commentaire si vous avez des questions ou si une erreur s’est glissée dans mon article.