إصلاح شامل للرسوم المتحركة في Unigine 2.22: آلات الحالة، ومزج الطبقات، وسير عمل الهيكل العظمي الجديد

سير عمل الرسوم المتحركة الذي دفع مطوري Unigine إلى هجر المحرك

كل مطور يستخدم Unigine اصطدم بالجدار نفسه: المُصيِّر يعرض مشاهد PBR مذهلة بمعدل 120 إطارًا في الثانية، لكن إنشاء مزج بسيط من وضع الوقوف إلى الجري يستغرق ساعة من الحيل البرمجية والتعديل اليدوي على العظام. هذا التفاوت بين الدقة البصرية وأدوات الرسوم المتحركة كان السر المكشوف لـ Unigine لسنوات، وهو السبب الذي يجعل معظم الفرق الصغيرة التي تقيّم Unigine تنسحب في النهاية.

مع Unigine 2.22، عالج الفريق أخيرًا هذه الفجوة بشكل مباشر. يقدّم الإصدار محررًا مرئيًا لآلة الحالة للرسوم المتحركة، ومزج طبقات إضافي مع أقنعة لكل عظمة، وخط أنابيب محسّن لاستيراد FBX مع تعيين الهيكل العظمي الافتراضي (Avatar)، وواجهة برمجة جديدة لتحريف الحركة الإجرائي (Motion Warping). بالنسبة للفرق التي تستخدم Unigine في المحاكاة، أو التصور المعماري، أو التطبيقات الصناعية، والتي ظلت تلصق منطق الرسوم المتحركة يدويًا في الكود لسنوات — هذا يغيّر سير العمل اليومي بشكل كبير.

سيرشدك هذا الدليل إلى ما تغيّر فعليًا، وكيفية الانتقال من الأسلوب القديم المعتمد على البرمجة النصية إلى أدوات آلة الحالة الجديدة، وأين تكون الحالات الحدّية أكثر إيلامًا.

---

ما الذي تغيّر في نظام الرسوم المتحركة في Unigine 2.22

الطريقة القديمة: منطق الرسوم المتحركة عبر البرمجة النصية

قبل 2.22، كان تشغيل انتقال بين حركتين في Unigine يعني كتابة المنطق بنفسك:

// UnigineScript — old pattern, pre-2.22
AnimLayer idle_layer = new AnimLayer();
idle_layer.SetAnimation("idle.anim");
idle_layer.Loop = true;

AnimLayer run_layer = new AnimLayer();
run_layer.SetAnimation("run.anim");
run_layer.Loop = true;

void update(float speed) {
    float blend = clamp(speed / 6.0, 0.0, 1.0);
    if (blend > 0.01f) {
        idle_layer.SetWeight(1.0 - blend);
        run_layer.SetWeight(blend);
    } else {
        idle_layer.SetWeight(1.0);
        run_layer.SetWeight(0.0);
    }
}

هذا يعمل مع نظام من حالتين، لكن توسيعه ليشمل الانحناء، والقفز، والتصويب، والركض السريع، و15 نوعًا من الهجمات يصبح غير قابل للصيانة بسرعة. كل فريق ينتهي به الأمر إلى بناء آلة حالة يدوية في السكربت، وكل فريق ينتهي به الأمر إلى محاربة انقطاعات الانتقال وأخطاء المزج.

نهج 2.22: آلات الحالة التصريحية

يقدّم Unigine 2.22 نظام AnimationGraph — محرر آلة حالة قائم على العقد مدمج في محرر Unigine، مع واجهة برمجة نصية للتحكم في وقت التشغيل. ترتبط الحالات بمقاطع الرسوم المتحركة أو مساحات المزج. وتحدد الانتقالات الشروط والمدد. يتولى المحرك المعالجة الداخلية للاستيفاء، ومزج المقاطعة، وتركيب الطبقات.

أبرز التحسينات:

• محرر مرئي لآلة الحالة — حدد الحالات والانتقالات والشروط في المحرر مع معاينة للرسم البياني
• تكديس الطبقات مع أقنعة العظام — مزج تصويب الجزء العلوي من الجسم فوق حركة الجزء السفلي باستخدام مجموعات عظام مسماة
• دعم الرسوم المتحركة الإضافية (Additive) — تطبيق الميلان، وتوجيه الرأس، والارتداد كإزاحات بدلاً من استبدال الوضعية بالكامل
• استيراد FBX محسّن — تعيين الهيكل العظمي الافتراضي الذي يحافظ على تسلسل العظام عبر أشكال الشخصيات المختلفة
• تحريف الحركة (Motion Warping) — يمكن إعادة توجيه حركة الجذر ومزجها في وقت التشغيل لتسلق العوائق، والقفز فوقها، والانتقالات خلف التغطية

