المقالات العلمية

هذه المقالة محمية ضمن الحقوق الفكرية لشركة In|Framez Technology Corp.، ومرخصة للعرض فقط ضمن الشبكة العربية لمطوري الألعاب مع الموافقة الصريحة من المؤلف وشركة In|Framez Technology Corp.. لا يسمح بإعادة نشر هذه المقالة أو تعديلها دون الرجوع للمؤلف. يمنع النسخ والاقتباس دون ذكر المصدر والموافقة من المؤلف.

مقدمة المقدمة للمقدمة

لا شك أننا لاحظنا النمو الكبير في عالم تصميم وإنتاج الألعاب الثلاثية الأبعاد، والذي بدأ يغزو حتى العالم العربي. من هذا المنطلق، وكي لا نبقى خلف الـ.. إحم... سنبدأ بسلسلة من الحديث المركز حول موضوع التصميم للألعاب. ماهي متطلباته؟ بم يختلف عن التصميم الـ 3D للتطبيقات العادية؟ ما هو محرك اللعبة؟ إلى آخر هذا الهراء الذي بدأ يظهر لنا في كل مكان... في هذا العدد، سنذكر بعض الفروق والاعتبارات التي يجب الانتباه لها أثناء التصميم للألعاب. المعلومات هنا مترجمة بشكل مباشر من مقالة قمت بتأليفها سابقاً على موقع In|Framez. المقالة هناك بالإنجليزية ويمكن تحميل مرفقاتها أيضاً من صفحة المقالة:

http://www.inframez.com/papers/realtime_teatime.htm

هذه المعلومات عامة ويمكن تطبيقها على برامج الـ 3D الحديثة مع بعض الفروق البسيطة... آه وبالمناسبة، هذه المقالة كتبتها أثناء عملي في وضع التصميم الأولي لنظام التعامل بين الإصدار الثالث من محرك الألعاب DirectSkeleton وبرامج الـ 3D المتوفرة في ذلك الوقت... لذلك قد تجد الكثير من الأمور التي تم تطويرها وتحسينها من جهة برامج الـ 3D المختلفة ومحركات الألعاب... ولكن مع ذلك المفاهيم الأساسية هنا مازلت كما هي.

نقطة أخيرة، الملف المرفق مع المقالة الأصلية يحتوي على مشهد مبني في Softimage|XSI. هذا المشهد يحتوي على أمور أو "مشاكل" معينة سنستفيد منها في إظهار وتوضيح النقاط التي ستمر معنا خلال هذه المقالة. بينما هذا الملف مخصص لـ XSI، إلا أن هذه الأمور عامة على جميع البرامج وتتفاوت بأهميتها بين برنامج لآخر.

مقدمة المقدمة

لا بد أن غالبيتنا من مصممي الـ 3D قد اعتاد على العمل باستخدام تقنيات متقدمة أثناء سير المشروع في إنتاج 3D للأفلام. المشكلة أن 90% من هذه التقنيات غير واردة عندما يكون العمل موجهاً لعالم ألعاب الكمبيوتر.

المشكلة نابعة أساساً من محدودية إمكانيات أجهزة اللعب هذه الأيام. وهكذا، علينا أن نخضع لهذه المحدوديات إن أردنا حقاً أن يرى عملنا النور من خلال نافذة اللعبة.  نعم هذه فترة انتقالية علينا أن نعايشها ريثما تتقدم (وترخص) التجهيزات القادرة على القيام بعمليات ray-tracing بشكل فوري (real-time) وغيرها من العمليات المعقدة، لتوصل لللاعب ما نتخيله نحن تماماً بدون أية محدوديات. وحتى ذلك الحين، بعضنا قد يكون قد أصبح بالقبر مع والت ديزني!

إذن، إن كنت تريد إنتاج بعض الـ 3D للألعاب قبل أن تنتهي صلاحيتك، عليك أن تتمكن من ضبط هذه القيود الغبية إلى الدرجة التي تسمح لك بالحصول على جودة جيدة، مع مراعاة المحدوديات القائمة.

تحسين الأداء (optimization) هو المفتاح هنا. هذا هو كل ما هنالك، وهذا هو ما سنتكلم عنه اليوم.

المقدمة

