Des donnés pour un rendu

Cet article aurait dû être un énième « Appel à témoins », pour un renderer d'images de synthèse. Malheureusement, l'isolement artistique dont je me plaignais dans Circuits fermés et dans Blogosphère et popularité continue de me hanter. Donc au lieu d'appeler des témoins en espérant (plus ou moins) de l'aide, je vais simplement expliquer le problème sans espoir que ça fasse avancer quoi que ce soit. De toute façon, ce n'est pas une question de clou.

Homéostasie

À l'heure où j'écris ces lignes, la totalité des image que j'ai publiées dans la section Dessins ont été construites en utilisant le renderer appelé pixie.

Au cas où ce soit utile de le rappeler, un renderer est un programme qui lit une description d'une en 3D, par exemple « deux sphères de telle matière à tel endroit dans une boîte », et qui construit une image (en 2D, donc) conforme à cette description.

Pixie est très bien comme programme, je m'en sers depuis plus de huit ans, et je n'ai pas trop à m'en plaindre. Alors, pourquoi vouloir changer ?

Le projet me donne l'impression d'être plutôt mort : la dernière mise à jour date de juin 2009, les listes de diffusion n'ont pas bougé depuis un an, et je n'y ai pas vu de dev' depuis fin 2010.

On pourrait se dire que c'est simplement que le programme est arrivé à maturité : s'il fait correctement tout ce qu'on attend de lui, et qu'on n'en attend rien de plus, il n'y a pas de raison de changer. C'est le cas pour ddns et libsoldout, dont je me sers quotidiennement et qui sont pratiquement terminés.

Ce n'est pas vraiment le cas de Pixie, s'il me rend des bons et loyaux services, c'est surtout parce qu'au fil du temps j'ai appris à contourner ses problèmes et ses bizarreries.

Par exemple, quelque chose se passe mal entre les fragments de tores et le raytracer, et ça conduit à des résultats aberrants. Du coup dans toutes mes images avec raytracer (pratiquement toutes), je remplace les tores par une approximation en surfaces bicubiques.

Autre exemple, la CSG n'est pas implémentée, donc pour faire un carré percé (par exemple pour la base des plot en LEGO), je ne peux pas soustraire un cylindre à un carré, je dois construire directement la surface avec une surface B‐spline rationnelle et non‐uniforme. L'artillerie lourde, quoi.

Mais finalement, tant que ça marche, ça marche. À chaque fois que j'arrivais à cette conclusion, je me disais qu'il n'y avait pas urgence à changer, je pourrai chercher calmement dans la concurrence quand je n'aurai que ça à faire.

Transistasie

Et puis il y a quelques jours, mon disque dur principal est mort, emportant avec lui toutes les données non‐sauvegardées, c'est-à-dire que des données qui ne sont pas importantes, vu que mes données importantes sont sauvegardées sur plein de disques différents dans plusieurs pays différents.

C'est là qu'on se rend compte que perdre toutes ses données non‐importantes, ben c'est chiant quand même.

Parmi ces données pas assez importantes pour être sauvegardées, il y avait mon ébauche de binding Ada à Pixie (en gros, du code qui permet d'utiliser Pixie à partir d'Ada au lieu du C pour lequel il est prévu).

Il était authentiquement trop brouillon et mal‐foutu pour mériter une place dans une sauvegarde (ou dans un gestionnaire de versions), mais il me suffisait pour faire en urgence des images d'anniversaire.

Donc à présent, pour faire des images de synthèse, je dois soit revenir au C, soit refaire un binding à partir de rien.

Du coup, tant qu'à refaire un binding, pourquoi ne pas en profiter pour changer de programme ?

Étude de marché

Je suis donc repartie plus sérieusement en quête d'un équivalent à Pixie qui soit mieux, et/ou qui ait plus de potentiel.

Aqsis

Aqsis est l'alternative la plus proche de Pixie. Tous les deux ont pris l'interface de Photorealistic Renderman, l'outil utilisé par Pixar pour faire ses films.

Quasiment la même interface, ça veut dire qu'un binding pour l'un est quasiment utilisable directement pour l'autre. Donc je peux réutiliser à peu près tous mes acquis, seul le jeu de fonctionnalités (et de bug) change. Je perds mon système d'éclairage préféré, en gagnant la CSG.