---

إعداد خط أنابيب الرسوم المتحركة الجديد خطوة بخطوة

الخطوة 1: حدد الهيكل العظمي الافتراضي (Avatar) الخاص بك

الهيكل العظمي الافتراضي هو حجر الزاوية في سير عمل 2.22. إنه قالب عظام مسمّى يربط الشبكات الهيكلية من أدوات DCC (Blender وMaya و3ds Max) بهيكل عظمي معياري تعتمد عليه آلة حالة الرسوم المتحركة.

إذا تجاهلت هذه الخطوة — وهذا ما يفعله كثير من المطورين الجدد على النظام — فستُعرض الرسوم المتحركة على عظام خاطئة أو لن تُعرض إطلاقًا. لن يرمي المحرك خطأً؛ بل يستخدم بصمت أول عظمة يجدها باسم مطابق، مما يسبب تشوهات غريبة في العرض.

في لوحة Skeleton Asset في المحرر، عرّف الهيكل العظمي الافتراضي:

// Avatar definition in Unigine's data format
avatar {
    name = "humanoid_standard";
    bones {
        root = "Hips";
        left_arm = "LeftArm";
        right_arm = "RightArm";
        left_leg = "LeftLeg";
        right_leg = "RightLeg";
        spine = "Spine";
        head = "Head";
    }
}

كل أصل شخصية في مشروعك يشارك هذا التعريف للهيكل العظمي الافتراضي. عند استيراد شخصية بشرية جديدة، تقوم بتعيين أسماء عظامها إلى أسماء الهيكل الافتراضي مرة واحدة، وستعمل كل مقاطع الرسوم المتحركة من كل شخصية مع رسوم أي شخصية أخرى. وقت الإعداد النموذجي لهذا التعيين هو 10-15 دقيقة لكل شخصية، مقارنة بالطريقة القديمة التي كانت تتطلب تسمية نقاط الارتساء يدويًا لكل مقطع رسوم متحركة، وهو ما كان يستغرق 30-60 دقيقة لكل شخصية وينكسر كلما أعدت توجيه الرسوم.

الخطوة 2: أنشئ آلة الحالة في المحرر

افتح محرر AnimationGraph من متصفح الأصول في Unigine 2.22. بالنسبة لوحدة تحكم شخصية أساسية، ستحتاج على الأقل إلى:

1. حالة الوقوف (Idle) — رسوم وقوف متكررة، حالة الدخول
2. مساحة مزج الحركة (Locomotion) — مزج ثنائي الأبعاد للمشي/الهرولة/الجري بناءً على معاملات السرعة والاتجاه
3. حالة القفز (Jump) — بداية قفزة غير متكررة وانتقالات في الهواء
4. حالة الهبوط (Land) — تعافٍ مرحلي مع انتقال قابل للمقاطعة للعودة إلى الحركة

كل حالة تشير إلى مقطع رسوم متحركة أو مساحة مزج. تربط الانتقالات بين الحالات عبر معاملات شرطية — أرقام عشرية، أو قيم منطقية، أو مشغلات (Triggers) تقوم بتعيينها من الكود في وقت التشغيل.

[Idle] --(speed > 0.1)--> [Locomotion]
[Locomotion] --(is_jumping == true)--> [Jump]
[Jump] --(on_ground == true)--> [Land]
[Land] --(land_finished == true)--> [Idle]
[Damage_Taken] --(hit_received == true)--> [Flinch]
[Flinch] --(flinch_finished == true)--> [Idle]

الخطوة 3: قُدها من الكود

الجانب البرمجي أصبح أبسط بشكل كبير. بدلاً من حساب أوزان المزج يدويًا، تقوم بدفع قيم المعاملات كل إطار:

// UnigineScript — driving the 2.22 AnimationGraph
ObjectMeshSkinned character_node;
AnimationGraph anim_graph;

int init() {
    character_node = node_cast(engine.editor.getNode("player_character"));
    anim_graph = new AnimationGraph(character_node);
    anim_graph.Load("animations/player_graph.animgraph");
    return 1;
}

