«تست موتور اول»؛ راهکاری برای رفع نقص متریال‌های سه‌بعدی در بازی‌سازی

تصور کنید یک مدل سه‌بعدی خیره‌کننده در مرورگر می‌بینید، اما به محض وارد کردن آن در محیط بازی، مدل یا غیب می‌شود یا با متریال‌های صورتی و شکسته ظاهر می‌گردد. یک دارایی سه‌بعدی تولیدشده توسط هوش مصنوعی تا زمانی که از «تست موتور اول» سرباز نزند، یک شیء آماده برای تولید نیست. در تاریخ ۱۰ اوت ۲۰۲۶، یک چارچوب فنی جدید با جزئیات منتشر شد تا شکاف میان تولید توسط هوش مصنوعی و پیاده‌سازی در زمان واقعی در موتورهای Unity و Godot را پر کند.

بسیاری از سازندگان، پیش‌نمایش باکیفیت در ابزارهای هوش مصنوعی را با آمادگی برای موتور بازی اشتباه می‌گیرند. در واقعیت، دارایی‌هایی که در مرورگر عالی به نظر می‌رسند، اغلب به محض قرارگیری در صحنه بازی به دلیل محورهای (Pivots) شکسته، نرمال‌های وارونه یا تعداد چندضلعی‌های (Polygon) غیرقابل تحمل، شکست می‌خورند. این شکاف باعث ایجاد یک چرخه «بدهی فنی» (Technical Debt) می‌شود که در آن توسعه‌دهندگان زمان بیشتری را صرف اصلاح مصنوعات و خطاهای هوش مصنوعی می‌کنند تا زمانی که اگر مدل را از صفر می‌ساختند، صرف می‌کردند. این چالش دقیقاً همان جایی است که تضاد میان حس بصری اولیه و قابلیت اطمینان فنی در محیط تولید خود را نشان می‌دهد.

برای حل این مشکل، این گردش‌کار یک «تست دود» (Smoke Test) تکرارپذیر را معرفی می‌کند. شما یک دارایی واحد را در یک صحنه خنثی با یک نور و یک دوربین قرار می‌دهید. هدف در اینجا تأیید زیبایی‌شناختی نیست، بلکه اعتبارسنجی فنی تبدیل‌ها (Transform)، متریال‌ها و هزینه پردازشی در زمان اجرا است. این تست باید کوچک و تکرارپذیر باشد. شما باید تبدیل‌ها و متریال‌ها را بازرسی کنید، صحنه را اجرا کنید، در صورت نیاز برخورد (Collision) یا تعامل را تست کنید و هر مشکل را ثبت نمایید. موفقیت در وارد کردن فایل تنها اولین گیت است؛ دارایی همچنان پیش از تبدیل شدن به یک شیء تولیدی در بازی، به پاک‌سازی نیاز دارد.

گیت بازرسی پیش از خروجی

بر اساس راهنمای dev.to، پیش از آنکه دارایی هرگز با موتور بازی تماس پیدا کند، باید از یک بازرسی پیش از خروجی عبور کند. شما باید بر اساس نقش دارایی تصمیم بگیرید که تست موتور اول چه چیزی را باید ثابت کند. یک مدل پیش‌زمینه (Prop)، شخصیت، قطعه محیطی، شیء قابل جمع‌آوری، ماکت محصول یا شیء سه‌بعدی رابط کاربری (UI)، هر کدام به شواهد متفاوتی نیاز دارند. برای جلوگیری از ایجاد گلوگاه در خط لوله تولید، باید برای هر مشکل احتمالی یک «مسئول شکست» (Failure Owner) تعیین شود.

