Hellkeeper.fr RSS Feed

Index Archives UnrealEd Tutorials Miscellaneous Maps Special Maps Links Hellkeeper Files Contact Administration

Objets Karma

Introduction

Le moteur Karma de MathEngine permet de simuler une physique réaliste pour certains objets. Les ragdolls, les cadavres désarticulés des joueurs, qui se déforment, tombent et réagissent aux tirs, sont de ce type. N'importe quel static-mesh pourvu d'une collision peut également être ajouté en tant qu'objet Karma et être soumis à une simulation physique largement paramétrable. Il est également possible de définir des points d'attache entre plusieurs objets Karma ou de les fixer au niveau par un ou plusieurs points.

Lorsqu'il est ajouté au niveau, un objet Karma est par défaut inerte tant que sa simulation physique n'a pas été initiée par un événement externe. Il peut s'agir d'un tir ou du contact d'un autre objet Karma déjà en mouvement. Une fois la simulation d'un objet commencée, il réagit au contact de tout actor ayant la propriété bBlockKarma = vrai.

Un joueur peut être bloqué, monter sur ou être repoussé par un objet Karma, mais il ne peut pas lui-même le bloquer ou le pousser. Aucun système n'est prévu pour que le joueur puisse manipuler un objet soumis à la physique ; la seule interaction qu'il peut avoir est le tir. N'importe quel tir d'arme peut servir à pousser un objet et déclenche la simulation d'un objet inerte, à l'exception du minigun, du marteau bouclier et des tirs principaux du fusil Link et du fusil d'assaut. Les projectiles du fusil Bio et les grenades n'activent pas la simulation en heurtant un objet Karma, mais leur éclatement oui.

Les projectiles qui rebondissent ou s'accrochent à la géométrie du niveau, tels que les grenades, les schrapnels du canon Flak ou les boules toxiques du fusil Bio, ne sont pas des objets physiques : leur comportement est spécifié dans leur code et leur "physique" est extrêmement simplifiée.

Les objets Karma sont affectés par paramètres de gravité ou de courant des PhysicsVolume. Ils peuvent être paramétrés pour réagir à l'eau s'ils entrent dans un WaterVolume et sont également bloqués par les BlockingVolumes. Par défaut, un mover possède le réglage bBlockKarma = faux et ne peut donc pas faire collision avec un objet Karma : ils se passent à travers. Si bBlockKarma = vrai, un mover peut interagir avec les objets physiques, mais uniquement si la simulation de ces derniers a déjà été initiée par ailleurs.