int update() {
    float speed = length(character_node.getPositionVelocity());
    bool is_jumping = !character_node.isOnGround();

    anim_graph.SetFloat("speed", speed);
    anim_graph.SetFloat("direction", character_node.getTurnAngle());
    anim_graph.SetBool("is_jumping", is_jumping);
    anim_graph.SetBool("on_ground", character_node.isOnGround());

    if (received_damage) {
        anim_graph.Trigger("hit_received");
        received_damage = false;
    }

    anim_graph.Update();
    return 1;
}

النسخة القديمة من هذا الكود كانت تتكون من 120-180 سطرًا من إدارة المزج اليدوية. النسخة الجديدة أقل من 30 سطرًا لأن منطق آلة الحالة والمزج والانتقالات يعيش داخل أصل الرسم البياني.

الخطوة 4: اضبط مزج الطبقات للجزء العلوي/السفلي من الجسم

بالنسبة لشخصية تحتاج إلى التصويب أثناء الجري، ستحتاج إلى طبقتين للرسوم المتحركة تُدمجان مع أقنعة العظام. في محرر AnimationGraph في 2.22:

الطبقة 0 (الأساسية): آلة حالة الحركة — تؤثر على الوركين والساقين وجوهر العمود الفقري
الطبقة 1 (تجاوز الجزء العلوي): مساحة مزج التصويب — تؤثر على العمود الفقري والذراعين والرأس
الطبقة 2 (إضافية): رسوم الارتداد — إزاحة إضافية على الذراع اليمنى والعمود الفقري

تستخدم أقنعة العظام مجموعات العظام الافتراضية التي عرّفتها في الخطوة 1. يحدد وزن مزج القناع مقدار ما تستبدله طبقة التجاوز من الطبقة الأساسية لتلك العظام. الوزن 1.0 يعني استبدالًا كاملًا؛ و0.7 يعني مزجًا جزئيًا (مفيد لمزج تأثير زاوية التصويب على الجزء العلوي من العمود الفقري).

هذه البنية الطبقية هي السبب الجوهري وراء انتقال الرسوم المتحركة إلى نظام آلة الحالة بدلاً من البقاء مدفوعة بالسكربت. المزج اليدوي للأقنعة ينهار بشكل كارثي عند إضافة طبقة ثالثة أو رابعة. النظام الجديد يتعامل مع ذلك عبر فرض ترتيب تقييم وتركيب الطبقات تسلسليًا قبل مرحلة التجهيز (Skinning).

---

الرسوم المتحركة الإجرائية: تحريف الحركة (Motion Warping) والحركة العكسية (IK)

ما الذي يحله تحريف الحركة

يعيد تحريف الحركة توجيه حركة الجذر في وقت التشغيل. المثال التقليدي: رسوم القفز فوق العائق لشخصيتك تحتوي على حركة جذر تحرك الكبسولة مسافة مترين للأمام، لكن العائق يبعد 1.5 متر فقط. بدون تحريف الحركة، ستبدو الشخصية إما طافية فوق الفجوة أو مخترقة للجدار. مع تحريف الحركة، يتم ضبط هدف حركة الجذر على حافة العائق، وينحني مسار الرسوم المتحركة ليطابقه.

في Unigine 2.22:

// Setting the motion warp target during a vault
Vector3 vault_edge = getVaultEdge(ground_check.point, obstacle.normal);

// The AnimationGraph exposes a warp target parameter
anim_graph.SetWarpTarget("vault_end_point", vault_edge);
anim_graph.Trigger("start_vault");

هذا مهم أيضًا لعملاء Unigine في المجال الصناعي والمحاكاة. أجهزة محاكاة التدريب التي تحتوي على شخصيات بشرية تحتاج إلى تفاعل دقيق مع هندسة البيئة. تحريف الحركة يوفر ذلك دون ضبط يدوي لموضع القدمين لكل رسوم متحركة.

تكامل الحركة العكسية (IK) لتشكيل الوضعيات في وقت التشغيل

يكشف Unigine 2.22 عن محلل حركة عكسية (IK) يعمل بعد تقييم طبقات الرسوم المتحركة. الاستخدامان الأكثر شيوعًا:

حركة القدم العكسية (Foot IK) — إطلاق أشعة من كل مفصل قدم نحو الأسفل، وضبط ثني الساق ليتوافق مع ميلان الأرض. يمنع منظر "الأقدام الطافية 5 سم فوق التضاريس غير المستوية" الذي يطارد معظم مشاريع Unigine.

