Page suivante Page précédente Table des matières

8. Divers

Cette section contient toutes les informations sur Ayam qui ne s'intègrent pas dans les autres sections principales.

8.1 Le système d'annulation (undo)

À l'aide du système d'annulation, les erreurs commises lors de la modélisation peuvent être corrigées.
Notez que seules les modifications d'objets peuvent être annulées. Cela inclut les modifications effectuées par des actions de modélisation interactives, les modifications effectuées à l'aide d'interfaces graphiques de propriétés, mais aussi les modifications de vues (modifications de type ou de paramètres de la caméra associée à une vue, sauf si elles sont explicitement désactivées à l'aide de l'attribut de vue "EnableUndo").
Il n'est pas possible actuellement d'annuler toute modification de la hiérarchie des objets, y compris le presse-papiers (par exemple, couper, coller) et les opérations de glisser-déposer. Si un objet est supprimé, il disparaît ! Si un objet est, accidentellement, déplacé par glisser-déposer, l'annulation n'aidera pas.

Le système d'annulation fonctionne en stockant des copies des différents états des objets modifiés dans un tampon d'annulation. Il est possible de reculer dans les états sauvegardés en utilisant <Ctrl+z> (annuler) mais aussi d'avancer en utilisant <Ctrl+y> (refaire).

L'espace de stockage occupé par le tampon d'annulation peut être ajusté en utilisant l'option de préférences "Modeling/UndoLevels". Une valeur de 0 désactive complètement le système d'annulation.[∗] La valeur 1 signifie qu'il y a toujours un état de la scène qui peut être restauré, et qu'une opération d'annulation potentielle peut aussi toujours être annulée en utilisant la fonction "redo".

Les modifications qui seraient annulées ou refaites sont affichées sous forme abrégée dans l'invite par défaut de la console de Ayam et également dans les entrées du menu principal "Edit/Undo" et "Edit/Redo".[∗]

Plusieurs actions permettent de vider complètement le tampon d'annulation (c'est-à-dire qu'aucune annulation n'est possible après l'une de ces actions) : Nouvelle scène, Ouvrir (remplacer) la scène et Fermer la vue.

En outre, les opérations d'annulation/rétablissement modifieront également les objets qui résident dans le presse-papiers des objets (s'ils ont enregistré des états dans le tampon d'annulation). Cela signifie que la séquence d'opérations suivante conduit à une sphère placée à "0,0,0" :


create Sphere (at 0,0,0)
move Sphere (to 1,1,0)
cut Sphere (vers le presse-papier)
undo
paste Sphere (du presse-papier)

8.2 Le concept de modélisation outils-objets

Cette section présente le concept de modélisation Tool-Objects, tel qu'il est utilisé dans Ayam.

Dans une application de modélisation standard, pour créer une surface de révolution, on pourrait soit créer d'abord une courbe puis appeler l'outil de révolution pour obtenir une surface appropriée (en perdant la courbe comme objet, ou même en la conservant, mais sans relation avec la surface), soit appeler d'abord l'outil de révolution, ce qui obligerait alors l'utilisateur à tracer une courbe avec des résultats similaires : la surface créée perdra généralement la relation avec l'outil de révolution et la courbe (même si elle est conservée intacte) perdra la relation avec la surface. Il n'y a pas de moyen facile de modifier les paramètres de création de la surface ou de changer la géométrie de la courbe plus tard sans tout recommencer.

Le concept de modélisation Tool-Objects surmonte ces inconvénients en transformant la révolution tool en une scène objet.

L'exemple de hiérarchie suivant montre deux objets dans une relation parent-enfant :

+-Tool_Object(Revolve)
 |         ^
 |         :
 |   <Notification>
 |         :
 \ Parameter_Object(NCurve)
L'objet parent est appelé Tool_Object et l'objet enfant est appelé Parameter_Object. Il y a un flux d'informations de l'objet paramètre vers l'objet outil. Ce flux d'informations est contrôlé par le mécanisme appelé Notification. Le mécanisme de notification veille à ce que chaque fois que les objets paramètres changent, l'objet outil soit informé afin qu'il puisse s'adapter aux changements. Pour les actions de modélisation interactives, la notification sera effectuée en faisant glisser la souris ou après avoir relâché le bouton de la souris (c'est-à-dire après la fin de l'action de modélisation), en fonction du paramètre de préférence principal "LazyNotify".

Dans l'exemple ci-dessus, une courbe NURBS est l'objet paramètre et l'objet outil crée une surface de révolution à partir des données de la courbe. La courbe NURBS et les paramètres de l'objet Revolve peuvent changer à tout moment. Lorsqu'ils sont enregistrés dans un fichier de scène Ayam, aucune donnée de surface ne sera écrite, ce qui conduit à de très petits fichiers qui contiennent en outre un historique de modélisation et capturent l'intention de conception jusqu'à un certain point.

Les objets-outils peuvent être des objets paramètres d'autres objets-outils :

+-Tool_Object(ExtrNP)
 +-Parameter_and_Tool_Object(Revolve)
  \ Parameter_Object(NCurve)
et il peut y avoir plus d'un objet paramètre par objet outil :
+-Tool_Object(Skin)
 | Parameter_Object_1(NCurve)
 | Parameter_Object_2(NCurve)
 | ...
 \ Parameter_Object_n(NCurve)

Les objets outils créent de nouveaux objets géométriques à partir des informations fournies par le ou les objets paramètres ou modifient le ou les objets paramètres et les transmettent à leur objet parent respectif.

