Créer des objets avec collision multi-matériaux

Ceci n’est pas à franchement parler un tutorial, mais plutôt une liste de solutions (certainement incomplète) permettant de créer des objets possédant des collisions constituée de plusieurs matériaux en réponse à un problème de Veldrin, et qui m’a permis de découvrir certains problème de collision que je ne testais plus depuis longtemps, pensant la méthodologie éprouvée.

L'idée ici est d'utiliser, dans un seul fichier nif, des blocs de collision avec des propriétés de matériaux différentes (pouvoir mélanger du verre et de la pierre, ou du bois par exemple), de façon transparente pour le joueur, c'est a dire que chaque partie du bloc de collision doit se comporter comme si les fichiers nif étaient séparés avec chacun son propre matériau.


C'est bien joli,... mais à quoi ça sert?
Tout simplement à ne pas disperser les objets ayant plusieurs matériaux dans plusieurs nif, et donc de n'avoir à gérer et à placer qu'un objet global.
Un exemple? tout de suite!
Dès le début de la cité sylvestre j'ai été confronté au problème des fenêtres qui, certains l'auront remarqué, n'ont pas toutes la même forme; c'est à dire que qu'en fonction des versions, les montants en bois et le verre sont changés de concert. Le comportement à la collision se devait d'être différent en fonction du matériau. Il était hors de question de définir tout en STONE, comme le fait souvent Bethesda, afin que tout richoche et que l'on ne voit pas la supercherie, pas plus que de permettre de planter des flèches dans du verre en passant tout en WOOD!
Il était toujours possible de définir deux fichiers nif avec chacun son matériau de collision (les murs en WOOD et les vitres en GLASS), mais cela nécessite de gérer deux objets et deux fichiers en parallèle, et est source d'erreurs (chaque partie du tout devant être positionnée avec les autres).