• هدف دارایی: تعیین اینکه آیا شیء یک مدل ایستا، دارایی محیطی، شخصیت، شیء متحرک، شیء برخورد یا یک نمونه اولیه وب/بازی است. مقصد تعیین می‌کند که کدام داده‌ها باید در هنگام وارد کردن باقی بمانند. مسئول شکست: تهیه‌کننده یا طراح.
• انتخاب فرمت: انتخاب بین FBX، GLB، glTF، OBJ یا هر فرمت مورد نیاز دیگر. انتخاب فرمت اشتباه می‌تواند داده‌های اسکلت، محورها، سلسله‌مراتب یا متریال‌های PBR (رندرینگ مبتنی بر فیزیک) — شبیه به تعریف دقیق خواص واقعی مواد مثل فلز یا شیشه برای نور — را حذف کند. مسئول شکست: مالک خط لوله (Pipeline Owner).
• وضعیت مش (Mesh): بررسی حفره‌های آشکار، نرمال‌های وارونه، تعداد بیش از حد چندضلعی‌ها، پوسته‌های جدا شده، سطوح تکراری و هندسه‌های پنهان. موتورها می‌توانند مش‌های شکسته را وارد کنند که بعداً در تست‌های نورپردازی، برخورد یا عملکرد شکست می‌خورند. مسئول شکست: هنرمند سه‌بعدی یا هنرمند فنی.
• بسته بافت (Texture): تأیید پوشه بافت‌ها، نام نقشه‌ها، اسلات‌های متریال، نقشه‌های PBR، فضای رنگی، رزولوشن و قراردادهای بسته‌بندی (Packing). متریال‌ها اغلب زمانی می‌شکنند که مسیرهای بافت یا انتظارات شیدر تغییر می‌کند. مسئول شکست: هنرمند متریال.
• مقیاس و محور: اطمینان از واحدها، جهت‌گیری، مبدأ (Origin)، مکان محور، تماس با زمین و ابعاد شیء. مقیاس یا محور اشتباه، جایگذاری، انیمیشن، فیزیک و تعامل را دشوار می‌کند. مسئول شکست: هنرمند فنی.
• انیمیشن و ریگ (Rig): بررسی اسکلت، حالت Bind Pose، کلیپ‌ها، حرکت ریشه (Root Motion)، دفرمه شدن و نیازهای بازنشانی (Retargeting). یک مش ممکن است وارد شود اما به محض اعمال اولین حرکت، شکست بخورد. مسئول شکست: ریگر یا انیماتور.

گردش‌کار وارد کردن در Unity

برای کاربران Unity، فرآیند روی تب‌های Model، Rig و Animation متمرکز است. فایل‌های مدل Unity می‌توانند شامل مش‌ها، ریگ‌ها، کلیپ‌های انیمیشن، متریال‌ها و بافت‌ها باشند. تست اول تأیید می‌کند که تنظیمات واردکننده (Importer)، نقش مورد نظر دارایی را حفظ کرده است.

توسعه‌دهندگان باید ابتدا فایل خروجی و پوشه بافت‌ها را در پوشه Assets پروژه Unity قرار دهند. در تب Model، باید Scale Factor و تنظیمات 'Convert Units' را بررسی کنید تا با اشیایی بیش از حد بزرگ یا میکروسکوپی مواجه نشوید. همچنین باید فشرده‌سازی مش، تنظیمات Read/Write، نرمال‌ها، تانژانت‌ها، هموارسازی (Smoothing)، UVها و برخوردکننده‌های تولید شده (Generated Colliders) را در صورت لزوم بازرسی کنید.

برای شخصیت‌ها یا اشیای متحرک، تب Rig نیازمند انتخاب بین تنظیمات Humanoid یا Generic است. اگر دارایی شامل کلیپ‌های انیمیشن است، تب Animation باید برای بررسی نام کلیپ‌ها، تنظیمات حلقه (Loop)، رفتار Root Motion و محدوده فریم‌های خاص بررسی شود.

در نهایت، تب Materials جایی است که اکثر دارایی‌های هوش مصنوعی شکست می‌خورند. شما باید ایجاد متریال، استفاده از متریال‌های جاسازی شده (Embedded)، شناسایی بافت‌ها، نقشه‌های نرمال، رفتار Metallic یا Smoothness و تخصیص شیدر را بررسی کنید تا مطمئن شوید رفتار PBR با تولید اولیه هوش مصنوعی مطابقت دارد.