Le schéma de dépendance purement hiérarchique peut être décomposé par des objets d'instance :

+-Tool_Object(Revolve)
 \ Parameter_Object(NCurve) --------------.
+-Tool_Object(Revolve)                    | !
 \ Parameter_Object(Instance_of_NCurve) <-'
Dans la scène ci-dessus, le deuxième objet outil Revolve dépend de la forme du premier objet paramètre. L'objet Instance transporte les données d'une partie de la hiérarchie à une autre. Le mécanisme de notification en est conscient et lance des mises à jour dans la hiérarchie de la scène chaque fois que nécessaire et de manière efficace (en ne mettant pas deux fois à jour les objets) selon le paramètre de préférence principal "CompleteNotify". Dans l'exemple ci-dessus, grâce à la notification complète, le deuxième objet Revolve sera automatiquement mis à jour à chaque fois que l'objet NCurve original change.

Deux autres mécanismes existent, qui aident les objets outils à obtenir les informations dont ils ont besoin et à accroître la flexibilité dans la construction de la hiérarchie et la modélisation : Provision et Conversion. Ces deux mécanismes sont assez similaires et convertissent les objets de manière temporaire/transparente (provision) ou définitive (conversion) d'un type à un autre, par exemple ils convertissent une ICurve (courbe d'interpolation) en une NCurve simple (courbe NURBS).

Grâce au mécanisme de provisionnement, un objet ICurve pourrait être utilisé à la place d'une NCurve comme objet paramètre dans tous les exemples ci-dessus facilement. Et grâce au mécanisme de conversion, les objets de l'outil Revolve pourraient être convertis en objets NPatch simples (par exemple pour des opérations de modélisation non disponibles pour les objets Revolve).

Notez que les objets d'instance sont soumis à une deuxième série de dispositions, c'est-à-dire que le maître n'a pas besoin d'être du type recherché mais plutôt de fournir le type recherché.

Même si, théoriquement, chaque outil pourrait être mis en oeuvre en tant qu'objet outil, cela n'a pas été fait dans Ayam (principalement parce que cela augmenterait inutilement la base de code). Seuls les outils les plus souvent utilisés qui transmettent et capturent une grande partie de l'intention de conception ont été implémentés en tant qu'objets-outils (ce sont les outils de création de surfaces ou de courbes). Mais les outils rarement utilisés peuvent être élevés à un niveau de capacités d'objets-outils presque complet grâce à l'utilisation du concept d'objets de script (voir la section L'objet Script).

Cela peut être fait facilement, par exemple en créant des objets de script de type "Modify" qui appellent ces outils à partir de leur script (après une éventuelle conversion du ou des objets fournis en un type approprié, l'outil peut avoir besoin de fonctionner dessus). Il est même possible d'ajouter des interfaces graphiques de propriété pour permettre à l'utilisateur d'ajuster les paramètres de l'outil tels qu'il les connaît à partir des autres objets Ayam et de combiner différents outils dans des objets uniques avec du code de script normal pour une flexibilité inégalée. Mais voyons d'abord un exemple simple :

+-Skin
 +-Script
  \ ExtrNC
Dans la hiérarchie des scènes ci-dessus, l'objet Script pourrait simplement inverser la courbe extraite avec un code comme celui-ci :
convOb -inplace; revertC

élevant effectivement l'outil "revertC" au rang d'objet.

Un exemple plus utile se trouve dans l'exemple de scène de Marsrakete (disponible sur la page d'accueil de Ayam). Ici, une courbe extraite d'un patch est coupée à la bonne longueur à l'aide d'un script comme celui-ci :


convOb -inplace; trimNC 0.0 0.5

. Voir la section Exemple de ligne paramétrique pour savoir comment ce script peut être étendu pour prendre en charge une interface graphique et davantage de vérifications d'erreurs.

8.3 Gestion des fichiers de scène

Cette section contient des informations exhaustives sur ce qui se passe exactement, lorsque Ayam lit ou écrit un fichier de scène.

Ouvrir une Scène