Sauf qu'en fait en tant que projet, Aqsis n'ai pas l'air tellement plus en forme que Pixie. Des forums bourrés de spam, un blog qui n'a qu'une entrée depuis 2011, un code qui ne bouge plus depuis début 2012, une liste diffusion bien légère qui a l'air de parler plus souvent de psychopath que d'aqsis, et une v2.0 dans les limbes depuis une éternité, ça ne respire pas vraiment la pérennité.

En fait Aqsis comme Pixie me semblent être arrivés à la conclusion de n'importe quel gros projet ne comprenant qu'un ou deux développeurs et une communauté trop petite pour en apporter d'autres.

POV-Ray

Avant de passer à Pixie, j'utilisais POV-Ray, avec lequel j'ai découvert l'image de synthèse. La dernière version stable date de 2004, et je l'utilisais encore avant de passer à Pixie.

Cette fois, l'argument de la maturité est acceptable. D'autant plus que la bêta 3.7 évolue pas mal.

Par contre, je me souviens encore du passage de POV-Ray à Pixie et la joie de découvrir un rendu bien plus rapide, l'illumination globale, les shaders programmable, et surtout la description de la scène dans un vrai langage de programmation plutôt que dans un langage de script ad-hoc.

Je ne suis pas encore assez désespérée pour faire la transition inverse.

LuxRender

LuxRender a l'air d'être le renderer libre le plus dynamique du moment, avec une communauté de développeurs et un nombre suffisant de fans pour avoir confiance dans l'avenir du projet.

En plus, son interface est faite dans le même esprit que celle de RenderMan, donc je peux réutiliser tous mes réflexes de Pixie. L'interface en elle-même est trop différente pour pouvoir réutiliser des bindings, mais comme justement je repars de zéro, il y a fort à parier que ça me prenne autant de temps d'écrire un binding pour LuxRender que pour Pixie.