Initialement, il était possible avec blender d'exporter simplement, dans un même fichier nif, un ensemble de maillages avec plusieurs blocs de collisions de nature différentes.
Chaque maillage de collision était défini par la méthode classique :
- affichage du maillage de collision ave une apparence de type "Limites" avec "Fil de Fer" en option,
- ajout d'une propriété de collision (dans le panneau "logique" de blender par appui sur F4), de type String, ayant pour nom Havok_Material et prenant
l'une des valeurs reconnue par oblivion (HAV_MAT_STONE... HAV_MAT_WOOD....)
- exportation en nif.
- ... (et c'est tout!)




Mais je vous parle d'un temps que les moins de 20 ans ne peuvent pas connaître; depuis les scripts d'export ont évolué et ceci ne semble plus possible.


------------------------------------------
Structure des blocs de collision des fichiers nif


Le script d'export a évolué, sans crier gare, et nombre d'objets sylvestres, testé à l’origine, ont désormais un comportement non souhaité lors des collisions (les murs avec fenêtres, le mobilier en bois avec vitre de verre...), ainsi les flèches récemment décochées sur le bois des murs des grandes maisons sylvestres ont la mauvaise idée de ricocher dans un joli petit bruit de verre plutôt que de se planter et de ne ricocher que sur les vitres elles-même.

Mon fichier de référence date du 20 juillet 2008 et a dû être réalisé avec blender 2.46, blender-nif-script 2.3.3 et pyFFI 0.11.0 (du moins étaient-ce les versions officielles de l'époque!).

Le fichier nif comprend trois cubes avec chacun un bloc de collision propre (STONE, WOOD, GLASS).
In-game chaque bloc de collision se comporte de façon autonome, les flêches se plante bien dans le bois et pas dans la pierre et le verre, et les son associés à l'impact sont bien ceux attendus.

L'exportation récente, en nif des maillages d'origine, à partir de blender, n'a pas permis d'obtenir les mêmes résultats, quelques soient les options utilisées.
L'option "use bhkListShape" n'a pas eu d'effet (l'ai-je mal utilisée? est-ce un bug? ... d'ailleurs à quoi sert-elle?).
A noter que POUR CE CAS d'exportation, IL NE FAUT PAS VALIDER l'option 'Do not use blender collision properties", qui va forcer le nom des matériaux à celui choisi dans les options de collision de la fenêtre d'exportation (et donc un seul et unique matériau!).

Les blocs de collision, entre le fichier d'origine et les nouveaux, sont décrits différemment.

La structure utilisée dans le fichier d'origine est la suivante :
bhkCollisionObject
--bhkRigidBody
----bhkPackedNiTriStripsShape
Ce dernier contient la liste de matériaux dans un tableau "Sub Shapes".

Ci dessous la structure du fichier nif d'origine et une vue in-game de la tentative de planter des flêches (qui ne se plantent que sur le seul matériau bois).




La structure utilisée dans les nouveaux fichiers est la suivante :
bhkCollisionObject
--bhkRigidBody
----bhkMoppBvTreeShape
-------bhkPackedNiTriStripsShape
Ce dernier contient la liste de matériaux dans un tableau "Sub Shapes".

Le bloc "bhkMoppBvTreeShape" semble contenir des informations permettant d'optimiser les collisions.
Il contient une information de materiau de collision, mais celle-ci ne semble pas être utilisée pour les collisions. Le remplacement du matériau STONE par WOOD, n'a pas permi de planter des flêches dans l'objet.

Ci dessous la structure du nouveau fichier nif avec le materiau du "bhkMoppBvTreeShape" en STONE ou WOOD et l'effet in-game.




Par contre le jeu semble préférer utiliser le premier matériau cité dans la liste des sub-shape; transformer le matériau du premier sub-shape de STONE à WOOD, a permi de planter les flêches (mais sur toute la structure puisque le multi matériau n'est pas géré avec ce fichier).




-----------------------------------------------------------
Méthode de l'édition du bloc de collision du fichier nif

Un essai de modification du nouveau fichier nif a été tenté avec succès.
Dans le bloc "bhkRigidBody", la valeur du "Shape", qui indique le numéro du sous bloc, a été modifier pour pointer directement sur le bloc "bhkPackedNiTriStripsShape" (et non sur le bloc "bhkMoppBvTreeShape" qui lui même pointait sur le "bhkPackedNiTriStripsShape"), puis le bloc "bhkMoppBvTreeShape" orphelin a été supprimé du nif.
Dans l'exemple des trois cubes, cela revient à faire passer la valeur du "Shape" de 4 (bhkMoppBvTreeShape) à 3 (bhkPackedNiTriStripsShape).
La structure du fichier est donc, a priori, semblable au fichier d'origine et le comportement conforme à ce qui est souhaité (des effets de collision, sonores... identiques!).

Ci dessous une vue du nif modifié et l'effet in-game.





Je ne sais pas s'il y a des effets de bords, des comportements anormaux qui résulterait de cette manipulation de fichier nif.
Peut-être qu'un jour il sera possible de refaire ces exportations de blocs de collision multi-materiaux; peut-être est-ce déjà possible mais que je sais tout simplement pas comment faire...


-----------------------------------------------------------
Méthode du fichier nif hiérarchique

L'idée ici consiste à réaliser un fichier nif ayant une hierarchie de NiNodes, chaque sous NiNode ayant son propre bloc de collision.

L'image suivant montre un exemple de ce qui peut être fait dans le cas des trois cubes de matériaux différents.




Le NiNode principal contient ici trois sous NiNode (un par cube), chaque sous NiNode ayant son propre bloc de collision mono-matériau.
La réalisation de ce fichier nif peut être fait soit par assemblage d'éléments exportés séparément avec son matériau, en utilisant NifSkope, soit directement à partir de blender en créant une parenté entre le bloc de collision et un objet.
Cette parenté n'ayant ici pour but que la séparation des meshs de collision, il n'est pas nécessaire qu'un bloc de collision et le mesh correspondant aient le même parent.
Mais ici, par soucis de clarté, chaque mesh et son bloc de collision ont été déclarés comme ayant le même parent. Par type de collision, un objet vide (empty) de blender a été créé pour la cause (en effectuant la commande : ajouter > objet vide), puis le maillage et le bloc de collision ont été apparenté à cet empty (par sélection successive de l'objet, du bloc de collision, puis de l'empty, puis en executant la commande objet>parenté>créer parenté ou en tapant Ctrl P).

Ci dessous, une vue du fichier nif et du résultat in game.





Cette méthode permet d'éviter la modification en directe du nif (même s'il est toujours bien d'y jeter un oeil!).
Elle permet aussi (de part la création de parenté), de regrouper les éléments d'un même nif dans une structure commune et donc d'effectuer l'exportation de l'ensemble en ne sélectionnant qu'une partie (le reste de la famille est exportée avec chaque membre), tout en permettant les manipulations globale des différents morceau de l'objet; ce qui peut être pratique si, comme moi, vous vous retrouvé, dans un fichier blender, avec une cinquantaine d'objets différents par calque!

Par contre son avantage est aussi son défaut : si vous modifié une toute petite partie d'un très gros objet, vous ne pourrez l'exporter seule "vite fait - bien fait" pour l'intégrer à la main dans le nif, sans casser cette parenté.

A noter que cette séparation des blocs de collision par niveau hiérarchique, est déjà utilisée pas Bethesda pour les objets animés, puisque l'animation est effectuée sur le NiNode comprenant le bloc de collision (cas des portes sylvestre par exemple pour lesquells les flèches plantées suivent la porte à l'ouverture et à la fermeture).


----------------------------
Resumé des solutions

Je vois donc plusieurs possibilités pour mélanger les matériaux de collision :
1- ne pas le faire, et créer des fichiers séparés en fonction des matériaux et reconstituer le tout dans le TESCS.
2- exporter les objets dans des fichiers séparés par type de matériaux de collision et réaliser un assemblage manuel avec NifSkope.
3- créer des niveaux hierarchiques pour, entre autres, les blocs de collision dans blender, et exporter dans un seul fichier nif.
2- utiliser les anciennes versions de logiciels (blender 2.46, blender-nif-script 2.3.3 et pyFFI 0.11.0) et exporter les structures à collision multi-matériaux dans un même fichier.
3- utiliser des versions plus récentes de logiciels (actuellement j'utilise blender 2.49, blender-nif-script 2.5.4 et pyFFI 2.1.4), et lier directement le bhkRigidBody au bhkPackedNiTriStripsShape (retirer le bhkMoppBvTreeShape)
4- trouver comment faire autrement avec la version de script actuelle...
5- attendre une nouvelle version de script?
6- …?