حركة التصويب العكسية (Aim IK) — تتبع اتجاه الكاميرا أو نقطة التصويب عبر تدوير سلسلة العمود الفقري وتقييد دوران الرأس. أساسي لأي لعبة تصويب من منظور الشخص الثالث مبنية في Unigine.

// Foot IK setup — called each frame after anim_graph.Update()
void applyFootIK(ObjectMeshSkinned node, AnimationGraph graph) {
    Vector3 left_foot_pos = node.getBoneWorldPosition("LeftFoot");
    Vector3 right_foot_pos = node.getBoneWorldPosition("RightFoot");

    float left_ground = castRayGround(left_foot_pos);  // returns Y offset
    float right_ground = castRayGround(right_foot_pos);

    // Smoothly offset the pelvis to the lower foot position
    float pelvis_offset = min(left_ground, right_ground);
    graph.SetFootIKPelvisOffset(pelvis_offset);
    
    graph.SetFootIKTarget("LeftFoot", left_ground);
    graph.SetFootIKTarget("RightFoot", right_ground);
}

ستحتاج أيضًا إلى تمرير بيانات المتجه العمودي لسطح الأرض إلى حركة القدم العكسية — إذا كانت القدمان على منحدر بزاوية 30 درجة، يجب أن يتوافق دوران الكاحل مع ذلك. إذا تجاهلت هذا، ستُوضع القدمان بشكل صحيح على المحور Y لكنها ستدور بشكل مسطح، وستبدو أسوأ من عدم استخدام IK إطلاقًا.

---

إصلاح استيراد FBX: ما يجب الانتباه له

تعيين الهيكل العظمي الافتراضي أثناء الاستيراد

يعالج مستورد FBX المحسّن في 2.22 نقاط الألم التاريخية المتعلقة بعدم تطابق تسلسل العظام. عند إفلات ملف FBX في متصفح الأصول، يقدم الآن:

• اكتشاف تلقائي لاصطلاحات تسمية العظام (Humanoid، Mixamo، مخصصة)
• تعيين الهيكل العظمي الافتراضي — وسم الشبكة المستوردة بهيكل مشروعك الافتراضي
• إصلاح دوران العظام — يعوّض نظام الإحداثيات Z-up في Blender مقابل نظام إحداثيات Unigine (كان هذا يسبب دوران عظمة الرأس بزاوية 90 درجة في المستورد القديم في كل عملية استيراد تقريبًا)
• استخراج مقاطع الرسوم المتحركة — تقسيم ملفات FBX متعددة اللقطات تلقائيًا إلى مقاطع منفصلة

إصلاح نظام الإحداثيات وحده يلغي ما كان يستغرق جلسة تصحيح أخطاء لمدة ساعتين لكل شخصية. في Unigine قبل 2.22، كنت تستورد شخصية بشرية من Blender وتقضي فترة ما بعد الظهر تتساءل لماذا تشير ذراعا الشخصية إلى الخلف. الآن يطبق المستورد تعويض الدوران وقت الاستيراد.

خطأ شائع: عدم تطابق المقياس

الشيء الوحيد الذي لا يصلحه المستورد الجديد تلقائيًا هو مقياس الوحدات. Blender يستخدم المتر افتراضيًا؛ وUnigine يستخدم المتر افتراضيًا؛ لكن Maya و3ds Max يستخدمان السنتيمتر افتراضيًا. إذا تم استيراد شخصيتك بمقياس 100 ضعف الحجم المقصود، تحقق من إعدادات وحدات FBX في نافذة الاستيراد. اضبطها لتطابق أداتك قبل الاستيراد. ما تزال هذه خطوة يدوية، وما تزال أكثر أخطاء الاستيراد شيوعًا في إصدار 2.22.

عدم تطابق المقياس يؤثر أيضًا على تشغيل مقاطع الرسوم المتحركة. الرسوم المتحركة المُخبوزة بمقياس 1 سم لكل وحدة ستنتج حركة جذر أكبر 100 مرة. الرسوم تُعرض، لكن الشخصية تنتقل عبر المشهد في إطار واحد. إذا رأيت هذا السلوك، تحقق من أن مقياس حركة الجذر في خصائص المقطع يطابق مقياس الشبكة.

---

دليل الترحيل: تحويل كود الرسوم المتحركة القديم

إذا كان لديك مشروع Unigine قائم برسوم متحركة مدفوعة بالسكربت، فإن الترحيل إلى نظام AnimationGraph يتم بشكل تدريجي — لست بحاجة إلى إعادة كتابة كل شيء دفعة واحدة.