Par contre, LuxRender se targue d'être non‐biaisé et physiquement correct. En soit c'est louable, mais l'autre côté de ce compris, c'est un temps de calcul assez énorme (on peut gagner beaucoup de temps en trichant sur la physique), et une bibliothèques de matériaux plus limitée (décrire un matériau physiquement juste, c'est dur) et plus rigide (pas de fantaisie non‐physique).

Appleseed

Appleseed est un renderer que j'ai découvert récemment, et qui a l'air assez peu connu. Et peu connu, ça veut dire une communauté d'utilisateurs assez réduite, et peu de développeurs. Exactement ce qui (à mon avis) a conduit Pixie et Aqsis à leur état actuel. À part que les développeurs font ça à plein temps, donc la pérennité est celle d'une entreprise (/*jupter jazz*/) et non d'un intérêt personnel. Je ne sais pas trop quoi en conclure concrètement.

Je trouve la page de présentation et les FAQ super séduisantes. Ça me donne envie sérieusement de bondir sur le projet. C'est exactement l'état d'esprit dans lequel je fais de l'image de synthèse, et les fonctionnalités correspondent à mes préoccupations. C'est peut-être un outil un peu trop gros pour le loisir de base, mais je serais prête à investir un temps « pro » tant ces pages m'enflamment.

Par contre, la réalité derrière fait mal. La liste des fonctionnalités annonce fièrement une interface C++ complète. Déjà des bindings sur du C++ sont nettement plus pénibles à construire que des bindings sur du C (comme c'est le cas pour RenderMan ou LuxRender).

Ensuite, je n'ai pas trouvé la moindre documentation concernant cette API, ce qui la rend beaucoup plus difficile à exploiter.

Enfin, après jurons et UTSL, il semble impossible de construire les objets d'une scène, l'API prétendument complète ne semble permettre que d'importer une géométrie existante dans un fichier externe de format que je n'ai pas encore pu déterminer (peut-être Wavefront .obj). Ce qui est d'autant plus pénible que ce format semble être polygonalisé, alors qu'un renderer gagne beaucoup à avoir une description mathématique des surfaces.

Autres ?

J'ai l'impression d'avoir couvert à peu près tous les candidats sérieux.

Je connais Yafaray qui n'a pas l'air en super forme non plus, et dont la seule interface semble être un fichier XML.

J'ai entendu parler de Cycles qui ne semble avoir d'interface que pour Blender.

J'ai vu passer quelques fois Mitsuba, qui ressemble à Appleseed par le manque de documentation de l'éventuelle interface, et par l'obligation d'importer des objets polygonalisés, mais sans tout ce que j'ai trouvé de positif dans Appleseed.

Et j'ai évidemment passé sous silence tous les renderers payants et les renderers gratuits mais propriétaires qui ne sont pas disponibles pour mon système d'exploitation actuel, pour des raisons que j'espère évidentes.

Conclusion

Je ne sais justement pas trop quoi conclure.

Il n'est pas encore complètement impossible que je puisse récupérer mon binding, ce qui remettrait en sommeil la question, au profit de Pixie.

La roadmap d'Appleseed parle d'ajouter un jour le support RIB, qui contiendra peut-être l'API définie dans le standard. En tout cas, ça n'a pas l'air parti pour être tout de suite.

Les inconvénients de LuxRender peuvent être gérables, le temps de calcul ce n'est qu'une question de patience, et les matériaux ne sont peut-être pas aussi contraignants que je l'imagine, surtout avec la possibilité de les combiner.

J'imagine qu'à très court terme, je vais continuer d'utiliser Pixie directement en C, et peut-être continuer mon étude de marché, en espérant tomber sur un autre inconnu aussi prometteur qu'Appleseed.

Commentaires

1. Le mercredi 7 août 2013 à 2:04, par _FrnchFrgg_ :

C'est un peu faux de dire que Cycles n'a de binding que depuis Blender; c'est pire que ça. Techniquement il est vrai que Brecht (le concepteur de Cycles) a dit qu'il pourrait être rendu standalone parce que concu architecturalement pour ça, en pratique on peut dire que Cycles est plus un renderer intégré à Blender. Ce qui veut dire qu'à moins d'un investissement considérable Cycles n'est pas dans la course.

D'autre part, Cycles est unbiased (peut-être qu'il a quelques possibilités de triche). Enfin, ça ne m'étonnerais pas que Cycle ne travaille que sur des meshes triangulés en interne (hormis traitement spécifique pour les cheveux et autres). Je tire ça de ce que j'ai lu que la bonne approche pour le motion (and deformation) blur (le vrai pas le blur entre images rendues successives) serait l'utilisation de «moving triangles».

Pour LuxRender il me semble qu'il soit globalement bon niveau vitesse, et avec le rendu sur GPU ça peut devenir plus rapide que du biased non accéléré...

2. Le mercredi 7 août 2013 à 12:19, par Franz :

Salut,

Je suis le fondateur et l'auteur principal d'appleseed. Je suis tombé sur ce post un peu par hasard, en jettant un oeil aux referrals sur appleseedhq.net.

Attention, long post :)

Ton analyse du "marché" des moteurs de rendu open source est pertinente. Dommage que Pixie n'ait jamais vraiment décollé, il a toujours eu une bonne réputation (largement justifiée) mais, comme beaucoup de projets open source, il n'a pas su se "marketer" et établir une communauté pérenne d'utilisateurs et de développeurs.

LuxRender et Cycles sont les leaders incontestés pour le moment; ils ont tout les deux su attirer utilisateurs et, dans une moindre mesure, développeurs, et leur pérénité à moyen terme semble assurée (rien n'est jamais certain sur le long terme; un projet peut mettre des années, voire des décennies avant de s'éteindre complètement).

Mitsuba, de Wenzel Jakob, est un des moteurs les mieux écrit et les plus robustes. L'architecture et le code sont exemplaires. Wenzel étant un excellent chercheur dans le domaine, Mitsuba bénéficie également des dernières avancées technologiques, tant au niveau des définitions de matériaux qu'au niveau des algorithmes de "light transport". Mitsuba a la réputation d'être un moteur "orienté recherche" : c'est assez vrai, mais des discussions privées avec Wenzel me font penser qu'il souhaiterait le transformer en outil de production, ce qui est tout à fait plausible. Pour autant, ce n'est pas encore chose faite.