برای تکمیل تست، مدل را به یک صحنه ساده بکشید (Drag). سلسله‌مراتب Prefab، محور، مقیاس، ظاهر متریال، سایه‌ها، برخورد و رفتار در زمان اجرا را بازرسی کنید. پیش از شروع پاک‌سازی، هرگونه هشدار وارد کردن، بافت‌های گم‌شده، متریال‌های صورتی، نرمال‌های وارونه، خطاهای مقیاس و مشکلات عملکردی را ثبت کنید.

گردش‌کار وارد کردن در Godot

موتور Godot با دارایی‌های سه‌بعدی متفاوت برخورد می‌کند و آن‌ها را به عنوان «صحنه» (Scene) با یک واردکننده سه‌بعدی قابل تنظیم می‌بیند. این موتور به‌شدت فرمت‌های glTF 2.0 یا GLB باینری را برای صحنه‌های سه‌بعدی توصیه می‌کند.

در حالی که OBJ در دسترس است، اما محدود است. OBJ نمی‌تواند به‌طور قابل‌اعتمادی محورها، اسکلت‌ها، انیمیشن‌ها، نقشه‌های UV2 یا متریال‌های PBR را مدیریت کند. برای هر دارایی که نیاز به حرکت یا متریال‌های پیچیده دارد، GLB یا glTF تست اول ایمن‌تری برای دارایی‌های سبک صحنه است.

پس از کپی فایل صحنه و بافت‌ها در پروژه Godot، باید درخت صحنه وارد شده، تبدیل‌ها (Transform)، واحدها، رفتار محور، سطوح مش، متریال‌ها، بافت‌ها و هرگونه AnimationPlayer موجود را بازرسی کنید. دارایی را در یک صحنه تست ساده با یک دوربین و نور باز کنید تا سایه‌زنی، نرمال‌ها، رفتار Alpha و ترجمه متریال PBR را تأیید کنید.

یک گام حیاتی در Godot، تخصیص آگاهانه برخورد (Collision) است. هرگز نباید فرض کنید مش بصری یک شکل برخورد بهینه است؛ شما باید برخورد را به‌طور آگاهانه ایجاد یا تخصیص دهید تا از لگ در زمان اجرا جلوگیری شود. اگر دارایی متحرک است، پخش انیمیشن، رفتار اسکلت، مفروضات Retargeting و Root Motion را بررسی کنید.

صحنه را اجرا کرده و تأثیر زمان فریم (Frame-time)، مشکلات شیدر، هشدارهای بافت، نقشه‌های گم‌شده و نقص‌های تعاملی را ثبت کنید.

مقایسه تصمیمات Unity در برابر Godot

انتخاب مسیر به نیازهای خاص موتور بستگی دارد:

• فرمت: Unity معمولاً از FBX برای گردش‌کارهای مدل، ریگ و انیمیشن استفاده می‌کند، اگرچه GLB در برخی خط لوله‌ها استفاده می‌شود. Godot ترجیح می‌دهد از GLB یا glTF برای دارایی‌های سبک صحنه استفاده کند. ثبت کنید که کدام داده‌ها باقی مانده‌اند: مش، سلسله‌مراتب، متریال‌ها، بافت‌ها، انیمیشن، اسکلت و محورها.
• متریال‌ها: در Unity، تخصیص شیدر، جست‌وجوی بافت، نقشه‌های نرمال و قراردادهای Metallic/Smoothness را بررسی کنید. در Godot، ترجمه PBR از GLB/glTF، حالت Alpha، مسیرهای بافت و سازگاری شیدر را بررسی کنید. نقشه‌های گم‌شده، Roughness اشتباه یا عدم تطابق اسلات‌های متریال را ثبت کنید.
• مقیاس و محور: Unity نیاز به تأیید Scale Factor واردکننده، Convert Units و محور Prefab دارد. Godot نیاز به تأیید Transform صحنه، مبدأ، مقیاس و جایگذاری برخورد دارد. واحدهای مورد انتظار را در برابر اندازه واقعی وارد شده ثبت کنید.
• انیمیشن: Unity بر تب‌های Rig و Animation، تنظیمات حلقه و تنظیمات Humanoid/Generic متمرکز است. Godot بر AnimationPlayer، اسکلت، نام کلیپ‌ها و Retargeting متمرکز است. تعداد کلیپ‌ها، محدوده فریم و شکست‌های دفرمه شدن را ثبت کنید.
• زمان اجرا (Runtime): هر دو موتور نیاز به بررسی رفتار Prefab/Scene در حالت Play، شامل نورپردازی، سایه‌ها و تأثیر زمان فریم دارند. وظایف پاک‌سازی شناخته شده، مسئول، شدت مشکل و تصمیم نهایی «قبول یا رد» (Go/No-go) را ثبت کنید.