الخطوة 1: راجع طبقات الرسوم المتحركة الموجودة

احسب عدد نسخ AnimLayer التي ينشئها مشروعك في وقت التشغيل. معظم مشاريع Unigine تحتوي على ما بين 4 و12 طبقة لكل شخصية. كل طبقة تقابل حالة في الرسم البياني الجديد أو طبقة في مجموعة الطبقات.

الخطوة 2: اربط الطبقات بالحالات

أنشئ أصل AnimationGraph وأضف حالات تطابق أسماء طبقاتك. بالنسبة للطبقات التي تُمزج بشكل إضافي، اجعلها طبقات إضافية في الرسم البياني بدلاً من إنشاء حالات مزج غير إضافية.

الخطوة 3: حافظ على المعاملات المدفوعة من الكود

كودك الحالي يحسب بالفعل أوزان المزج وقيم السرعة وشروط التشغيل. أعد هيكلة هذه القيم لدفعها إلى الرسم البياني بدلاً من تعيين أوزان الطبقات مباشرة. يبدو الترحيل هكذا:

// BEFORE — direct layer manipulation
void updateMovement(float speed, float angle) {
    locomotion_weight = clamp(speed / max_speed, 0.0, 1.0);
    idle_layer.setWeight(1.0 - locomotion_weight);
    locomotion_layer.setWeight(locomotion_weight);
    blend_parameter.setFloat(angle);
}

// AFTER — parameter-driven state machine
void updateMovement(float speed, float angle) {
    anim_graph.SetFloat("speed", speed);
    anim_graph.SetFloat("direction", angle);
}

الخطوة 4: أزل منطق السكربت الزائد

بمجرد أن تتولى آلة الحالة الانتقالات والمزج، يمكنك حذف كود الاستيفاء اليدوي، والتسهيل (Easing)، وتقييد الأوزان. في المشاريع التي تم تحويلها حتى الآن، تقلصت سكربتات الرسوم المتحركة بنسبة 60-75% من حيث عدد الأسطر. المنطق لا يختفي — بل ينتقل إلى أصل الرسم البياني، الذي يمكن التحكم في نسخه وتحريره في المحرر المرئي.

---

اعتبارات الأداء

تقييم الرسم البياني للرسوم المتحركة ليس مجانيًا. إليك الأرقام الفعلية للعبء الإضافي:

السيناريو	الأسلوب القديم بالسكربت	آلة الحالة (2.22)
شخصية واحدة، حركة أساسية	~0.02ms	~0.03ms
شخصية واحدة، 3 طبقات + IK	~0.06ms	~0.04ms
50 شخصية، رسوم متحركة مختلطة	~3.2ms	~1.8ms
200 شخصية، مع تفعيل LOD	~8.5ms	~4.1ms

نظام آلة الحالة أثقل لكل شخصية على المستوى الأساسي بسبب عبء تقييم الرسم البياني. لكنه يكتسب كفاءة مع الشخصيات متعددة الطبقات لأن المزج يتم داخل المحرك بدلاً من استدعاءات متعددة لتعيين الأوزان عبر السكربت في كل إطار. عند 50+ شخصية، يكون نظام آلة الحالة أسرع بنحو 40-50%.

تقييد رسوم LOD المتحركة هو رافعة التحسين الأساسية لديك. يدعم Unigine 2.22 معدلات تحديث للرسوم المتحركة لكل مستوى LOD. الشخصيات التي تبعد أكثر من 30 مترًا يمكن تحديثها كل 3 إطارات؛ والشخصيات التي تبعد أكثر من 80 مترًا يمكن تحديثها كل 8 إطارات. اضبط ذلك في إعدادات LOD الخاصة بـ AnimationGraph:

LOD_0: 0-15m    -> full frame rate
LOD_1: 15-30m   -> every 2nd frame
LOD_2: 30-80m   -> every 4th frame
LOD_3: 80m+     -> every 8th frame, disable IK

هذا وحده يمكن أن يقلل تكلفة معالجة الرسوم المتحركة على المعالج بنسبة 60-70% في مشاهد العالم المفتوح التي تحتوي على العديد من الشخصيات غير القابلة للعب (NPCs).

---

أفضل الممارسات للترحيل إلى رسوم 2.22 المتحركة

1. حدد الهيكل العظمي الافتراضي أولاً، قبل إنشاء أي أصول AnimationGraph. الترحيل إلى هيكل افتراضي موحد بعد بناء 20 أصل رسم بياني يعني إعادة تعيين كل مرجع عظمة يدويًا — وهذا أمر يمكن تجنبه إذا خططت مسبقًا.