Les véhicules utilisent le moteur Karma pour leur assemblage et leur comportement, mais la façon dont ils sont implémentés dépend du jeu et du type de véhicle utilisé. Unreal 2 XMP utilise des véhicules basés sur la classe KVehicle, où chaque pièce de la machine est un static-mesh employé comme objet Karma, le véhicule entier étant assemblé par des contraintes. UT2003 possède une map de démonstration, VehicleDemo (retirée d'UT2004) qui permet d'essayer un véhicule (le Bulldog) utilisant un système de ce type. Les véhicules d'UT2004 utilisent la classe SVehicle, qui se base sur des meshes pourvus d'un squelette (comme les modèles de joueurs), ce qui permet d'avoir un système moins complexe, notamment en multijoueur, en réduisant le nombre d'objets à gérer séparément.

Dans tous les cas, il faut éviter tout contact entre les objets Karma et les véhicules. La collision des deux entraîne un énorme ralentissement du jeu quelle que soit la puissance de la machine sur laquelle il tourne.

En dehors des véhicules, les ragdolls des joueurs sont le seul élément de physique présent dans le jeu original, ce qui n'est possible que parce qu'ils n'ont aucune incidence sur le jeu et sont de simples décorations : ils ne font pas collision avec les autres objets physiques (pas même les autres ragdolls) ou les joueurs, uniquement avec la géométrie de la map. En multijoueur, les objets Karma sont calculés par le client, ce qui limite les possibilités d'utilisation à des éléments discrets et purement esthétiques (comme les cadavres), car ils n'auront pas forcément le même comportement pour tous les joueurs. Il existe des mods permettant d'activer la réplication de la physique pour que les objets Karma réagissent de la même façon chez tous les participants, mais ce tutorial n'abordera pas cet aspect. Les véhicules possèdent leur propre système de réplication.

Ce tutorial se concentrera sur les objets utilisables comme décorations dans une map.

Collisions

N'importe quel static-mesh peut être utilisé comme objet physique du moment qu'il possède un modèle de collision. Celui-ci peut être une collision simplifiée créée dans l'éditeur, comme expliqué dans le tutorial sur les static-meshes, mais il est également possible de générer une collision spécifique au moteur physique, la Karma primitive. Celle-ci n'est utilisée que pour la physique de l'objet et non pour la collision avec les tirs, par exemple. Pour ce faire, il faut choisir, dans le static-mesh browser, Collision Tools → Fit Karma Primitive.

On peut alors choisir de générer une primitive basique : une sphère ou un cylindre (aligné sur l'un des axes de l'éditeur).

Ces primitives peuvent être rendues visibles en cliquant sur View → Show Karma Primitives dans le browser ou dans la vue 3D. Elles sont affichées en vert autour du static-mesh. Si l'objet possède une collision simplifiée et pas de Karma primitive, les vertices de la collision sont affichés sous la forme de croix.

Les deux types de collision peuvent coexister pour un même static-mesh, mais la Karma primitive est toujours utilisée par le moteur Karma si elle est présente. Si le static-mesh possède un modèle de collision mais que son utilisation par le moteur physique est désactivée (UseSimpleKarmaCollision = faux), l'objet se comportera comme un static-mesh normal : il pourra bloquer les joueurs, les tirs et les autres objets physiques, mais restera inerte.

Les différents types de collision obéissent à des impératifs différents suivant la situation : il est préférable que les tirs des armes, par exemple, aient une collision extrêmement précise basée sur les triangles du static-mesh, mais la collision simplifiée permet d'éviter que le joueur se coince dans le décor si un static-mesh présente des aspérités. Pour le comportement physique, les interactions étant coûteuses, un modèle extrêmement simplifié peut s'avérer utile. À l'inverse, il est aussi possible de réaliser une collision à base de Karma primitives dans un logiciel externe et de l'importer afin que le moteur physique dispose d'un modèle plus ajusté que la collision simplifiée, afin d'avoir un comportement plus réaliste de l'objet lorsqu'il chute ou percute la géométrie dans ses mouvements.

Objet Karma simple

Si le static-mesh sélectionné dans le static-mesh browser possède un modèle de collision, quel que soit le type, il peut être ajouté en tant qu'objet Karma en faisant clic droit → add Karma Actor (autrement, l'option n'est pas présente). Pour donner un exemple, j'utiliserai le static-mesh cp_Mechstaticpack1.Decors.cp_sg_Mechtechbarrel3.

Une fois ajouté, il ne se distingue pas des static-meshes normaux par son apparence extérieure, que ce soit dans le jeu ou dans l'éditeur (il n'a pas de couleur spéciale dans les vues 2D).
L'objet est immédiatement utilisable dans le jeu, mais la simulation doit être activée par un événement externe. Si la map est testée, l'objet reste fixe et ne tombe pas s'il est placé en l'air. La première impulsion déclenchant la physique peut être une collision avec un autre objet physique déjà en mouvement, une explosion ou le tir d'une arme (à l'exception de celles citées dans l'introduction).

Par défaut, les objets Karma, une fois activés, glissent énormément sur le sol et leur comportement est très basique. De plus, ils ne sont par défaut actifs que si le niveau de détail est réglé au maximum dans le jeu.

Tout ceci peut être modifié avec l'onglet Karma, qui contient un paramètre directement accessible ainsi qu'une liste, KParams, qui possède déjà un élément contenant trois sous-onglets.