Lors de la lecture d'une scène en utilisant " File/Open " ou la liste MRU (la plus récemment utilisée) :

  1. Ayam va d'abord vérifier l'état de changement de scène de la scène actuellement chargée et avertir l'utilisateur, si la scène actuelle contient des changements non sauvegardés,
  2. puis Ayam effacera le tampon d'annulation et la scène en cours (le contenu du presse-papiers n'est pas touché, sauf par exemple les objets, dont les maîtres sont effacés avec la scène : ces objets d'instance seront supprimés du presse-papiers),
  3. si le nouveau fichier ne semble pas être un fichier de scène Ayam (jugé uniquement par l'extension du nom du fichier) Ayam essaiera d'importer le fichier en utilisant un plugin d'importation responsable du fichier (chargeant automatiquement le plugin correspondant s'il n'est pas déjà chargé),
  4. Ayam va changer le répertoire de travail de l'application pour le répertoire du fichier de scène,
  5. maintenant, une copie de sauvegarde du fichier à lire sera faite (selon le réglage des préférences "Main/BakOnReplace"), une ancienne copie de sauvegarde potentiellement existante sera écrasée sans notification, note : même si la sauvegarde échoue, la lecture de la scène continue,
  6. l'en-tête du fichier de scène sera lu pour en déduire la version du format du fichier de scène,
  7. le fichier sera lu avec tous les objets, *
  8. toutes les instances seront connectées à leurs maîtres à l'aide des informations stockées dans les balises "OI" ; si un maître ne peut être trouvé dans la scène, le ou les objets d'instance respectifs seront supprimés,
  9. tous les objets seront connectés à leurs matériaux à l'aide des informations stockées dans les balises "MI" ; si aucun matériau correspondant ne peut être trouvé, la connexion ne sera pas établie,
  10. une notification complète sera effectuée,
  11. si le fichier contient un objet Root avec des balises "SaveMainGeom" et/ou "SavePaneLayout", les géométries respectives des fenêtres/ widgets des balises seront rétablies,
  12. si aucune erreur n'est survenue lors de la lecture, le nom de la scène en cours sera défini comme celui du fichier, sinon le nom de la scène en cours sera réinitialisé à " unnamed " (pour éviter d'encombrer de bons fichiers de scènes qui n'ont pas pu être chargés pour une raison quelconque avec une seule pression, peut-être même involontaire, de <Ctrl+s>),
  13. le nom du fichier sera mis à la première entrée du menu fichier la plus récemment utilisée,
  14. l'état de changement de scène sera remis à " unchanged ",
  15. si un objet Root a été lu, un drapeau de sauvegarde des vues sera activé, sinon il sera effacé et les opérations de sauvegarde suivantes ne permettront pas de sauvegarder la racine et les vues (c'est-à-dire que les fichiers de scène sans racine et les vues restent des fichiers de scène sans racine et sans vues, même si de nouvelles vues sont ouvertes et paramétrées).
* en lecture d'objets à partir d'un fichier :
  1. si un objet de vue est lu, une nouvelle fenêtre de vue sera ouverte (sauf pour les trois premiers objets de vue en mode GUI à fenêtre unique, où seule la configuration des objets de vue lus sera copiée sur les objets de vue déjà existants des trois vues internes),
  2. si un objet est d'un type actuellement indéfini (c'est-à-dire défini par un plugin), Ayam dérivera un nom de plugin potentiel à partir du nom du type d'objet et tentera de charger le plugin, puis la lecture de la scène se poursuivra,
  3. si un objet matériau est lu, Ayam l'enregistrera immédiatement ; si cet enregistrement échoue (parce qu'il y a déjà un matériau avec ce nom enregistré ; ce matériau peut seulement être dans le presse-papiers, car tous les autres objets ont été supprimés avant l'ouverture du fichier), le nouvel objet matériau sera renommé en ajoutant un numéro et l'enregistrement est tenté à nouveau, ces étapes seront répétées jusqu'à ce qu'elles réussissent (avant la version 1.21, Ayam n'essayait pas de renommer le matériau et d'autres objets étaient alors connectés au matériau déjà existant),
  4. si le chargement d'un objet échoue, Ayam passe à l'objet suivant et continue à lire à partir du fichier.

Insérer une scène

Contrairement à la lecture des scènes via " File/Open " ou la liste MRU, la lecture des scènes via " File/Insert " fait certaines choses différemment :

  1. la scène actuelle ne sera pas effacée avant la lecture du fichier,
  2. le niveau actuel ne sera pas réinitialisé avant la lecture du fichier ; si le fichier de scène à insérer ne contient ni racine ni vues, les nouveaux objets seront créés dans le niveau actuel, sinon les objets seront créés dans le niveau le plus élevé de la scène, qui sera aussi le nouveau niveau actuel dans tous les cas (après la lecture),
  3. aucune copie de sauvegarde ne sera faite du fichier à insérer,
  4. si un matériau est manquant dans le fichier, et qu'un matériau correspondant (par son nom) existe dans la scène, les objets seront reliés à ce matériau,
  5. les fenêtres de vue seront ouvertes pour chaque objet de vue lu (les vues internes ne seront pas modifiées),
  6. le répertoire actuel ne sera modifié que pendant l'opération de lecture du fichier,
  7. si un objet matériau est lu, Ayam l'enregistrera immédiatement ; si cet enregistrement échoue (parce qu'il y a déjà un matériau avec ce nom enregistré), le nouvel objet matériau sera renommé en ajoutant un numéro et l'enregistrement est tenté à nouveau, ces étapes seront répétées jusqu'à ce qu'elles réussissent ; avant la version 1.21, Ayam n'essayait pas de renommer le matériau et d'autres objets étaient alors reliés au matériau déjà existant,
  8. le nom de fichier actuel ne sera pas modifié,
  9. la scène a changé d'état sera réglée sur " changed ",
  10. l'indicateur de sauvegarde des vues ne sera pas modifié, ce qui signifie que l'insertion d'un fichier de scène sans vues dans une scène vide (par exemple directement après le démarrage de l'application ou après " File/New ") puis la sauvegarde de la scène, enrichiront le fichier de scène avec la racine et les vues (contrairement au chargement de cette scène via " File/Open ").

Sauvegarder une scène