2. أبقِ آلات الحالة مسطحة قدر الإمكان. يدعم AnimationGraph في Unigine آلات حالة فرعية متداخلة، لكن الرسوم البيانية شديدة التداخل (3+ مستويات) تصبح صعبة التصحيح بصريًا. إذا كان رسمك البياني يحتاج أكثر من 20 حالة، قسّمه إلى رسوم بيانية منفصلة لأجزاء معينة من الجسم أو سياقات محددة (قتال مقابل استكشاف).

3. استخدم المشغلات (Triggers) للأحداث التي تحدث مرة واحدة، وليس القيم المنطقية. مشغل hit_received يُطلق مرة واحدة ويُعاد ضبطه تلقائيًا. القيمة المنطقية is_hit تبقى صحيحة حتى تقوم بتعيينها خطأً صراحةً، مما يتسبب غالبًا في تكرار الرسوم المتحركة إلى ما لا نهاية عندما ينسى المطورون إعادة الضبط.

4. قم بقياس الأداء باستخدام لوحة Animation Profiler قبل الترحيل وبعده. يعرض ملف الأداء في Unigine 2.22 الآن زمن المعالجة لكل حالة، وتكلفة تقييم المزج، وعدد تحويلات العظام لكل شخصية. استخدمه لتحديد الحالات المكلفة — تشغيل Aim IK على شخصيات لا تصوّب هو أكثر أشكال الهدر شيوعًا.

5. اختبر انتقالات حالات الرسوم المتحركة عند معدلات إطارات متطرفة. عند 12-15 إطارًا في الثانية (وهو شائع على الأجهزة منخفضة المواصفات أو عندما يكون المعالج الرسومي مشبعًا)، يمكن أن تنتج الانتقالات السريعة بين الحالات فجوات في التقييم تظهر كوضعية T-pose لإطار واحد. استخدم محدد معدل الإطارات لاختبار الانتقالات تحت الحمل قبل الإصدار.

---

ماذا يعني هذا بالنسبة للمركز التنافسي لـ Unigine

إصلاح الرسوم المتحركة في Unigine 2.22 لا يجعل المحرك منافسًا لـ Control Rig في Unreal أو حزمة Animation Rigging في Unity بين ليلة وضحاها. تلك الأدوات تمتلك سنوات من التطوير وأصول مجتمعية ضخمة خلفها. لكن ما يفعله 2.22 هو إزالة السبب الرئيسي الذي جعل الفرق ترفض Unigine أثناء التقييم التقني.

بالنسبة للفرق الملتزمة بالفعل بـ Unigine — خاصة في المحاكاة، والهندسة المعمارية، والتصور الصناعي حيث تكون كفاءة استدعاءات الرسم وأداء المشاهد الكبيرة أمرًا أساسيًا — يزيل هذا الإصدار آخر فجوة رئيسية في سير العمل. محرر آلة الحالة المرئي وحده يقلل وقت إعداد الرسوم المتحركة لمشروع شخصية جديد من 2-3 أيام إلى 4-6 ساعات، بناءً على تقارير الترحيل المبكرة من الاستوديوهات التي تعمل بنسخة 2.22 التجريبية.

إذا كان كود الرسوم المتحركة في مشروع Unigine الخاص بك يحتوي على أكثر من 500 سطر من منطق المزج، فإن أدوات آلة الحالة في 2.22 ستبسطه بشكل كبير. ابدأ بدورة الوقوف-الحركة-القفز لشخصية اللاعب الرئيسية كترحيل تجريبي لإثبات المفهوم، ثم انشر النمط إلى شخصيات NPC والشخصيات الثانوية.

---

الخطوات التالية

نزّل Unigine 2.22 من صفحة Unigine SDK الرسمية وافتح مشروع تعليم AnimationGraph المرفق مع نماذج SDK. يعرض المشهد النموذجي شخصية بشرية بثلاث طبقات مع مزج الحركة، وAim IK، وتحريف الحركة جاهزة للاستخدام. أعد تطبيق هذا الإعداد مع أصول شخصيتك الخاصة قبل بناء رسم بياني مخصص من الصفر — إنها أسرع طريقة لفهم خط أنابيب التقييم وتحديد أين يتوافق كود الرسوم المتحركة الحالي مع النظام الجديد.

---

المصدر: إصدار Unigine 2.22