Si bKTakeShot est vrai (c'est le cas par défaut), l'objet réagit aux tirs qu'il reçoit. S'il est faux, l'objet ne réagit pas aux tirs mais il les absorbe : ils ne traversent pas l'objet et ne rebondissent pas dessus. L'onglet Object est généralement inutile car il ne contient que le nom de l'ensemble de propriétés de l'objet.

L'onglet KarmaParams est le plus important car il contient de nombreux paramètres qui régissent la façon dont la simulation physique gère l'objet.

• bDestroyOnWorldPenetrate : Si vrai, l'objet est supprimé du niveau si son centre sort des limites du niveau. Le cas peut se présenter lorsque, par exemple, un objet se déplace à très haute vitesse et que le moteur physique "rate" le calcul de la collision.
• DoSafetime : Permet de forcer le moteur à recalculer si un objet semble devoir sortir de la map, afin de l'empêcher si nécessaire.
• bHighDetailOnly : Si vrai, la simulation n'est active pour l'objet que si le niveau de détail physique est maximum dans les options du jeu. En désactivant ce paramètre, la simulation peut être forcée dans tous les cas.

Notez que le niveau de détail physique choisi par le joueur dans les options du jeu est transmis à la map lors du chargement. Si le niveau de détail est changé en cours de partie, la map doit être rechargée pour que le nouveau réglage s'applique. Dans l'éditeur, le niveau de détail actuel est visible dans le LevelInfo (View → Level Properties → LevelInfo → PhysicsDetailLevel).

• bKAllowRotate : Si vrai, permet à l'objet de tourner sur lui-même autour de son axe vertical. Ne fonctionne que si bKStayUpright est vrai.
• KDoubleTickRate : Double la fréquence de calcul de la simulation pour cet objet afin d'obtenir un résultat plus précis. Si deux objets Karma avec des réglages différents pour ce paramètre entrent en contact, il est possible que la collision se fasse mal.
• bKNonSphericalInertia : Par défaut, le moteur physique calcule approximativement la masse de l'objet à l'aide d'un "Inertia Tensor" sphérique. Si cette propriété est vraie, le modèle de collision de l'objet est utilisé à la place pour son inertie avec davantage de précision, au prix d'un calcul plus lent.
• bKStayUpright : Si ce paramètre est vrai, l'objet résiste aux forces qui devraient le renverser. La force avec laquelle il tente de se maintenir debout est réglée avec les paramètres StayUprightDamping et StayUprightStiffness.
• KActorGravScale : Multiplicateur de la gravité appliquée à l'objet. Une valeur négative inverse la direction de la gravité. Une valeur très supérieure à 1 peut faire passer l'objet à travers le sol lorsque la simulation débute.
• KAngularDamping et KLinearDamping : Résistance de l'objet aux mouvements rotatifs et linéaires (respectivement). Plus la valeur est forte, plus il faut de force pour mettre l'objet en mouvement.
• KBuoyancy : Flottaison de l'objet. Si la valeur est supérieure à 1, l'objet remonte à la surface s'il se trouve dans un WaterVolume, et ce d'autant plus vite que la valeur est haute. Si la valeur est exactement 1, il ne coule pas et ne flotte pas mais reste là où il s'immobilise dans l'eau. Si la valeur est inférieure à 1, il coule d'autant plus vite que la valeur est proche de 0.
• KMass : Multiplicateur de la masse de l'objet. Celle-ci est calculée par rapport aux dimensions de son modèle de collision.
• KMaxAngularSpeed et KMaxSpeed : Vitesses maximales que l'objet peut atteindre pour, respectivement, ses mouvements rotatifs (en radians par seconde) et ses déplacements linéaires (en unités Unreal par seconde).
• KStartAngVel et KStartLinVel : Lorsque la simulation physique de l'objet débute, ces deux paramètres permettent de lui imprimer instantanément une rotation et de le propulser dans une direction donnée.
• KStartEnabled : Activer ce paramètre permet de commencer la simulation dès le lancement du jeu au lieu d'attendre un déclenchement extérieur.
• KVelDropBelowThreshold : Appelle une fonction du script lorsque la vitesse de l'objet descend sous cette limite.
• Repulsors : Sans effet. Cette propriété nécessite un code spécifique.
• StayUprightDamping et StayUpRightStiffness : Si bKStayUpright = vrai, ces deux paramètres définissent la façon dont l'objet tente de maintenir son orientation. StayUprightStiffness indique avec quelle force l'objet tente de se remettre à la verticale lorsqu'il reçoit un choc et StayUprightDamping agit comme un amortisseur des oscillations que l'objet peut faire autour de son axe.

La partie KarmaParamsCollision contient trois propriétés supplémentaires qui influent sur les contacts entre l'objet et la géométrie qu'il touche, là où KarmaParams se concentre sur le comportement de l'objet lui-même.

• Kfriction : Friction entre l'objet et la géométrie qu'il touche. C'est parce que ce paramètre est par défaut à 0 qu'un objet Karma récemment ajouté glisse sur le sol comme une savonnette. Si la friction est haute (par exemple 1 ou 2), l'objet accorche fortement le sol et nécessite beaucoup de force pour être mis en mouvement, avant de s'immobiliser rapidement. On peut aussi utiliser une valeur négative pour accentuer la glisse sur toutes les surfaces.
• KimpactThreshold : Si l'objet reçoit un impact d'une force supérieure à celle spécifiée dans ce champ, une fonction codée peut être déclenchée.
• KRestitution : Lorsque l'objet heurte une surface et rebondit, ce paramètre indique la proportion de la vitesse d'origine qu'il conserve. Si KRestitution = 1, l'objet rebondit en conservant sa vitesse d'origine. Si la valeur est 0, il ne rebondit pas. Si la valeur est très supérieure à 1, l'objet rebondit avec une vitesse plus grande que celle d'origine. Après quelques rebonds, la résultat est tout bonnement anarchique.

Une fois la taille de mon tonneau réduite de moitié, son paramètre KStartEnabled est réglé sur vrai pour que la simulation démarre dès le début de la partie. Il est un peu au-dessus du sol et chute donc lorsque la jeu démarre. Il réagit déjà aux tirs et bloque le joueur, mais glisse sur le sol comme sur de la glace. Si de l'eau est présente, il coule au fond comme s'il chutait à l'air libre.

Pour donner l'impression d'un baril plein de liquide, avec une inertie importante, on peut par exemple régler bKStayUpright et bKAllowRotate = vrai. StayUprightStiffness et StayUprightDamping sont réglés respectivement à 50 et 10. KFriction = 1 et KRestitution = 0.8 permettent d'immobiliser rapidement l'objet lorsqu'il roule sur le sol (au lieu de glisser), ce qui donne l'impression d'un objet lourd et plein. On peut aussi baisser la valeur de KMaxSpeed pour l'empêcher d'être projeté trop rapidement en cas de fort impact, mais la valeur maximale est à apprécier en fonction de l'effet recherché. Enfin, pour qu'il flotte, KBuoyancy est réglé sur 1.2.

Son comportement dans l'eau peut être testé en l'ajoutant à une map avec un WaterVolume, par exemple CTF-December.

Attention, un objet qui flotte tente de sortir entièrement du WaterVolume et de se maintenir au-dessus. La surface doit donc être décalée du sommet du volume pour que l'objet ne semble pas posé sur l'eau une fois immobilisé.

Ragdolls

Les ragdolls sont les cadavres des joueurs. Ils se distinguent des autres objets par la présence d'un squelette : au lieu de static-meshes fixes, ce sont des objets déformables.

Il est possible d'en ajouter comme "décorations" à une map, tout en gardant à l'esprit que, comme les cadavres des joueurs, ces ragdolls rebondissent sur la géométrie et peuvent être propulsés par des tirs, mais ils ne peuvent pas interagir avec les autres objets Karma (ils passent à travers).
Après avoir ajouté n'importe quel static-mesh comme KActor, il faut choisir le mesh du personnage voulu dans l'animation browser.

Tous les modèles du jeu existent en deux versions, l'une étant un simple reskin du visage. Le mesh EgyptMaleA apparaît ainsi sous les traits de Scarab, mais Horus utilise le même mesh. Si c'est ce dernier qui doit être utilisé, il suffit de changer la skin de visage. Notre exemple utilisera Malcolm, le mesh MercMaleD du package HumanMaleA.

Une fois le mesh sélectionné, ajoutez-le à votre objet dans Display → Mesh et changez DrawType en DT_Mesh. Le changement est instantané.

Le personnage est toutefois toujours considéré comme un objet fixe qui n'utilise pas l'effet de ragdoll si le jeu est lancé. Pour que l'effet fonctionne, il faut d'abord changer Movement → Physics en PHYS_KarmaRagDoll pour indiquer quel type de physique doit être appliqué.

Une fois ceci fait, il faut donner à l'objet les propriétés d'un ragdoll, notamment le squelette de collision utilisé. Dans l'onglet Karma, une fois supprimé le contenu de KParams avec le bouton "Eff.", il est possible d'ajouter un nouvel élément dans une liste comprenant KarmaParams, KarmaParamsCollision, KarmaParamsRBFull et KarmaParamsSkel. C'est ce dernier élément qui convient. Une fois ajouté, il contient les mêmes sous-onglets et paramètres que KarmaParams, mais il possède en plus un sous-onglet KarmaParamsSkel contenant 4 paramètres spécifiques.

• bKDoConvulsions : Permet de forcer le corps à convulser en se contractant régulièrement. C'est l'effet utilisé lorsqu'un joueur est abattu par un tir de Lighting Gun pour simuler le courant électrique le traversant.
• bRubbery : Désactive toutes les limites des articulations du squelette (par exemple celles limitant la rotation des épaules à des angles réalistes) ce qui donne l'effet d'une poupée de chiffon ou d'une peluche molle qui peut se déformer sans aucune résistance.
• KConvulseSpacing : Temps minimal et maximal entre chaque convulsion si bKDoConvulsions = vrai.
• KSkeleton : Ce paramètre définit quel modèle de collision ragdoll est utilisé pour le mesh. Il est capital car l'effet ne fonctionne pas autrement. Le nom du modèle est sensible à la casse, doit être tapé manuellement et il n'y a pas de liste fournie, l'information n'étant visible nulle part dans UnrealEd. Fort heureusement, la liste n'est pas longue :
  • Alien est le modèle utilisé pour tous les personnages Gen Mo'Kai, mâles et femelles.
  • Bot est le modèle utilisé pour les robots normaux comme Corrosion et Rapier.
  • Jugg est le modèle utilisé pour tous les Juggernauts, hommes et femmes, ainsi que pour les robots massifs comme Xan et Cyclops.
  • Male est utilisé pour les humains et les personnages Cauchemar masculins.
  • Female est utilisé pour les humaines et les personnages Cauchemar féminins, mais aussi les robots féminins comme Divisor ou Enigma.
  • Skaarj est le modèle utilisé pour les Skaarjs.

Une fois le modèle de collision ragdoll convenable ajouté (Male pour Malcolm), la map peut être jouée. Le corps réagit, comme les cadavres, aux tirs et aux chutes. Il possède la totalité des paramètres des objets Karma normaux en plus de ses paramètres spécifiques.

Notez que si KStartEnabled = faux, le corps sera compacté au début de la partie et ne se déploiera qu'après le début de la simulation, quand il aura reçu un tir. Il est donc presque toujours nécessaire de régler ce paramètre sur vrai.

Le mesh doit impérativement avoir un DrawScale (et DrawScale 3D) de 1. Si ce n'est pas le cas, le mesh sera déformé.

Si le mesh utilisé n'est pas un des personnages par défaut du jeu, il se peut que son modèle Karma ne soit pas un des modèles cités ci-dessus. Dans ce cas, le modèle aura sans doute été fourni avec un fichier .ka rangé dans le dossier /KarmaData/ d'UT2004. Il y a fort à parier que le nom du modèle de collision ragdoll sera le même que celui du fichier .ka fourni (par exemple Effigy pour le modèle du même nom). Si ce n'est pas le cas, il peut s'avérer nécessaire d'ouvrir le fichier .ka pour voir comment se nomme le modèle à l'intérieur. Pour cela, il faut installer KAT, le Karma Authoring Tool, fourni sur le CD 3 d'UT2003, le CD 6 d'UT2004 (ou le dossier CD6 du DVD), dans le dossier /Extras/. Une fois lancé, il possède une interface assez proche de celle d'UnrealEd.

Par défaut, KAT présente la liste des modèles d'UT2003 (il manque donc les Skaarjs). Dans la barre d'outil de droite, on peut ouvrir un fichier .ka en cliquant sur File → Add to workspace.

Il suffit alors d'ouvrir le fichier .ka du modèle. Le nom du ou des éléments qu'il contient correspond au nom du ou des modèles ragdolls qui sont utilisables.

Les propriétés de l'onglet KParams du ragdoll fonctionnent de la même façon que pour un objet Karma standard.

Contraintes

En plus des objets Karma eux-mêmes, UnrealEd possède plusieurs actors permettant des contraindre leurs mouvements. Ils se trouvent dans l'actor browser sous KActor → KConstraint.

Le KCarWheelJoint n'est utile que pour les véhicules et ne sera donc pas détaillé ici.

KBSJoint

Le KBSJoint (pour Karma Ball and Socket Joint) est un actor permettant d'attacher entre eux des objets Karma, y compris des ragdolls, et de les fixer au niveau. Le KBSJoint est fixé au pas de la grille et son pivot rouge représente le point exact d'attache.

• bKDisableCollison : Si vrai, les deux objets Karma reliés par le KBSJoint ne peuvent pas entrer en collision l'un avec l'autre et se traversent. Cela peut s'avérer utile lorsque deux objets sont par exemple mis bout à bout et que leur forme devrait leur interdire toute mobilité l'un par rapport à l'autre.
• KConstraintActor1 et KConstraintActor2 : Les deux actors Karma reliés entre eux par le KBSJoint. En cliquant dans le champ, on peut utiliser le bouton "Trouv." qui permet de cliquer ensuite sur un objet physique dans un des viewports. Le nom s'affiche (et peut être entré manuellement) sous la forme KActor'mylevel.XXX', où XXX est le nom de l'objet (visible dans ses propriétés, Object → Name), ce qui donne un nom du type KActor'mylevel.KActor3'.
• KConstraintBone1 et KConstraintBone2 : Si l'un des objets Karma concernés est un ragdoll, ce paramètre permet d'insérer le nom exact du bone qui est attaché à l'emplacement du KBSJoint.
• KForceThreshold : En accord avec les paramètres de ce type déjà vus, ce paramètre permet d'appeler une fonction UScript si le KBSJoint est soumis à une force supérieure au seuil défini.

Une fois les deux objets Karma placés en contact l'un avec l'autre, il suffit d'ajouter le KBSJoint au point où ils se touchent. Ils sont automatiquement attachés par leur point le plus proche du KBSJoint, et ce même s'ils sont séparés. Il faut ensuite les paramétrer comme actors contraints dans les propriétés du KBSJoint.

KConstraintActor1 doit impérativement contenir la référence d'un objet Karma. Si ce champ est vide, le KBSJoint sera sans effet

L'objet dans KConstraintActor1 sera attaché à l'objet dans KConstraintActor2 s'il est également rempli. Si KConstraintActor2 est laissé vierge, l'objet sera fixé à la position de l'actor KBSJoint lui-même, ce qui permet de l'attacher à une position précise dans le niveau.

Un même objet Karma peut être fixé à un autre en plusieurs points, en utilisant plusieurs KBSJoint. En revanche, une limitation du moteur d'UT2004 est que seuls les objets Karma peuvent être liés entre eux : il n'est pas possible d'en attacher un à un mover, par exemple.

Si le KBSJoint n'est lié à aucun actor ou s'il est lié à un actor qui n'est pas un objet Karma, UnrealEd affichera une erreur lors du rebuild.

L'exemple traditionnel permettant de voir le fonctionnement du KBSJoint en action est la lampe au bout d'une chaîne : trois sections de chaîne sont superposées et une lampe est fixée à la dernière section, le tout constitué d'objets Karma. Un KBSJoint est ajouté à chaque jonction. Chaque KBSJoint est relié aux deux objets Karma au-dessus et au-dessous de lui. Celui au sommet de la chaîne fixe le tout au plafond en ayant un champ KConstraintActor2 vide.

Une fois le jeu lancé, un tir permet de vérifier le fonctionnement du système. Si un des éléments tombe ou ne se déplace pas avec le reste du système, un KBSJoint est mal configuré.

Si plusieurs objets sont ainsi liés entre eux avec des KBSJoints, il suffit que l'un d'eux soit activé (ou soit réglé en KStartEnabled = vrai) pour démarrer le simulation de toute la chaîne. Le moindre mouvement d'un des objets exercera en effet au moins une petite traction qui se répercutera sur tous les KBSJoints et objets du système.

L'attache d'un ragdoll est également fonctionnelle. Par défaut, le corps est attaché au KBSJoint par sa partie la plus proche.

Pour attacher le ragdoll par un de ses bones spécifiques, il faut ajouter son nom dans le KConstraintBone1 ou 2 (suivant que le ragdoll est le KConstraintActor 1 ou 2). Ce nom peut être trouvé dans l'animation browser en activant View → Bones et BoneNames. Dans la partie droite du browser, dans Mesh → Attach → Sockets, il suffit de trouver l'élément numéroté ayant le BoneName correspondant au point d'attache désiré et de noter le contenu de la propriété AttachAlias. C'est ce nom raccourci qui doit être renseigné.

Certains bones refusent cependant totalement de se fixer aux autres objets Karma, notamment ceux aux extrémités du squelette (tête, mains, pieds). Dans la mesure où le ragdoll se fixe par défaut par son point le plus proche du KBSJoint, KConstraintBone1 et 2 peuvent généralement être ignorés. Comme les ragdolls ne peuvent, dans tous les cas, pas faire collision avec les autres objets Karma, bKDisableCollision = faux n'a pas d'effet si un ragdoll est fixé à un autre objet physique.

KConeLimit

Le KConeLimit permet de limiter la liberté de mouvement autour d'un joint. Par défaut, un actor attaché à un KBSJoint peut tourner à 360° autour de ce point d'attache, sur tous les axes. Afin d'empêcher la lampe de faire des tours complets (y compris à travers la chaîne), on peut donc placer un KConeLimit. Son emplacement n'a pas d'importance mais il est préférable de le placer à proximité du système qu'il limite.

Il s'agit d'un actor directionnel dont la flèche définit un axe autour duquel la liberté de mouvement du joint est limitée. Pour relier deux portions de chaîne verticales, il faut ainsi orienter l'actor vers le bas.

Dans les propriétés du KConeLimit, KConstraintActor1/2 et KConstraintBone1/2 permettent d'indiquer quels sont les objets Karma dont le mouvement doit être limité. Le KConeLimit ne les attache pas ensemble : ils doivent déjà être liés par une autre contrainte et c'est le mouvement autour de celle-ci qui sera limité. Le paramètre bKDisableCollision, qu'il partage avec les autres KConstraint, n'a pas d'effet chez lui.

Les paramètres spécifiques du KConeLimit gèrent l'angle maximal que peuvent faire les deux objets.

• KDamping : Perte de vitesse de l'objet lorsqu'il "rebondit" sur l'angle maximal.
• KHalfAngle : Angle maximal par rapport à l'axe du KConeLimit. Cet angle est en unités Unreal (65536 = 360°).

• KStiffness : Rigidité de la limite. Plus la valeur est forte, plus l'objet bute brutalement sur la limite lorsque l'angle maximal est atteint.

Pour limiter le mouvement de la lampe, le KConeLimit, orienté vers le bas et relié à la fois à la lampe et aux derniers maillons de la chaîne, peut recevoir un KHalfAngle de 8192, ce qui permet à la lampe de s'écarter de la verticale d'environ 45° (pour une liberté totale d'environ 90°). L'angle est calculé par rapport à la position des deux objets Karma considérés. Si la partie supérieure de la chaîne est ainsi mise en mouvement, elle embarque l'angle du KConeLimit avec elle.

Le KConeLimit ne s'applique que sur le ou les KBSJoints reliant les deux objets qu'il référence lui-même : dans le cas de la lampe au bout de la chaîne, un KConeLimit différent doit être utilisé pour chaque KBSJoint si chaque articulation doit être limitée.

KHinge

Le KHinge est un actor versatile qui agit comme une charnière ou un pivot autour duquel un mouvement angulaire peut être paramétré. Comme le KBSJoint, il est fixé au pas de la grille et agit comme une attache entre un objet Karma et le niveau ou un second objet. Comme le KConeLimit, il est directionnel et exerce son effet sur l'axe matérialisé par sa flèche.

Le KHinge fixe un objet Karma en ne lui donnant la liberté que de pivoter autour de l'axe choisi, là où le KBSJoint laisse une totale liberté sur tous les axes. Il peut également être déclenché pour faire pivoter l'objet Karma autour de cet axe sur commande, ce qui permet de l'utiliser comme moteur.

Ses propriétés contiennent tous les paramètres d'un KBSJoint et d'un KConeLimit, mais plusieurs sont spécifiques à cet actor. Le plus important est KHingeType qui définit la façon dont l'articulation fonctionne.

• HT_Normal : Fonctionnement par défaut, attache simplement l'objet sur un axe, autour duquel il peut tourner (à 360°).
• HT_Springy : Une fois la simulation démarrée, le KHinge tente de maintenir l'objet à la position définie par KDesiredAngle. Si l'objet s'en écarte suite à un événement extérieur, le KHinge le ramène à cet angle comme un ressort.
• HT_Motor : Permet de donner une rotation continue à l'objet autour de l'axe du KHinge.
• HT_Controlled : Ce mode permet de faire tourner l'objet Karma autour de son axe jusqu'à atteindre KDesiredAngle et de l'y arrêter.

Les autres paramètres permettent de préciser le comportement de ces modes de fonctionnement. Tous les angles sont exprimés en unités Unreal (65536 = 360°) par rapport à la position initiale de l'objet Karma (son orientation dans l'éditeur est donc considérée comme l'angle 0 sur tous les axes en ce qui concerne la physique).

• KDesiredAngle et KAltDesiredAngle : Deux angles utilisés par HT_Springy et HT_Controlled.
• KDamping et KStiffness : Règlent le force et la résistance d'un KHinge en mode HT_Springy, de la même façon que pour le KConeLimit.
• KDesiredAngleVel et KMaxTorque : Ces paramètres sont utilisés pour déterminer comment HT_Motor et HT_Controlled font tourner l'objet Karma sur son axe. Ils définissent respectivement la vitesse de rotation (en unités Unreal par seconde : 65536 = 1 tour/seconde) et la puissance du moteur (son moment de force ou torque).
• KProportionalGap : Quand KHingeType = HT_Controlled, la rotation de l'objet ralentit quand il s'approche de l'angle désiré. Ce paramètre définit à quel distance angulaire de la position voulue la rotation commence à ralentir. Ainsi, si KDesiredAngle = 30000 et KProportionalGap = 10000, l'objet tourne à sa vitesse maximale (KDesiredAngleVel) juqu'à avoir effectué une rotation de 20000 degrés Unreal, puis ralentit progressivement sur les 10000 derniers degrés, jusqu'à s'arrêter totalement.

Le KHinge peut être déclenché par un Trigger, ce qui permet de l'utiliser pour ouvrir une porte, activer une catapulte, arrêter (ou activer) un ventilateur, etc. Il possède pour cela plusieurs InitialStates.

• ToggleMotor : Change le KHingeType de l'actor en HT_Motor. Si c'est déjà la cas, passe au mode HT_Controlled en changeant KDesiredAngle pour la position actuelle de l'objet Karma.
• ControlMotor : Identique, mais au lieu de réagir à chaque déclenchement successif, le KHinge reste en HT_Motor tant que le joueur reste sur le Trigger. Dès que le Trigger est "relâché", la rotation s'arrête.
• ToggleDesired : Permet à un KHinge réglé en HT_Springy ou HT_Controlled d'alterner entre KDesiredAngle et KAltDesiredAngle à chaque déclencement. Son utilisation permet de basculer entre deux positions en utilisant un Trigger.
• ControlDesired : Identique, mais l'alternance n'a lieu que tant que le joueur active le Trigger et prend fin quand le Trigger est "relâché".

Détail important : si l'objet Karma est réglé en KStartEnabled = faux, utiliser le Trigger démarre la simulation.

Charnière

L'exemple le plus simple pour montrer l'effet du KHinge est de l'utiliser comme charnière d'une porte. Il suffit d'un static-mesh adéquat ajouté en objet Karma et d'un KHinge pointé vers le haut ou le bas (pour limiter le mouvement autour de l'axe Z) placé sur l'axe de la porte. Il se place là où se situeraient les gonds.

La porte est ajoutée dans le KConstraintActor1 du KHinge. La contrainte fonctionne déjà, mais l'effet est très rudimentaire : tirer dans la porte ou y projeter un objet karma la fait tourner sur son axe sans limite jusqu'à ce qu'elle heurte un objet.

En l'occurence, elle tourne jusqu'à environ 90° avant de heurter le static-mesh du cadre de porte. Si la porte n'est entourée que de BSP, cependant, elle passe à travers en raison d'un bug du paramètre bKDisableCollision du KHinge : si l'objet n'est attaché à rien et que ce paramètre est vrai, sa collision avec la géométrie est désactivée. Le bug disparaît si un autre objet est attaché au premier.

Avec la collision activée, la porte peut osciller autour de son axe en heurtant les murs, mais elle ne se referme jamais. Pour qu'elle tente de se refermer quand le choc est passé, on peut utiliser KHingeType = HT_Springy. Le KHinge tente alors de résister au mouvement pour garder la porte close. Par défaut, KStiffness et KDamping étant à 0, la porte est très lâche et oscille très longuement sur son axe avant de s'immobiliser. Augmenter KDamping à 1 ou 2 permet de l'immobiliser plus vite en lui faisant perdre de la vitesse à chaque va-et-vient. Elle se comporte comme une porte de saloon qui se referme toute seule.

Si KDesiredAngle est différent de 0, il est aussi possible de faire en sorte qu'un choc sur la porte l'ouvre et qu'elle se maintienne ouverte : elle est alors fermée dans sa position de départ et activer la simulation active l'effet de ressort pour l'amener à KDesiredAngle (16384 par exemple, pour qu'elle pivote à angle droit).
Elle est alors toujours sensible aux tirs et aux impacts, mais oscille autour de sa position ouverte et non de sa position fermée.

La porte peut également être commandée par un Trigger pour s'ouvrir et se fermer. En réglant KDesiredAngle = 16384 et KAltDesiredAngle = 0, on définit la position ouverte et la position fermée. Il suffit alors de changer Object → InitialState → ToggleDesired et d'ajouter un Trigger dont l'event déclenche le tag du KHinge. La porte s'ouvre jusqu'à KDesiredAngle quand le Trigger est activé et se referme jusqu'à KDesiredAngle à la seconde activation (toujours avec la brutalité d'un ressort qui se détend subitement).

Dans toutes les positions, la porte réagit également aux tirs et chocs avec l'effet de ressort. Si la porte est activée avant le premier déclenchement du Trigger, il faut inverser les valeurs de KDesiredAngle et KAltDesiredAngle car la simulation commence alors dès le début du jeu et la porte se rend alors directement à la position KDesiredAngle.

Pour donner un mouvement plus délibéré à la porte, il est possible d'utiliser KHingeType = HT_Controlled. Il faut alors définir la vitesse de rotation de la porte avec KDesiredAngleVel et donner un KMaxTorque assez élevé pour vaincre l'inertie de l'objet, par exemple 100. Si l'InitialState reste ToggleDesired, activer la porte fait parcourir la rotation voulue à l'objet Karma puis l'immobilise. Un nouveau déclenchement la referme. Si elle subit un choc ou un tir, la porte revient en position avec la vitesse voulue au lieu d'osciller comme avec un ressort.

KProportionalGap permet de définir à quel niveau de sa rotation la porte commence à ralentir. Si sa valeur est très basse et la rotation très rapide, il est possible que le KHinge ne parvienne pas à arrêter la rotation avant d'atteindre l'angle voulu, auquel cas la porte oscille autour de l'angle en perdant de la vitesse.

Moteur

Pour créer un ventilateur ou pour simuler une pièce de moteur en rotation, il suffit d'ajouter un objet Karma utilisant un static-mesh approprié, de placer en son centre un KHinge avec KHingeType = HT_Motor et de spécifier la rotation voulue dans KDesiredAngleVel ainsi qu'un KMaxTorque suffisant pour mettre l'objet en mouvement. Le ventilateur se met à tourner à la vitesse voulue dès que la simulation commence (ou dès le début du jeu si KStartEnabled = vrai). Le KHinge doit être orienté perpendiculairement au ventilateur pour que celui-ci tourne autour.

Il est même possible de créer des engrenages. Il existe plusieurs static-meshes de rouages dans les packages d'UT2004, mais beaucoup possèdent des collisions cylindriques très simplifiées qui peuvent pas s'imbriquer.

Il suffit de copier un de ces static-meshes et de fabriquer, pour le duplicat, une collision simplifiée à base de brushes, qui permet aux dents de s'emboîter. Tous les KHinges doivent être réglés sur HT_Normal, à l'exception d'un seul, utilisant HT_Motor, qui doit alors avoir un KMaxTorque assez élevé pour faire tourner le mécanisme complet.

Si la simulation de l'objet Karma régi par le KHinge en HT_Motor est mise en route, sa rotation l'amène à toucher le rouage suivant, qui, en tournant à son tour, entraîne le troisième, etc.

En utilisant un Trigger et les InitialStates disponibles, il est possible d'allumer ou d'éteindre le moteur à volonté. De plus, le KHinge sert de pivot à l'objet, ce qui évite les désagréments qui peuvent être rencontrés avec des static-meshes au pivot très excentré ou mal positionné.

Le KConeLimit peut être utilisé pour limiter le mouvement d'un objet Karma autour d'un KHinge. Ce dernier ne laissant qu'un seul axe de mouvement possible, le KConeLimit doit être aligné perpendiculairement pour avoir un effet. Cela permet de limiter artificiellement les mouvements d'un KHinge en mode HT_Normal autour de son axe, tout en le gardant lâche, comme une girouette. Pour les autres modes, le fonctionnement même du KHinge rend l'utilisation d'un KConeLimit peut souhaitable voire redondant.