تست دود عملکرد (Performance Smoke Test)

موفقیت در وارد کردن، تنها اولین گیت است. یک تست دود عملکرد فاش می‌کند که آیا مش تولیدشده توسط هوش مصنوعی برای سخت‌افزار هدف بیش از حد سنگین است یا خیر. این کار جایگزین پروفایلینگ کامل نیست، اما به‌سرعت دارایی‌هایی را که برای صحنه مورد نظر بیش از حد سنگین هستند، شناسایی می‌کند.

این فرآیند شامل بررسی تعداد مثلث‌ها، تعداد رئوس (Vertex)، تعداد متریال‌ها، تعداد بافت‌ها و رزولوشن بافت‌ها است. شما باید به دنبال سطوح داخلی غیرضروری، تکرارهای پنهان، مش‌های کوچک و جدا شده و قطعات ادغام‌نشده باشید که ابزارهای تولیدکننده هوش مصنوعی اغلب ایجاد می‌کنند.

دارایی را در فاصله دوربین مورد انتظار و نورپردازی صحنه تست کنید. تعیین کنید که آیا به LODها (سطوح جزئیات)، برخورد ساده‌شده، فشرده‌سازی بافت، اطلس‌بندی (Atlas work) یا یکپارچه‌سازی متریال نیاز دارد یا خیر. برای اهداف موبایل یا وب، از بودجه سخت‌گیرانه‌تری استفاده کنید و در اولین فرصت روی یک دستگاه یا مرورگر نماینده تست کنید.

ثبت کنید که آیا دارایی برای استفاده در نمونه اولیه پذیرفته شده است، نیاز به بهینه‌سازی دارد، نیاز به تولید مجدد دارد یا باید به‌صورت دستی بازسازی شود.

نقش V2Fun در این زنجیره

پلتفرم V2Fun در این خط لوله به عنوان یک ابزار تولید فرانت-اند (Front-end) قرار می‌گیرد. این یک پلتفرم خلق سه‌بعدی با هوش مصنوعی است که به کاربران کمک می‌کند تا کاندیداهای دارایی سه‌بعدی را از روی تصویر یا متن تولید کنند، بافت‌های هوش مصنوعی را اعمال نمایند و گردش‌کارهای شخصیت‌محور را برای استفاده‌های پایین‌دستی آماده کنند. در این راستا، رقابت میان مدل‌های پیشرو مانند Claude Opus 5 و GPT-5.6 در تولید بازی‌های سه‌بعدی رویه‌ای می‌تواند کیفیت خروجی‌های اولیه در چنین پلتفرم‌هایی را به شدت تغییر دهد.

این موضوع باعث می‌شود V2Fun پیش از تست اول موتور بسیار مرتبط باشد، به‌ویژه زمانی که یک تیم کوچک نیاز دارد چندین کاندیدای بصری را به‌سرعت تولید کند. V2Fun برای تولید و آماده‌سازی کاندیداهای Prop، پیش‌نویس‌های شخصیت یا مدل‌های سبک محصول که قرار است در Unity یا Godot اعتبارسنجی شوند، بیشترین کاربرد را دارد.

با این حال، این راهنما تأکید می‌کند که V2Fun جایگزینی برای تست موتور یا تأیید نهایی آمادگی بازی نیست. این ابزار از بخش ابتدایی گردش‌کار پشتیبانی می‌کند: تولید دارایی، اکتشاف بافت، تکرار مدل و خروجی گرفتن. این موتور بازی است که تصمیم می‌گیرد آیا مقیاس، متریال‌ها، برخورد، انیمیشن، تعامل و هزینه زمان اجرا قابل قبول هستند یا خیر.