Comme tu l'as constaté, appleseed est encore assez en retrait par rapport à cette concurrence. C'est un choix délibéré de ma part : si j'encourage son utilisation dès maintenant, je ne le considère pas encore assez utilisable pour le promouvoir à une plus large audience. D'ailleurs, le fait qu'il soit toujours en version alpha à tendance à refroidir les utilisateurs les moins téméraires.

Je dirais qu'il manque à appleseed au moins une chose vraiment essentielle à ce stade : une intégration solide dans une des applications de création de contenu (Maya, 3ds Max, Houdini, Blender...). Plusieurs projets sont en cours de développement (Mayaseed, mayaToAppleseed, Blenderseed) mais aucun n'est encore assez complet et robuste. L'autre gros point noir est le manque de documentation. Il serait encore un prématuré de tout documenter étant donné que les choses bougent encore pas mal : les formats de fichiers et les API évoluent, la terminologie change, des fonctionnalités sont ajoutées, supprimées...

Malgré tout, appleseed n'a pas grand chose à envier aux autres moteurs de rendu en termes de features ou de performance, et possède aussi ses qualités propres : transformation motion blur, deformation motion blur et instancing hiérarchique puissants (largement au-delà de ce qu'offrent les autres moteurs open source); rendu spectral; rendu entièrement linéaire avec correction/décorrection gamma à la volée; interface utilisateur dédiée, disponible sur toutes les platformes supportées; construction et édition de la scène pendant le rendu, donc avec visualisation instantanée des changements; excellent scaling sur les machines multiprocesseurs / multicores; etc.

Le projet est également bien vivant : nous sortons chaque année entre 4 et 6 releases, dont 2 à 3 release majeures, et ce depuis la première alpha publique en juillet 2010. Nous avons de nombreuses discussions sur la mailing list de développement (appleseed-dev) qui est ouverte à toutes les discussions autour du rendering. appleseed est également utilisé avec succès depuis plusieurs années, y compris sur des petites productions commerciales. La dernière en date est une série d'une dizaine épisodes de 15 à 20 secondes pour la BBC, qui devrait être diffusée sur la télévision britannique prochainement.

Le futur nous dira si appleseed réussit à se créer une place, et s'il réussit à attirer suffisamment d'utilisateurs et de développeurs. Je ne peux évidemment rien garantir à ce stade, mais nous travaillons dur, le projet avance, et l'architecture et le code sont sains.

N'hésite pas à rejoindre la mailing list appleseed-dev [https://groups.google.com/forum/#!forum/appleseed-dev] si tu veux te tenir au courant des développements récents et participer aux discussions. Je t'invite d'ailleurs à utiliser cette mailing list pour toutes tes interrogations ou questions au sujet des API (C++ ou Python), afin que tout le monde puisse profiter des réponses. N'hésite également pas à télécharger appleseed, à l'essayer et à nous faire part de tes retours (sur le forum ou sur appleseed-dev). La prochaine alpha (la 19ème !) devrait sortir très prochainement; elle apporte notamment l'édition de la scène à la volée pendant le rendu.

Franz

3. Le mercredi 7 août 2013 à 13:04, par Natacha :

_FrnchFrgg_, je n'ai rien contre la tesselation en soi, hein. J'ai tendance à préférer l'élégance de la résolutions d'équations (comme le fait LuxRender), mais c'est juste pour l'élégance. Ce je n'aime pas du tout, c'est la tesselation statique, parce qu'une bonne tesselation dépend des conditions de rendu (par exemple la taille apparente), c'est idiot de prendre la même tesselation pour un morceau de tore qui constitue la bouée dont la valve est en gros plan et pour un morceau de tore qui fait partie d'un pneu d'avion vu à 10km. Donc je veux laisser la tesselation au renderer.

Quant à LuxRender, il a l'air effectivement assez prometteur, je suis en train de l'évaluer par rapport à Pixie sur une scène largement à son avantage. Par contre pour ce qui est de l'accélération par GPU, si tu prends en compte le temps d'installation d'un autre OS, de le configurer et de se familiariser avec, ça fait exploser le temps de rendu. Donc ça va rester du pur CPU.

Franz, bienvenue ici, je ne m'attendais pas à être remarquée. Je n'étais peut-être pas assez claire, mais j'ai une très très bonne impression d'Appleseed, et la seule raison pour laquelle je n'ai pas franchi le pas c'est la description des objets.