تطورت جميع برامج تصميم الـ 3D لتشمل أدوات إضافية مخصصة للعمل مع مواد الألعاب. حسنا��، أعترف. هناك بعض النكشات التي تربض هنا وهناك، والتي سأنوه عن بعضها في هذه المقالة حالما نواجهها. ولكن المهم هنا أن جميع برامج الـ 3D لها حلول معينة تتبجح بها شركات هذه البرامج لتسهيل إنتاج مواد الألعاب. الحل عادة يتشكل من بعض التوجيهات، نوعية ملفات خاصة يمكن للعبة التعامل معها، بالإضافة لبعض الأوامر الخاصة.

هذه المقالة ترسم بعض الخطوط العريضة التي يجب أن نبقيها في البال عندما نصمم مواد للألعاب وتطبيقات الـ 3D الفورية. مع هذه المقالة، أرفقت مشروع XSI يحتوي على مجموعة من المشاهد لشخصية محسنة للـ real-time صنعها أحد زملائي في العمل للعبة ما. تأكد من تحميله واستخدامه لتطبيق التقنيات التي سنتكلم عنها قريباً. إذن، فلنبدأ...

إعرف عدوك

كما في أي إنتاج فلمي، مواد الألعاب تحتاج إلى بناء، تحريك، وإدارة تقنية، وجميع الأمور الأخرى التي اعتدنا عليها في الإنتاج الفلمي. ولكن في عالم الألعاب لدينا تركيز أكثر على عملية التحسين (optimization)، بالإضافة إلى عملية جديدة تدعى: Real-time shaders setup. وعملية ثالثة (وهي أهمها غالباً) هي تجهيز المواد للتصدير إلى محرك الـ 3D.

قبل أن تبدأ العمل بالمشروع، إجلس مع قائد المبرمجين في المشروع، اطلب له عصيراً، وناقش معه جميع الأمور التي يستطيع (أو لايستطيع) معالجتها من موادك. مثلاً، هل يدعم المحرك الحركة (animation)؟ (طبعاً يجب أن يدعمها)، لأي درجة؟ هل يدعم منحنيات حركة تكعيبية (cubic interpolation)؟ أم فقط خطية (linear fcurves)؟ أظن أن الفكرة وصلتك؟

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

آه، موضوع آخر... عبر هذه المقالة، سيكون هناك عبارة صغيرة سأكررها مراراً وتكراراً، فقررت أن أجد اختصاراً لها. إذا قرأت TFELY فمعناها "المحرك اللعين يحد من إمكانياتك".

مضلعات (polygons) أم NURBS؟

كما نعرف، هناك عدة طرق لبناء المجسمات (meshes). وعادة يترك الخيار للمصمم في استخدام الطريقة التي يفضلها. القرار يتخذ عادة وفقاً لمهاراته، وبنية المجسم. فمثلاً، قد يجد المصمم أن تشكيل جزرة بالـ NURBS أسهل وأسرع من تشكيلها من مضلعات مجردة. ولكن بشكل عام، عندما نتكلم عن الـ real-time، فإن المجسمات المبنية من المضلعات هي الفائزة. هذا بسبب كون أغلب المحركات لا تدعم بشكل مباشر الـ NURBS، لذا عليها أن تقوم بتحويل الـ NURBS إلى مضلعات (tesselation) بشكل أوتوماتيكي أثناء اللعب، وهي ليست بالعملية السريعة أبداً (أحد الألعاب التي دعمت الـ NURBS بشكل مباشر لعبة Messiah). المشكلة تكمن في الواجهات البرمجية الأساسية بحد ذاتها (كـ Direct3D)، فهي لا تدعم إظهار الـ NURBS. لذا، في النهاية، يجب تحويل الـ NURBS إلى مضلعات. وإذا قمت بهذه العملية باكراً، قد تحصل على فرصة أفضل للقيام بتحسينات أكثر.

في حالة XSI، يمكنك دائماً تحويل أي مجسم NURBS إلى مضلعات بأي وقت، لكن تذكر أنك ستفقد الـ UV coordinates، لذا دائماً قم بالإكساء بعد تحويل الـ NURBS إلى مضلعات. على كل حال، هذه حالة TFELY أخرى.

يمكنك فتح المشهد "model.scn" ومقابلة السيد ‘جاك النصاب‘ بعد أن قامت عصا التحسين السحرية بسحره لإزالة كل المضلعات الإضافية منه، مستبدلة إياها بـ render-mapped texture.