اگر پروژه‌ای به توپولوژی سخت‌گیرانه، LODهای سفارشی، شیدرهای بهینه، برخورد دست‌ساز، سیستم‌های انیمیشن پیچیده، بودجه‌های عملکردی خاص پلتفرم یا تحویل تجاری نهایی نیاز دارد، دارایی باید از V2Fun به یک خط لوله تخصصی مانند Blender، Unity یا Godot برای پاک‌سازی دستی منتقل شود.

ماتریس مسئولیت شکست

وقتی تستی شکست می‌خورد، گردش‌کار برای تضمین پاسخگویی، اصلاح را به یک نقش خاص می‌سپارد:

• مقیاس یا محور اشتباه: هنرمند فنی. علت احتمالی: واحدها، مبدأ، تبدیل خروجی یا تنظیمات واردکننده. اقدام: اصلاح در DCC یا تنظیمات واردکننده و سپس وارد کردن مجدد.
• متریال‌های صورتی یا گم‌شده: هنرمند متریال یا یکپارچه‌ساز موتور. علت احتمالی: عدم تطابق شیدر، بافت‌های گم‌شده یا نقشه‌های پشتیبانی‌نشده. اقدام: اتصال مجدد بافت‌ها یا تخصیص شیدر موتور.
• نرمال‌های شکسته یا درزهای سایه‌زنی: هنرمند سه‌بعدی یا هنرمند فنی. علت احتمالی: نرمال‌های مش تولیدشده ناسازگار، تانژانت‌ها یا درزهای UV. اقدام: محاسبه مجدد نرمال‌ها یا تعمیر مش.
• عدم اجرای انیمیشن: ریگر یا انیماتور. علت احتمالی: نوع ریگ، اسکلت، خروجی کلیپ یا عدم تطابق سلسله‌مراتب. اقدام: اصلاح تنظیمات ریگ یا خروجی مجدد کلیپ‌ها.
• برخورد (Collision) بد: توسعه‌دهنده موتور. علت احتمالی: استفاده از مش بصری به عنوان برخورد یا شکل‌های مقعر/پیچیده. اقدام: ایجاد برخورد ساده‌شده.
• هزینه پردازشی بالا: هنرمند فنی. علت احتمالی: تعداد چندضلعی‌ها، اندازه بافت یا نبود LODها. اقدام: بهینه‌سازی مش یا فشرده‌سازی بافت‌ها.
• عدم قطعیت در حقوق یا تحویل: تهیه‌کننده یا مدیر پروژه. علت احتمالی: مراجع ورودی مستند نشده یا محتوای شخص ثالث. اقدام: بررسی حقوق منبع و شرایط پلتفرم.

این رویکرد ساختاریافته، تولید هوش مصنوعی را از یک «لاتاری» به یک فرآیند مهندسی پیش‌بینی‌پذیر تبدیل می‌کند. با تبدیل اولین وارد کردن به موتور به یک گیت باینری «قبول/رد»، استودیوها می‌توانند تولید دارایی‌های خود را بدون افزایش بدهی فنی مقیاس کنند.

برای پیاده‌سازی این روش، با ایجاد یک «صحنه اعتبارسنجی» (Validation Scene) در پروژه خود شروع کنید. از این صحنه برای بنچ‌مارک کردن هر دارایی هوش مصنوعی پیش از اجازه ورود به دنیای اصلی بازی استفاده کنید. این مراحل را دنبال کنید: تعریف نقش دارایی، انتخاب فرمت بر اساس داده‌های مورد نیاز، اجرای بازرسی پیش از خروجی، وارد کردن در یک پروژه تست تمیز، تأیید تبدیل‌ها و متریال‌ها، تست برخورد و انیمیشن و در نهایت اجرای تست دود عملکرد برای تعیین مسئولین پاک‌سازی.

اما داستان بهینه‌سازی این مدل‌ها در سطح سخت‌افزار حتی پیچیده‌تر است — به تحلیل ما درباره‌ی مدیریت حافظه VRAM در موتورهای بازی مراجعه کنید.