Comme dit dans le premier paragraphe de ce commentaire, une bonne tesselation dépend des conditions de rendu, et je ne me sens pas vraiment de la faire moi-même, donc il faut que le renderer le fasse.

À ce stade il peut être intéressant de rappeler ma méthode de travail pour arriver à mes images : je suis incapable d'utiliser un modeler, ou d'interagir avec une représentation 2D de quoi que ce soit. Donc je programmes les scènes, en écrivant directement des .pov, des .rib ou un programme qui utilise une API similaire. Donc je ne peux pas compter sur un modeler qui ferait la tesselation ad-hoc à ma place.

Je ne sais pas à quel point il serait difficile d'ajouter des primitives de base à Appleseed pour que je puisse m'en servir ; mais si c'est à ma portée je crois que je serais prête à braver mon manque de goût au C++ pour l'écrire. Ce serait de toute façon un prérequis pour supporter l'interface RenderMan, mais ce support a l'air plutôt loin dans la roadmap…

4. Le mercredi 7 août 2013 à 22:20, par Franz :

Quelles primitives utilises-tu le plus dans l'API RenderMan ? Surfaces de subdivisions ? Quadrics ? NURBS ? CSG ? Solides de base ?

Pour le moment, aucune de ces primitives n'est supporté par appleseed. Les surfaces de subdivisions seront probablement implémentées en priorité, mais je ne peux pas te dire exactement quand ce chantier sera attaqué étant donné la quantité d'autres fonctionnalités "prioritaires" :)

Nous prévoyons de supporter des plugins natif (C++) qui permettraient, entre autre, d'injecter de la géométrie (polygonale) dans appleseed, au moment du rendu. Il deviendrait alors assez facile de supporter au moins les primitives de base...

Franz

5. Le mercredi 7 août 2013 à 23:36, par Natacha :

En lisant « Solides de base » je comprends la même chose que « Quadrics » (cône, sphère, disque, hyperboloïde, etc, avec le tore même si en vrai c'est une surface du quatrième ordre). J'utilise surtout ça et des NURBS, et si la CSG était disponible dans Pixie je m'en servirais pas mal aussi (ça m'aurait évité de calculer (sur papier) les paramètres d'une NURBS pour faire l'intersection d'une sphère et d'un cube pour représenter un dé).

src/appleseed/renderer/modeling/object/ me donne l'impression d'être prêt à recevoir de nouvelles sortes d'objets, mais object.h ne décrit pas vraiment ce qu'il est nécessaire de développer pour introduire un nouveau type d'objets.

Si c'est aussi facile que dans LuxRender, je me sentirais tout à fait capable de me lancer dans des patchs pour ajouter ces primitives à Appleseed. À l'inverse, s'il est nécessaire de développer une tesselation intelligente des primitives et les interfacer un peu partout dans la base de code, ça devient insurmontable pour quelqu'un qui découvre.

Et tout ça, c'est en supposant que l'architecture d'Appleseed soit capable d'encaisser un grand nombre d'objets simples (quelques milliers d'hexaèdres dans quelque chose d'aussi basique que [http://instinctive.eu/dessins/00A-la-majeur]) alors que le format actuel favorise un petit nombre d'objets complexes. Si ce n'est pas le cas, il faut en plus trouver un moyen de construire des objets rassemblant plein de primitives, et ça devient de l'ingénierie logicielle qui n'est pas évidente.

Bref, j'ai très envie de proposer ma main d'œuvre pour faire avancer cette interface dont j'aurais besoin, mais j'ai peur que ça se révèle hors de ma portée.

6. Le jeudi 8 août 2013 à 10:24, par Franz :

Je ne sais pas si c'est bien l'endroit idéal pour aborder ces questions techniques, mais je peux quand même te donner une idée de la façon dont tu pourrais ajouter des primitives géométriques à appleseed.

Comme je le disais dans un post précédent, appleseed ne supporte pour le moment que les tessellations triangulaires "statiques" : les surfaces doivent être tessellées à l'avance, de façon non-adaptative (rien n'empêche pour autant de tesseller moins finement un objet qui ne sera jamais vu de prêt). Il y a de bonnes raisons justifiant ce choix, particulièrement en animation où la tessellation adaptative pourrait générer des artifacts d'une frame à l'autre, quelque chose qu'on essaye d'éviter à tout prix.