أوزان، envelope، تلبيس، وإلى آخر هذا الهراء...

في أحد الأيام، استطعت أن أنسق تلك الجلسة المنتظرة مع مبرمج محرك الـ 3D لدينا، واستطعنا أن نجد حالة TFELY جديدة وأساسية، تكمن في عملية الـ envelope أو الـ skin. أغلب بطاقات العرض الرخيصة في سوق اليوم تسمح فقط بأربعة مؤثرات (عظمات bones) كحد أقصى على كل مجسم. مثلاً، هذه هي الحال في معالجات بطاقات nVIDIA المسماة Geforce256 و Geforce2. إذا كنت تريد جعل هذه البطاقات أداء حسابات الـ envelope بشكل مسرع (hardware accelerated) فعليك تقسيم المجسم إلى أجزاء أصغر، بحيث يتأثر كل قسم بشكل أعظمي بأربعة عظمات بنفس الوقت. في هذه الحالة، عليك أن تكون منتبهاً إلى نواظم المضلعات عند شقف المجسم من أجل الحفاظ على نعومتها واستمراريتها. للأسف، في XSI2 (أو أقدم) عندما تشقف المجسم يعيد البرنامج توليد النواظم للمضلعات المتأثرة، مما يسبب عدم استمرارية في الإضاءة في أماكن الفصل.

 
هذا يتطلب تحايل على الحيلة. يمكنك إنجاز هذه المهمة في Softimage|3D حيث يمكنك التحكم بالنواظم بـ "edit shading normals" أو استخدام الـ "normals modifying add-on" لـ XSI 3 لإصلاح الأمور. في ملف "envelope.scn" يمكنك رؤية نسختين من نفس الشخصية. واحدة مع أجزاء مفصولة مع envelope بعدد أقصى 4 مؤثرات، والآخر ‘حتة واحدة‘ باثنين وعشرين مؤثراً. عندما تنتهي من تقسيم و إنجاز الـ envelope للمجسم، تبقى لديك مهمة إضافية واحدة، وهي تحديد الـ deformers.

يحدد برنامج XSI لمؤثر سلسلة العظام (bone chain effector) التي تختارها أوزان صفرية ضمن أوزان الـ envelope، بالرغم أنك لم تختره كجزء مؤثر. لذا عليك أن تزيله يدوياً لتتخلص من المؤثرات الغير فعالة على مجسمك (وهي سيئة جداً بالمناسبة، صدقني). ستجد ضمن مرفقات المقالة ملف سكريبت (Script File) مساعد يقوم بهذه الخطوة بشكل أوتوماتيكي لك. إقرأ الملاحظات في بداية الملف لمزيد من المعلومات.

في كل مرة تقوم بالـ enveloping، يضيف XSI مجموعة من الـ clusters إلى مجسمك لحفظ معلومات الأوزان. بعض هذه الـ clusters مرئي ويمكنك الوصول إليها مباشرة من الـ explorer، ككلسترات "EnvelopeWeightsCls". ولكن، هناك clusters أخرى مخفية لا يمكنك اختيارها مباشرة، مثل "EnvelopeSelCls#" المستخدمة لتعليم نقاط المجسم بألوان رمزية تعاون على معرفة انتمائية كل نقطة لأي مؤثرات عليها. عدد هذه الـ clusters يعتمد على عدد الـ deformers، مما يعني أنه يمكن أن تحصل على 34 cluster إضافي لشخصية نظامية enveloped. حاول إحصاء عدد هذه الـ clusters على نفس الشخصية المضلعة من "envelope.scn" باستخدام ملف السكريبت التالي: "cluster_info.vbs" في XSI.

ترك هذه الـ clusters الإضافية للتصدير مع المشهد سيتسبب بتضخم حجم الملف النهائي بشكل غير مقبول، مما يعني زمن تحميل ومعالجة أطول (مما سيجعل المبرمجين غير سعداء بعملك). ما نحتاج إلى فعله هو -ببساطة- أن نتخلص من جميع الـ clusters الإضافية التي لن تستفيد لعبتنا من وجودها، ككلسترات الترميز اللوني. للأسف، إزالة مثل هذه الـ clusters من كل مجسم هي عملية مرهقة، خاصة أن هذه الـ clusters مخفية ولا يوجد طريقة مباشرة للوصول إليها وحذفها كأية clusters أخرى. وهكذا، نضطر للعودة إلى السكريبت لأداء هذه المهمة الغبية. يمكنك استخدام هذا السكريبت "filter_cls.vbs" (والذي كتبته أثناء عملي في ديمو DOTT) من أجل ترشيح وحذف هذه الـ clusters الإضافية. نفذ ملف السكريبت على الشخصية الـ enveloped في "envelope.scn" لترشيح الـ clusters الغير مرغوب بها. بعد الانتهاء من تحسين مجسماتك، عليك أن تجربها لتتحقق من كونك لم ترتكب خطأ ما قبل الانتقال للخطوة التالية.