Lors de la sauvegarde d'une scène à l'aide de "File/Save":

  1. Ayam vérifiera d'abord le nom du fichier de la scène en cours, si le nom est "unnamed", un nouveau nom de fichier sera demandé,
  2. si le fichier ne semble pas être un fichier de scène Ayam (jugé uniquement par l'extension du nom du fichier) Ayam essaiera d'exporter la scène actuelle en utilisant un plugin d'exportation responsable du type de fichier au lieu de l'enregistrer dans un fichier de scène Ayam (en chargeant automatiquement le plugin correspondant s'il n'est pas déjà chargé),
  3. la géométrie de la fenêtre principale et des widgets internes est enregistrée dans les balises "SaveMainGeom" et/ou "SavePaneLayout" (si présentes dans l'objet Root), Les balises
  4. "OI" et "MI" seront créées pour permettre aux instances d'être connectées à leurs maîtres respectifs et aux objets à leurs matériaux, lors de la relecture du fichier de scène,
  5. alors, tous les objets de la scène seront enregistrés dans le fichier ; si l'indicateur d'enregistrement des vues a été effacé lors de la lecture du fichier de scène précédent, la racine et les vues seront omises (c'est-à-dire que les scènes sans racine et sans vues restent des scènes sans racine et sans vues, même si de nouvelles vues ont été ouvertes et paramétrées pendant le chargement de la scène),
  6. si aucune erreur ne s'est produite lors de l'écriture de la scène, le nom du fichier sera placé dans la première entrée de fichier la plus récemment utilisée dans le menu fichier (en fonction également du paramètre de préférence "SaveAddsMRU"), et l'état de changement de la scène sera réglé sur " unchanged ",
  7. si des erreurs se sont produites, l'état de changement de la scène actuelle sera conservé.

8.4 Le fichier Ayamrc

Pour personnaliser Ayam au-delà des capacités du dialogue des préférences, le fichier ayamrc peut être utilisé. Ce fichier est soit pointé par la variable d'environnement AYAMRC ou est déterminé comme suit :

Le fichier ayamrc est lu à chaque démarrage de Ayam et enregistré à nouveau à la sortie (si le paramètre de préférence "Main/AutoSavePrefs" est activé).

Le fichier ayamrc contient :

  1. paramètres de préférence (y compris certains paramètres cachés qui ne nécessitent qu'un réglage occasionnel et ne sont pas accessibles à l'aide de l'éditeur de préférences de l'interface graphique),
  2. position et taille de la fenêtre principale et de la fenêtre de la boîte à outils,
  3. position et taille des différentes fenêtres de dialogue (si le paramètre de préférence "SaveDialogGeom" est défini en conséquence),
  4. Raccourci clavier pour les entrées de menu et les actions de modélisation,
  5. Bases de données RiOption et RiAttribute.
Vous pouvez modifier le fichier avec n'importe quel éditeur de texte (pendant que Ayam n'est pas en cours d'exécution), mais gardez à l'esprit que le fichier sera analysé par Tcl. Si, pour une raison quelconque, vous détruisez votre fichier ayamrc de sorte que Ayam ne démarre plus correctement, vous pouvez toujours lancer Ayam avec l'option de ligne de commande "-failsafe". Lorsque vous quittez l'application la fois suivante, ou que l'entrée du menu principal "File/Save Prefs" est invoquée, un fichier ayamrc correct sera à nouveau créé. Tous les paramètres des préférences seront réinitialisés aux valeurs par défaut et toutes vos modifications du fichier ayamrc seront toutefois perdues.

Une autre façon de réinitialiser le fichier ayamrc consiste à supprimer simplement le fichier manuellement ou en utilisant l'entrée du menu principal "Special/Reset Preferences".

Pour réinitialiser les éléments individuels aux valeurs par défaut, il suffit de supprimer les lignes correspondantes dans le fichier ayamrc.

Enfin, la réinitialisation des préférences individuelles sans éditeur de texte est également possible à l'aide de l'interface de script en manipulant le tableau global "ayprefs". L'exemple suivant conduit à une réinitialisation du paramètre de préférence de tolérance à sa valeur par défaut pour le prochain démarrage de Ayam.

» unset ayprefs(Tolerance)
Après avoir supprimé certains éléments du tableau des préférences, Ayam doit être relancé.

Changement des raccourcis clavier

Vous pouvez adapter les raccourcis clavier utilisés dans l'interface graphique à vos besoins particuliers en utilisant le fichier ayamrc. Notez que si vous faites cela, l'interface graphique (les entrées de menu et la fenêtre "Show Shortcuts") s'adaptera à vos changements mais certainement pas cette documentation, ni la carte de référence (à moins qu'elle ne soit recréée à l'aide du script "refcard.tcl"), ni les tutoriels.

Ayam fait ne fait pas de contrôle sur les conflits dans les raccourcis clavier. Cela signifie que la dernière liaison définie pour une clé sera utilisée.

Sous Unix, la sortie du programme "xev" et la page de manuel de la commande "bind" de Tk fournissent des informations utiles sur les chaînes qui peuvent être utilisées pour décrire les pressions sur les touches. Vous pouvez également utiliser directement la console Ayam pour déduire les noms de clés, entrez simplement:

» toplevel .keytest; bind .keytest <Key> {puts %K}
dans la console Ayam. Vous pouvez maintenant activer la nouvelle fenêtre de niveau supérieur et taper sur votre clavier pendant que la console Ayam imprime les noms des touches.

Pour plus de commodité, la chaîne spéciale "Ctrl" sera remplacée par "Control" avant qu'un raccourci ne soit transmis à la commande bind.

Exemple :


set aymainshortcuts(Prefs) {Ctrl-p}

définit le raccourci clavier pour l'ouverture de l'éditeur de préférences à <Ctrl+p>. Voir le fichier ayamrc lui-même pour une liste complète des raccourcis disponibles.

Paramètres de préférences cachés

Le fichier ayamrc contient actuellement les paramètres de préférences cachés ajustables suivants :

Base de données pour RiOption et RiAttributes

Avec le fichier ayamrc, la base de données des RiOptions et des RiAttributs peut également être adaptée au système de rendu RenderMan cible actuel.

Des options et des attributs spécifiques au restituteur peuvent ensuite être ajoutés aux scènes à l'aide de balises et des entrées du menu principal "Special/Tags/Add RiOption" et "Special/Tags/Add RiAttribute", Voir aussi les sections Balise RiAttribute et Balise RiOption.

La syntaxe pour une nouvelle RiOption est assez simple comme le montre l'exemple suivant :


set riopt(runtime) {
 { verbosity s { "silent" "normal" "stats" "debug" } }
}

Cet extrait définit la section "runtime" et y ajoute une seule option, " verbosity". L'option est déclarée comme étant de type chaîne de caractères en utilisant "s" et est fournie avec une liste de valeurs par défaut : "{ "silent" "normal" "stats" "debug" }". Pour ajouter une autre option à cette section, disons l'option "op" qui doit être une valeur entière, l'extrait susmentionné doit être changé en :
set riopt(runtime) {
 { verbosity s { "silent" "normal" "stats" "debug"} }
 { op i }
}

Comme vous pouvez le voir, il n'est pas obligatoire de fournir des valeurs par défaut. Veillez à fermer correctement tous les croisillons, sinon le prochain départ de Ayam risque d'échouer. Les types de paramètres disponibles sont les suivants :

8.5 Variables d'environnement

Cette section documente les variables d'environnement utilisées par Ayam.

8.6 Aperçu des plugins

Cette section donne un aperçu des différents plugins disponibles dans Ayam.

Il existe actuellement cinq grands types de plugins pour Ayam :

plugins d'analyse des ombres

aysdr, ayslb, ayslc, ayslo, ayslo3d, ayslx, ayso. Voir aussi la section Plugins d'analyse des ombres (shaders).

objets personnalisés

metaobj, sdnpatch, sfcurve, sdcurve, bcurve, csphere. Voir aussi la section Gestion des objets personnalisés.

plugins d'import/export

dxfio, mfio, mopsi, objio, onio, rrib, x3dio. Voir aussi la section Importations et Exportations.

plugins de langage de script

plugins d'aide à la modélisation

8.7 Plugins d'analyse des ombres (shaders)

Les plugins suivants sont fournis pour permettre l'analyse des ombres compilées :[∗] "ayslb" pour Air, "ayslx" pour Aqsis, "ayso" pour RDC, "ayslo" pour PRMan, "ayslo3d" pour 3Delight, "aysdr" pour Pixie[∗] , and "aygso" pour Gelato[∗].

Après le chargement de l'un des plugins susmentionnés, Ayam sera en mesure d'analyser les ombres compilées avec le compilateur d'ombres du moteur de rendu respectif.

Il ne peut y avoir qu'un seul plugin d'analyse d'ombre actif. Vous ne pouvez pas charger d'abord ayslb puis ayslx et vous attendre à ce qu'Ayam analyse les ombres slb et slx.

Un plugin d'analyse d'ombre peut être chargé automatiquement au démarrage de Ayam en utilisant l'un des scripts Tcl fournis : "loadayslb.tcl", "loadayslo.tcl", "loadayslo3d.tcl", "loadayslx.tcl", "loadayso.tcl", "loadaysdr.tcl", et "loadaygso.tcl". Pour charger automatiquement un plugin, il suffit d'ajouter le script approprié au paramètre de préférence "Main/Scripts" en utilisant le bouton "Add" dans l'éditeur de préférences.

En outre, ces scripts peuvent être adaptés pour définir un paramètre de préférence "Shaders" différent ou pour rechercher immédiatement les ombres après le chargement du plugin. Pour cela, il suffit d'enlever les marques de hachage (#) des lignes correspondantes dans le script. Notez qu'il n'est pas nécessaire de modifier les scripts pour l'analyse immédiate des ombres si le plugin d'analyse des ombres est chargé automatiquement au démarrage de Ayam, car le chargement des scripts (et donc aussi du plugin) se fera avant que la séquence de démarrage de Ayam n'exécute la passe initiale d'analyse des ombres. Le chemin de recherche des ombres utilisé pour la première passe d'analyse des ombres est pris dans le paramètre de préférence "Shaders".

Si un plugin d'analyse des ombres est chargé manuellement ou via un script de chargement inchangé, le chemin de recherche des ombres doit être adapté manuellement. En outre, une analyse des ombres doit également être lancée manuellement. Les deux actions peuvent être effectuées à l'aide de l'éditeur de préférences. La recherche des ombres peut également être lancée à l'aide du menu principal : "Special/Scan Shaders".

Afin de mieux s'adapter à l'évolution rapide des outils de rendu RenderMan, depuis Ayam 1.11, tous les plugins d'analyse des ombres sont indépendants de la version de Ayam (mais dépendent toujours de la version du moteur de rendu et de la version Tcl). Cela permet de distribuer des plugins d'analyse des ombres mis à jour sans mettre à jour Ayam également et donc à une fréquence plus élevée. De plus, la compilation d'un plugin d'analyse des ombres est maintenant beaucoup plus facile.

Pour l'analyse des ombres sans plugins, Voir aussi la section Analyse des ombrages (shaders).

8.8 Instanciations automatiques

Dialogue d'instanciation automatique

Automatic Instancing est disponible via l'entrée du menu principal : "Special/Instances/Automatic Instancing". Lorsque cette entrée de menu est sélectionnée, un petite boite de dialogue de paramètres apparaît, voir aussi l'image ci-dessus.

Automatic Instancing crée des instances à partir de tous les objets instanciables en utilisant un algorithme simple qui compare récursivement les objets (Voir aussi la section L'objet Instance).

Deux objets sont considérés comme instanciables lorsque tous leurs attributs, à l'exception des attributs de transformation, sont identiques. La comparaison des matériaux et des balises peut être désactivée. La portée de l'instanciation automatique peut également être définie sur les objets sélectionnés, le niveau actuel ou tous les objets de la scène (indépendamment du niveau actuel et de la sélection). [∗]

L'algorithme d'instanciation est également capable de créer des instances de regroupement d'objets (objets avec des objets enfants, par exemple des niveaux ou des outils-objets comme revolve). Toutefois, pour que deux objets de regroupement soient instanciés, non seulement tous les objets enfants et les objets de regroupement doivent être instanciables, mais les objets enfants doivent également être dans le bon ordre. Il ne suffit pas que pour chaque enfant du maître potentiel, il existe un enfant correspondant de l'instance potentielle. L'instanciation des objets de regroupement peut réduire considérablement le nombre total d'objets dans une scène.

Notez qu'avant que l'instanciation automatique ne commence, toutes les instances existantes seront résolues.
Après l'instanciation, certaines statistiques seront affichées dans la console.

Pour plus d'informations sur ce sujet, voir :

Schultz, R., and Schumann, H.: "Automatic Instancing of Hierarchically Organized Objects", in: Kunii T.L. (ed.): Spring Conference on Computer Graphics (SCCG 2001) Conference Proceedings, Budmerice, Slovakia, 25-28 April 2001, ISBN 80-223-1606-7

8.9 Rendu piloté par l'importance (Importance Driven Rendering IDR)

Le plugin de rendu piloté par l'importance peut être utilisé pour réduire considérablement les temps de rendu lors du développement d'une scène. Il fonctionne en trois étapes principales :

  1. Les valeurs d'importance sont attribuées aux éléments de la scène.
  2. Deux passes de restitution sont lancées en fonction des valeurs d'importance attribuées. Les éléments ayant des valeurs d'importance différentes sont masqués mutuellement à l'aide des instructions "RiMatte".
  3. Les images partielles résultantes sont composées en une seule image résultante, qui est ensuite affichée.
La paramétrisation des deux passes de rendu garantit que le temps de rendu total est inférieur au temps de rendu d'une seule passe de haute qualité.

De nombreuses options existent pour attribuer une importance et paramétrer les passes de restitution :

Les éléments des scènes peuvent être des objets géométriques, des régions dans l'espace image ou des régions dans l'espace objet. Les valeurs d'importance ne sont actuellement que des valeurs binaires. L'attribution peut se faire manuellement (à l'aide de balises IDR) ou de manière semi-automatique par dérivation de l'importance des objets actuellement sélectionnés ou modifiés. Pour éviter toute incohérence dans les images résultantes, les valeurs d'importance peuvent être propagées entre des objets proches (géométriquement ou hiérarchiquement), ou entre des objets qui sont liés (par exemple d'un matériau à un objet géométrique).

La paramétrisation des deux passes de rendu comprend actuellement la sélection d'un moteur de rendu différent et la possibilité de réduire la résolution de rendu et le taux d'ombrage. Pour réduire davantage les temps de rendu des moteurs de rendu de raytracing, la taille de la région à restituer peut être automatiquement adaptée aux éléments de la valeur d'importance actuelle (y compris une exécution d'optimisation qui équilibre les temps de démarrage du moteur de rendu et les temps nécessaires pour restituer les régions non occupées à l'origine par deux régions à fusionner).

De plus, la mise en cache d'images partielles est possible. Cependant, la mise en oeuvre de cette fonctionnalité n'est pas très sophistiquée pour le moment, car elle utilise l'outil texte Unix "diff" pour décider si deux flux RIB sont identiques et ne nécessitent donc pas de restitution. Pour commencer à utiliser l'IDR :

  1. charger une scène (par exemple, la scène de l'exemple de cactus),
  2. charger le plugin IDR (menu "File/Load Plugin"),
  3. ouvrir la fenêtre de contrôle de l'IDR en utilisant le menu principal "Custom/Open IDR",
  4. régler le mode d'affectation sur "Selection",
  5. sélectionner un objet dans la scène (par exemple l'objet nommé "Pot"),
  6. puis appuyez sur le bouton "Render !".
Comparez le temps de restitution avec un rendu complet à partir de la fenêtre de visualisation. L'IDR exige qu'au moins le créateur de la deuxième passe de rendu honore RiMatte. Comme l'IDR n'honore pas RiMatte, il est parfois nécessaire d'exclure simplement les objets de valeur d'importance différente. Il ne faut pas s'attendre à des images erronées, car rgl ne calcule que les effets d'éclairage locaux. Vous trouverez plus d'informations à ce sujet dans:

Schultz, R., and Schumann, H.: "Importance Driven Rendering - Using Importance Information in the Rendering Process", in: Hamza M., Sarfraz M. (ed.): Computer Graphics and Imaging (CGIM 2001) Conference Proceedings, Honolulu, Hawaii, 13-16 August 2001, ISBN 0-88986-303-2

8.10 Aperçu CSG à l'aide du plugin AyCSG

Exemple de prévisualisation de CSG (à gauche sans, à droite avec CSG)

Le plugin AyCSG peut être utilisé pour résoudre et prévisualiser les opérations du CSG. Pour cela, le plugin utilise des algorithmes de restitution CSG basés sur des images fournis par la bibliothèque OpenCSG de Florian Kirsch. La bibliothèque OpenCSG prend actuellement en charge les algorithmes Goldfeather et SCS. Ce dernier ne fonctionne correctement qu'avec des primitives convexes. Comme Goldfeather et SCS sont tous deux des algorithmes de restitution d'images, il n'y a pas de limite aux types d'objets géométriques qui peuvent être utilisés dans les hiérarchies CSG. Vous pouvez par exemple utiliser les Quadrics, NURBS et Metaballs dans toutes les combinaisons possibles. Vous devez juste vous assurer que chaque primitive CSG décrit un espace fermé.

Pour que les algorithmes de restitution CSG fonctionnent correctement, il faut connaître la complexité en profondeur (convexité) d'une primitive. La complexité en profondeur d'une primitive détermine le nombre maximum de surfaces orientées vers l'avant que tout rayon traversant cette primitive pourrait traverser. Une sphère régulière a une complexité de profondeur de 1, un tore de 2, mais ne confondez pas la complexité de profondeur avec le genre, ce sont des valeurs différentes. Une représentation 3D de la lettre A, par exemple, a un genre de 1 mais une complexité de profondeur de 3. La complexité de profondeur d'une primitive peut être stockée dans une balise "DC". Un tore obtiendrait par exemple une balise nommée "DC" avec la valeur "2". Si aucune balise "DC" n'est présente pour une primitive, une valeur par défaut pour la complexité de profondeur de "1" sera utilisée. Si la complexité de la profondeur n'est pas correctement spécifiée, des erreurs de restitution, comme des parties manquantes de surfaces, se produiront.

Notez que le bon fonctionnement de AyCSG dépend non seulement de la complexité de la profondeur mais aussi de l'ordre d'enroulement des primitives OpenGL (triangles ou quads) utilisées pour le dessin des primitives CSG. L'ordre d'enroulement doit être cohérent dans une scène, de sorte que l'algorithme de restitution puisse décider de ce qui est à l'intérieur et à l'extérieur en regardant une seule primitive OpenGL. Pour toutes les primitives quadriques de Ayam, l'ordre d'enroulement est toujours cohérent. Cependant, pour les patchs NURBS, l'ordre d'enroulement dépend de l'orientation des dimensions du patch. Si les patchs NURBS sont utilisés dans les opérations CSG, il peut être nécessaire de les inverser (par exemple en utilisant l'outil "RevertU", voir Outil de reversement sur U (Revert U)).

Si l'ordre d'enroulement de certaines des primitives dans une hiérarchie CSG n'est pas correct, les primitives respectives ne seront pas efficaces dans les opérations CSG dans la mesure où l'image restituée devient complètement vide.

Le rendu AyCSG obéit aux options d'affichage "Draw Selection only" et "Draw Level only" ainsi qu'à l'attribut "hide" des objets. Si le rendu CSG échoue pour des scènes complexes complètes, vous pouvez toujours obtenir un aperçu des CSG importantes en utilisant des objets en les sélectionnant et en activant l'option de vue "Draw Selection only".

Notez également que le rendu CSG nécessite une carte graphique rapide (plus le taux de remplissage est élevé, mieux c'est). De plus, votre sous-système OpenGL doit prendre en charge l'extension PBuffers et, selon les options de rendu choisies, un tampon de stencil. Des accélérations peuvent être obtenues en utilisant les extensions "GL_ARB_occlusion_query" ou "GL_NV_occlusion_query" (si vous en disposez).

Une fois que le plugin AyCSG est chargé avec succès, vous pouvez restituer l'aperçu CSG dans n'importe quelle fenêtre de visualisation en utilisant le raccourci clavier <Ctrl+C> ou en utilisant le nouveau bouton dans la barre de menu de chaque fenêtre de visualisation (voir image ci-dessous). Si vous maintenez la touche <Shift> enfoncée tout en appuyant sur le bouton, la vue commencera à restituer continuellement les CSG (le bouton reste enfoncé pour le signifier) jusqu'à ce que vous cliquiez à nouveau sur le bouton.

Voir avec l'icone AyCSG

Le plugin AyCSG prend en charge les options suivantes, qui sont disponibles via l'entrée du menu principal "Custom/AyCSG Preferences":

Le tableau suivant donne un aperçu des options disponibles, de leurs restrictions et des exigences implicites.

AlgorithmDCSamplingConcave PrimitivesDC Tags neededRequirements
GoldfeatherOcclusionQueryYesNoocclusion query extension
GoldfeatherDCSamplingYesNostencil buffer
GoldfeatherNoDCSamplingYesYesNone
AutomaticNoDCSamplingYesYesNone
SCSNoDCSamplingNoNoNone
SCSOcclusionQueryNoNoNone
SCSDCSamplingNoNostencil buffer

Aperçu des options de AyCSG

Les paramètres par défaut sont d'utiliser l'algorithme Goldfeather avec des requêtes d'occlusion, car cette combinaison permet des hiérarchies CSG complexes, dispose d'une prise en charge matérielle étendue, ne nécessite aucune modification des arguments de vue exotiques, et également aucune balise DC.[∗] Voir aussi : Kirsch F. and Doellner J.: "Rendering Techniques for Hardware-Accelerated Image-Based CSG", in: Skala V. (ed.): Journal of WSCG'04, 221-228, ISSN 1213-6972

8.11 Augmenter la vitesse de dessin

En cas de réponse lente de l'interface utilisateur de Ayam (ne tenant pas compte des longues opérations de mise à jour de l'arbre), plusieurs choses peuvent être faites pour augmenter la vitesse de dessin :

8.12 Modélisation sans vue

Pour travailler sur des scènes très grandes/complexes, il peut être nécessaire de désactiver toutes les vues. Dans Ayam, cela peut être fait en mode GUI multi-fenêtres (voir la section La sous-section suivante contient les paramètres relatifs à l'interface graphique utilisateur (GUI).).

S'il y a beaucoup d'objets, il est également conseillé de faire passer le widget de sélection des objets du mode arborescence au mode boîte de liste (menu : "Special/Toggle TreeView").

La modélisation sans vues ne fonctionne pas sur Apple Mac OS X Aqua si une fonctionnalité GLU est impliquée (car toute fonctionnalité GLU sur Mac OS X nécessite un contexte GL). GLU est nécessaire pour la tessellation de PolyMesh et NURBS.

8.13 Restrictions et lacunes dans la mise en oeuvre

En raison de la façon dont Ayam est mis en oeuvre, il existe plusieurs restrictions et lacunes :

Déficiences de l'interface utilisateur de Ayam :

8.14 Comment se joindre à la fête

Contribuer à rendre Ayam encore meilleur pimentera aussi votre vie. Voici comment faire :

  1. Ecrire/traduire des tutoriels
  2. Traduisez quelques textes d'aide en forme de ballon. Créer un nouveau fichier de script de traduction en entrant dans la console Ayam :
    » ms_create lang
    (en remplaçant lang par une désignation linguistique à deux caractères comme it pour l'italien). Maintenant, éditez/traduisez le nouveau fichier de script. Testez-le en l'ajoutant au paramètre de préférence "Scripts".
  3. Créer et soumettre des exemples d'objets, de scènes et d'images.
  4. Mettez en place des objets personnalisés comme des arbres, des paysages, du ciel, des XSplines, des T-Splines, ou tout ce qui vous vient à l'esprit. Notez que la licence de Ayam ne vous empêche pas de mettre en oeuvre votre objet personnalisé en tant que partagiciel ou même en tant que logiciel commercial. Cependant, les logiciels libres sont préférés pour des raisons évidentes.
  5. Don de fichiers source pour améliorer plusieurs parties critiques du modeleur, quelques idées sont : meilleure simulation (plus exacte) de l'éclairage (est-ce possible de faire cela avec OpenGL ?), widgets de transformation, véritable prise en charge des surfaces de subdivision, levée de certaines déficiences (voir ci-dessus), plugins d'import/export. La page du projet de Ayam sur SourceForge énumère quelques tâches supplémentaires et vous êtes toujours les bienvenus pour discuter de ces questions sur le forum public.
Veuillez ne pas mettre en oeuvre des objets personnalisés comme de simples triangles ou polygones. Ce serait quelque chose qui n'est pas vraiment voulu par l'équipe de Ayam, et cela montrerait sûrement les limites de la conception actuelle de tout code fonctionnant sur la structure de la scène. Les objets Ayam devraient être des objets de haut niveau ! En lisant le dernier paragraphe, vous pourriez penser que nous sommes un peu en guerre contre les modèles polygonaux. Ce n'est pas le cas. Pour l'instant, les modèles polygonaux sont le seul moyen de prévisualiser une géométrie complexe en utilisant des graphiques accélérés au niveau des cartes graphiques. Mais même si RenderMan prend en charge le rendu des modèles polygonaux, leur utilisation comme primitive n'est pas recommandée pour de bonnes raisons. En d'autres termes, utilisez les modèles polygonaux dans le modeleur comme représentation rapide de vos objets de niveau supérieur, mais s'il vous plaît, si vous allez réellement restituer quelque chose, n'utilisez pas cette représentation polygonale. Si vous voulez plutôt utiliser une représentation polygonale complète, hé bien, il existe de bons modeleurs.

8.15 References

Suggestions de lecture :

Ressources internet relatives à Ayam : Resources internet relatives à RenderMan :

8.16 Remerciements

Tout d'abord, je tiens à exprimer un grand "merci" à Bernd (Pink) Sieker. C'est le premier vrai utilisateur de Mops et le premier bêta-testeur, qui m'a incité ces dernières années par e-mail et sur IRC à corriger ce bug particulier, à ajouter quelques fonctionnalités essentielles, à déplacer les lumières à nouveau etc. pp. en d'innombrables itérations. Bernd, sans votre aide, je n'en serais sûrement pas là, merci !

8.17 Trademarks

OpenGL (R) is a registered trademark of Silicon Graphics, Inc.

The RenderMan (R) Interface Procedures and Protocol are: Copyright 1988, 1989, 2000 Pixar All Rights Reserved

RenderMan (R) is a registered trademark of Pixar

The Affine Libraries and Tools are Copyright (c) 1995, 1996, 1997, 1998 Thomas E. Burge All rights reserved.

Affine (R) is a registered trademark of Thomas E. Burge.

TIFF Software is Copyright (c) 1988-1997 Sam Leffler Copyright (c) 1991-1997 Silicon Graphics, Inc.

Dime is Copyright (c) 1998-1999 Systems In Motion, SA All rights reserved.

AutoCAD (R) is a registered trademark of Autodesk, Inc.

DXF (R) is a registered trademark of Autodesk, Inc.


Page suivante Page précédente Table des matières