Un objet appleseed doit donc pouvoir retourner sa tessellation quand on lui demande : c'est ce que fait la méthode virtuelle renderer::Object::get_region_kit(). Une région c'est une tessellation triangulaire, c'est-à-dire un ensemble de triangles. Un "region kit" c'est simplement une collection de régions (il est important que les tessellations ne puissent être évaluées que partiellement, d'où le découpage en régions).

La bonne façon de faire serait donc d'ajouter un nouveau type d'objet, par exemple renderer::QuadricPatch, qui dériverait de renderer::Object. Il faudrait également créer une nouvelle classe pour représenter une région d'une quadrique, par exemple renderer::QuadricRegion, qui implémenterait l'interface renderer::IRegion. Dans un premier temps on pourrait considérer que le patch entier soit tessellé en une seule région, donc renderer::QuadricObject::get_region_kit() renverrait un region kit ne contenant qu'une seule région (de type renderer::QuadricRegion).

La méthode renderer::QuadricRegion::compute_local_bbox() devrait calculer la boîte englobant la région (dans l'espace de l'objet) et la méthode renderer::QuadricRegion::get_static_triangle_tess() devrait calculer et retourner la tessellation de l'objet en triangles.

C'est à peu près tout. Il faudrait ensuite permettre de créer ce nouveau type d'objet depuis un fichier de scène (*.appleseed) mais c'est quelque chose donc je peux m'occuper.

Je serais prêt à te filer un coup de main et à te guider si c'est un projet qui t'intéresse.

Franz

7. Le jeudi 8 août 2013 à 10:28, par Franz :

Pour répondre à ta question:

> Et tout ça, c'est en supposant que l'architecture d'Appleseed soit capable d'encaisser un grand nombre d'objets simples

Oui, appleseed est architecturé pour supporter un nombre extrème de primitives de façon la plus efficace possible. Plusieurs dizaines de millions de triangles ne posent aucun problème particulier si la machine possède assez de RAM, et les temps de rendu ne devraient pas être fondamentalement affectés.

Franz

8. Le jeudi 8 août 2013 à 20:53, par Natacha :

Ce n'est effectivement pas l'endroit idéal pour ça, non pas au risque de gêner le peu de lecteurs qui hantent ces pages, mais parce que ces informations méritent une audience plus large. Je vais brièvement répondre pour clore les points en cours, et la suite sera sur appleseed-dev ou par e-mail personnel, suivant votre préférence.

De cette description, je me sens capable de me lancer dans l'écriture de ces nouveaux objets, après avoir comblé (ou au moins défriché) deux prérequis : d'une part le modèle mathématique représenté par la tesselation (ce n'est visiblement pas seulement un tas de triangles, il y a au moins une interpolation des normales, et peut-être des choses en plus pour limiter les coins aux bords des objets), et d'autre part les algorithmes typiques de tesselation (je sais décrire mathématiquement toutes ces surfaces, mais j'imagine qu'une tesselation naïve ferait retomber dans des pièges déjà résolus moult fois).

Autrement, je continue de penser qu'une tesselation adaptative suffisamment intelligente est compatible avec l'animation, par exemple celle de Pixie en mode REYES qui génère des triangles suivant leur surface apparente (en visant une fraction de pixel). Je me doute bien qu'avec les techniques de rendu plus élaborées ce n'est pas aussi facile, et je ne serais pas tellement surprise si mon « suffisamment intelligente » n'est pas réalisable.

Je reste quand même peu confortable vis-à-vis d'une tesselation statique, j'aurais préféré que tout soit réduit à des éléments moins grossiers (mais peut-être les triangles d'Appleseed sont-ils moins plats que je ne le crains ?)

Enfin pour l'architecture, j'avais bien vu les objectifs de triangles nombreux (avec il me semble dans la roadmap la gestion de plus de triangles que ne peut en contenir la RAM). Je m'interrogeais sur les objets en eux-mêmes, parce que suivant l'overhead d'un objet, il peut-être possible d'avoir 100 objets d'un million de triangles chacun mais pas cent mille objets de dix triangles chacun.

D'ailleurs justement le schéma Objet → Région → Triangles plaide pour un changement d'ordre de grandeur à chaque étape, donc il n'est pas évident du tout qu'un million d'objets « Cube » soient gérables avec cette architure qui appelle tous ces triangles à être rassemblés dans des régions d'un même object.

Cela étant, comme dit mon besoin c'est essentiellement une interface RenderMan, et les problèmes que je soulèverais peut-être auraient de toute façon finis par se poser.

9. Le mardi 13 août 2013 à 22:16, par Franz :

Excellente idée que de continuer sur appleseed-dev.

Pour répondre quand même à quelques points que tu soulèves :

> Autrement, je continue de penser qu'une tesselation adaptative suffisamment intelligente est compatible avec l'animation [...] Je me doute bien qu'avec les techniques de rendu plus élaborées ce n'est pas aussi facile [...]

C'est bien sûr vrai, c'est ce que font PRMan (RenderMan), mental ray et d'autres moteurs utilisés en animation. Cela dit les choses se compliquent nettement quand on considère non plus seulement les surfaces directement visibles (comme c'est le cas dans l'algorithme REYES traditionnel), mais qu'on s'intéresse aux réflexions raytracées, à la réfraction, ou à l'illumination globale. Par exemple, si l'on place une lentille grossissante devant la caméra dans un moteur de raytracing, des critères de finesse de tessellation simples comme les distances surfaces-caméra ne suffisent plus.

Pixar a montré que ces problèmes sont résolubles, par exemple en employant un cache de tessellation multirésolution. Deux autres approches sont envisageable : (1) la plus simple consiste à tesseler les surfaces de façon uniforme selon des critères de finesse choisis par l'utilisateur, en prenant soin de conserver la même tessellation au cours d'une animation pour éviter toute incohérence d'une frame à l'autre; (2) une solution plus élaborée consiste à calculer les intersections rayons-surfaces directement, sans tessellation, de façon analytique quand c'est possible, où par approximations numériques successives quand ça ne l'est pas. Un certain nombre de papiers ont été publiés à ce sujet. Je n'ai pas réellement commencé à investiguer mais ça me semble être l'approche la plus désirable pour au moins un certain nombre de surfaces (et de courbes).

L'approche (1) est immédiatement utilisable dans appleseed. L'approche (2) requiert un certain nombre de développements pour que le noyau d'intersection puisse supporter les surfaces non-tessellées.

> Je reste quand même peu confortable vis-à-vis d'une tesselation statique, j'aurais préféré que tout soit réduit à des éléments moins grossiers (mais peut-être les triangles d'Appleseed sont-ils moins plats que je ne le crains ?)

Les triangles d'appleseed sont plutôt plats :) Par contre tu peux spécifier une normale à chaque vertex pour simuler une surface lisse.

> Enfin pour l'architecture, j'avais bien vu les objectifs de triangles nombreux (avec il me semble dans la roadmap la gestion de plus de triangles que ne peut en contenir la RAM). Je m'interrogeais sur les objets en eux-mêmes, parce que suivant l'overhead d'un objet, il peut-être possible d'avoir 100 objets d'un million de triangles chacun mais pas cent mille objets de dix triangles chacun.

Dans le cas où la scène entière tient en mémoire, l'overhead par objet est minimal : les performances seront sensiblement les mêmes pour 100 objets d'un million de triangles ou un million d'objets de 100 triangles. Dans le cas où la scène totale est trop volumineuse, il sera nécessaire d'architecturer la scène de façon un peu différente pour qu'appleseed puisse décider à chaque instant quels objets doivent être en mémoire et quels objets doivent être temporairement écartés; cela à un coût essentiellement logarithmique en fonction du nombre total d'objet dans la scène.

---

J'aimerai assez rapidement ajouter le support de plugins dans appleseed. Cela te permettrait, si ça t'intéresse, de définir de nouvelles primitives et d'implémenter tes algorithmes de tessellation assez facilement (et avec un minimum de C++ !) sans avoir à se préoccuper trop de comment fonctionne le noyau de rendu, tout en profitant automatiquement de toutes les autres fonctionnalités.

Si tu gardes un oeil sur appleseed-dev, tu seras informée quand le support des plugins sera disponible.

Franz

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.