التعامل مع الحركة

في أغلب برامج 3D اليوم (لا سيما XSI)، يوجد مفاهيم حركة تعتبر غريبة جداً على مبرمجي ألعاب اليوم (كالـ Animation Mixer). بالرغم من أن محركات الألعاب قد بدأت باستخدام mixers مبسطة لمزج الحركات، إلا أنها ما تزال "ساذجة" وبعيدة عن درجة تعقيد أنظمة الحركة في برامج اليوم. من آخره، لا يمكنك نقل مفاهيم الحركة كما هي إلى الألعاب.

بشكل رئيسي، مستوى الحركة الذي يمكنك الوصول له يعتمد على المحرك وصيغة الملفات التي ستصدر مشاهدك إليها لفتحها باللعبة. بحالة ملفات dotXSI، لا يمكنك لوم صيغة الملفات، لأنها نظرياً تستطيع التعبير عن جميع معلومات الحركة التي تعتبر ذات معنى بالنسبة للعبة إما عن طريق قواعد الملف الجاهزة (templates)، أو معلومات مخصصة أخرى (custom parameters). إذن، هذه حالة TFELY أخرى. بالحديث عن الـ custom parameters، هؤلاء الشباب يلعبون دور الجوكر بالنسبة لـ dotXSI. يعملون لكل شيء ويستطيعون التعبير عن أي شيء!

في أي وقت تريد تصدير معلومات تحريك لعنصر غير مدعوم بشكل مباشر في dotXSI، كل ما عليك أن تفعله هو نسخ معلومات الحركة إلى custom parameter وترك الباقي على المحرك اللعين. مثلاً، الإصدار الثالث من محرك DirectSkeleton يقبل معلومات الحركة لأي عنصر معروف (مثلاً، لون الـ material، زاوية فتل الكاميرا، الإزاحة والفتل والتحجيم SRT، Shape Animation... الخ) بالإضافة إلى وصلة مفتوحة لتمرير معلومات حركة للـ custom parameters عن طريق إجراءات معرفة من قبل مستخدم المحرك.

إذن، علينا أن نحول كل المعلومات في الـ Animation Mixer كالتعابير الرياضية، القيود الحركية، ومعاملات السكريبت، إلى fcurves اعتيادية قبل تصدير المشهد. فلنجرب هذه العملية فوراً. افتح الملف "animation.scn"، ثم أضف كليب الحركة "Hard_Run" من مكتبة XSINet المحلية إلى الـ mixer المسمى "ManSkeleton_Compatible". نحتاج إلى تحويل الحركة إلى fcurves باستخدام أمر "Apply Action". فنختار مصدر الحركة "Hard_Run" من الـ explorer، ونضغط "Apply Action" في واجهة الـ Motion. بعد ذلك، نحذف الـ mixer فقط لنتأكد أنه لن يتم تصدير هذه المعلومات. بعد الانتهاء من تحويل الحركة، بقيت لدينا مهمة واحدة. وهي تحسين الـ fcurves الناتجة. استخدم أدوات تنظيف الـ fcurve (fcurve fitting tools) في الـ animation editor لتحصل على fcurves أبسط وأخف. نعم! هذا سيجعل المبرمج سعيداً في عمله.

إكساءات ومواد mentalRay وما شابهها هي مجرد حلم

بالرغم من أن أجهزة اللاعبين اليوم تدعم الـ shaders بشكل أو بآخر، إلا أنها ما زالت بعيدة عن إمكانية أداء الحسابات الثقيلة كتلك التي يقوم بها mentalRay. لبطاقات العرض إمكانية تشغيل shaders فورية، إى أنها بسيطة ومحدودة جداً (عليها محدودية حتى بعدد التعليمات التي يمكن أن تنفذها!). طالما أنه حكم علينا الاعتماد على الـ materials التي يقدمها OpenGL أو DirectX (أيهما يدعمه المحرك)، فقد يكون تصرفاً حسناً أن نزيل الـ materials التي تحوي shaders لـ mentalRay من الـ render tree، لأنك قد تخدع نفسك برؤية شيء قد لا تراه في المنتج النهائي.

حذف الـ shaders الخاصة بـ mentalRay يخفف أيضاً من حجم الملف النهائي للمشهد بإغفال بارامترات الـ shader العديدة (الـ simple phong وحده له حوالي 20 بارامتر مختلف).
لاحظ أنك إذا كنت تصدر المشهد إلى dotXSI 3.0، فإن كل الـ render tree ستختزل وتستبدل بعقدة soft_material بسيطة. قد تحتاج لبعض السكريبت هنا لأتمتة عملية تحويل shaders الـ mentalRay إلى real-time shaders، مما يهون عليك حياتك.

عمليات الترتيب والتجميع

كما لاحظت سابقاً، العديد من مهام ‘ما-قبل-التصدير‘ يمكن أتمتتها بملفات سكريبت بسيطة. حالما تكتبها، يمكنك جمعها كلها مع بعضها بملف سكريبت واحد لسهولة الاستخدام.
وإن كنت مصاباً بلغة برمجة مثل ++C يمكنك بناء نسخ مترجمة واستخدامها كوحدة مخصصة للمحرك. هذه الخطوة جد مهمة، خاصة إن كان هناك الكثير من الأشخاص يعملون على نفس المشروع، وكلهم متدخل بعملية التصدير إلى الـ real-time.

لمن يدق الجرس

لقد طبقت جميع مهام التنظيف والتحسين بالفعل، وأخيراً قمت بتصدير الملف.

الآن تر��يه في وجه المبرمج وتقول:

خذ عملك يا صاح! لقد انتهيت.

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

آلو؟

وفجأة تنفتح أبواب جهنم في وجهك:

ماذا فعلت أيها البابون الكبير؟

ببراءة ترد:

ماذا؟

والعاصفة تستمر في الزئير:

الشخصية الأخيرة التي صدرتها

نعم؟

إنه يمشي على رأسه بدلاً من قدميه!

العالم يبدأ بالتلاشي ببطء من حولك ويتحول إلى سواد في عينيك وتسقط مغشياً عليك.

سعدو! سعدو! أين أنت؟ يجب أن تصلح هذا الشيء اللعين! سعدو! أجب يا غبي!

من جهة أخرى، لو كان سعدو أكثر صبراً، لما وقع في مثل هذا الموقف. لقد نسي أن يستعرض ويصحح الأخطاء التي قد تنتج أثناء التصدير. هذه نقطة مهمة جداً وأساسية. لكل صيغة ملفات أدواتها الخاصة التي تمكنك من معاينتها. في حال dotXSI، يمكن استخدام XSI Viewer لمعاينة المعلومات التي صدرتها، أو باستخدام عارض مخصص يعتمد على المحرك. في بعض الحالات الخاصة، المعاينة لا تكفي. قد تحتاج لفتح وإصلاح الملف بشكل يدوي لمعالجة بعض الأخطاء. (في هذه الحال يمكنك استخدام XSIDump لمتابعة الخطأ وإصلاحه في ملفات dotXSI).

الآن، افتح الملف "export.scn" واستخدم أمر "dotXSI export" لتصدير المشهد إلى dotXSI. لاحظ كيف يتم استبدال العظمات بـ nulls للتأكد من أن الملف يمكن فتحه بأغبى محرك موجود. تحقق من الملف، وتأكد من أنه صحيح. عندما ينتهي هذا، يمكنك رمي الملف في وجه المبرمج ثانية. في هذه المرة، إن صاح رئيسك عليك، فقط قل:

اسمع يا سيد! أنا لست الشخص الذي يجب أن تصيح عليه عندما لا يعرف ذاك المبرمج الغبي كيف يقرأ الملف! الملف صحيح ويمكنك التحقق من ذلك بنفسك!

وفي هذه المرة يصبح دور المبرمج لتسود الدنيا في عينيه. إنه خطؤه في النهاية!

الموت للمبرمجين! (أمزح فقط)