مدل‌سازی سه‌بعدی و هوش مصنوعی — دامنه‌ی آینده · فصل ۱ — Blender، UV/PBR، Reconstruction و Optimization · 337
3D Foundations و Blender Production Modeling
با ابزار یا اصطلاحات 3D آشناست اما pipeline production، quality و interoperability را end-to-end کنترل نمی‌کند. موضوع جاری: «3D Foundations و Blender Production Modeling». می‌تواند «3D Foundations و Blender Production Modeling» را در یک asset pipeline محدود اجرا و quality/interoperability evidence لازم را ثبت کند.
خلاصهٔ درس
با ابزار یا اصطلاحات 3D آشناست اما pipeline production، quality و interoperability را end-to-end کنترل نمی‌کند. موضوع جاری: «3D Foundations و Blender Production Modeling».
می‌تواند «3D Foundations و Blender Production Modeling» را در یک asset pipeline محدود اجرا و quality/interoperability evidence لازم را ثبت کند.
خروجی این درس
می‌تواند «3D Foundations و Blender Production Modeling» را در یک asset pipeline محدود اجرا و quality/interoperability evidence لازم را ثبت کند.
مدلی که خوب به نظر می‌رسد، هنوز ممکن است دارایی تولیدی مناسبی نباشد
فرض کنید یک تیم کوچک محصول، یک مدل سخت‌سطح ساخته‌شده در Blender را تحویل می‌گیرد. سیلوئت خوب است، لبه‌های Bevel تمیز دیده می‌شوند و در viewport ایراد آشکاری به چشم نمی‌آید. با این حال، نفر بعدی که فایل را باز می‌کند نمی‌تواند با اطمینان به چند سؤال ساده پاسخ دهد: سیستم واحد صحنه چیست؟ مقیاس فیزیکی موردنظر چه بوده است؟ آیا یکی از اشیای فرزند هنوز non-uniform scale دارد؟ وضعیت Normal در بخش‌های آینه‌ای واقعاً سازگارند؟ کدام Modifier هنوز قابل ویرایش است و کدام مرحله‌ها مخرب شده‌اند؟ تعداد triangle برای هدف اعلام‌شده مناسب است؟ فایل از چه قرارداد نام‌گذاری پیروی می‌کند؟
فاصله میان «ظاهر تمام‌شده» و «دارایی‌ای که بتوان آن را قابل پیش‌بینی تحویل گرفت» مسئله اصلی این درس است. خروجی شما فقط یک mesh نیست؛ یک artifact قابل‌ممیزی با نام Production Mesh Modeling and Topology Evidence Pack v1 است. این بسته کاربرد هدف، سیستم واحد، مقیاس مرجع، وضعیت transform، هدف topology، آمار هندسه، وضعیت Normal، الزام Manifold، وضعیت Modifier و تاریخچه مراحل مخرب، نام‌گذاری، وضعیت origin/pivot، محدودیت‌های شناخته‌شده و شواهد سازگاری بین‌ابزاری را کنار هم نگه می‌دارد تا بازبین دیگری بتواند دلیل یک تصمیم محدود را بازسازی کند.
Blender 5.2 یکی از نسخه‌های فعال LTS در برنامه فعلی Blender است. مستندات Blender 5.2 همچنین ویرایش mesh در Edit Mode و ساخت هندسه چندضلعی با vertex، edge و face را توضیح می‌دهند. این‌ها واقعیت‌های مربوط به ابزارند و به‌تنهایی «topology مناسب» برای هدف شما را تعریف نمی‌کنند. glTF 2.0.1 نیز transform گره‌ها، mesh، اجزای primitive و vertex attribute را صریح نمایش می‌دهد؛ بنابراین فرض‌های transform و هندسه در شواهد تبادل داده اهمیت دارند. با این حال، glTF معیار پذیرش مدل‌سازی در MAKNOW را تعیین نمی‌کند. [BLENDERLTS] [BLENDERMODEL] [BLENDERMESH] [GLTFSPEC]
خروجی عملی این درس Production Mesh Modeling and Topology Evidence Pack v1 است و باید به یکی از وضعیت‌های محدود READY، TARGET_SPECIFIC، REWORK_REQUIRED، HOLD، EVIDENCE_INCOMPLETE، PROVENANCE_UNKNOWN یا METHOD_UNSUITABLE ختم شود.
زمان فعال برنامه‌ریزی‌شده: ۶۰ دقیقه.
مرز درس: D3D-001 مبانی سه‌بعدی و قرارداد مدل‌سازی تولیدی را پوشش می‌دهد. این درس UV/PBR و AI-assisted texturing مربوط به D3D-002، بازسازی سه‌بعدی مربوط به D3D-003 یا خروجی‌های بسته‌بندی و تحویل در درس‌های بعدی را جذب نمی‌کند. یک beauty render، export موفق یا صرفاً بازشدن فایل در ابزار دیگر، به‌تنهایی شواهد آمادگی تولید نیست.
پیش‌نیاز HARD — FND-003
پیش از ادامه باید بتوانید مرز مرتبطی را که از FND-003 می‌آید توضیح دهید. اگر این شواهد هنوز ضعیف است، فقط یک پل محدود برای آن بسازید؛ تکمیل پیش‌نیاز را فرض نکنید و خروجی یادگیری آن را دوباره داخل این درس تدریس نکنید.
پیش‌نیاز SOFT — AIE-011
اگر AIE-011 هنوز برای شما تثبیت نشده است، فقط شواهد لازم برای پشتیبانی کنترل‌شده از تصمیم و استفاده مسئولانه از AI را بازسازی کنید. در این درس AI می‌تواند شواهد مصنوعی داده‌شده را سازمان دهد یا بررسی‌های قطعی را اجرا کند؛ اما اجازه ندارد کیفیت، provenance، سازگاری مقصد، حقوق استفاده یا تأیید نهایی را اختراع کند.
مسیر خود را از روی شواهد انتخاب کنید، نه از روی سرعت کار در Blender
پیش از باز کردن آموزش، به چهار سؤال پاسخ دهید:
- اگر مدل در viewport درست دیده شود، آیا این موضوع ثابت می‌کند واحد، مقیاس و transform آن برای تحویل صحیح است؟
- اگر یک مدل سخت‌سطح بیشتر از انتظار triangle داشته باشد، آیا بدون دانستن هدف و بودجه می‌توان آن را «بیش از حد سنگین» دانست؟
- اگر هندسه آینه‌ای ظاهراً سالم باشد ولی وضعیت Normal و تاریخچه مراحل مخرب ثبت نشده باشد، آیا وضعیت مثبت قابل دفاع است؟
- اگر دارایی دوم یک شیء ارگانیک برای رندر آفلاین باشد، آیا باید همان قواعد topology، Manifold و بودجه هندسه دارایی اول را بدون تغییر کپی کند؟
۴ از ۴ → مسیر سریع. ۲ تا ۳ → مسیر اصلاح. ۰ تا ۱ → مسیر پایه.
در مسیر سریع تعریف‌های مقدماتی فشرده می‌شوند، اما معیار شواهد کامل باقی می‌ماند. در مسیر اصلاح، نخستین بُعد شواهدی خراب را جدا می‌کنید و کوچک‌ترین mutation مرتبط را دوباره اجرا می‌کنید. در مسیر پایه، نقشه کامل فیلدها و یک نمونه هدایت‌شده حفظ می‌شود. هیچ مسیری اجازه ندارد نتیجه‌ای قوی‌تر از شواهد موجود صادر کند.
خودسنجی مسیر: Q1 ظاهر را از قرارداد transform جدا می‌کند؛ Q2 نشان می‌دهد بودجه هندسه به هدف وابسته است؛ Q3 وضعیت نامعلوم تاریخچه/Normal را حفظ می‌کند؛ و Q4 انتقال را بر اساس شواهد جدید دوباره محاسبه می‌کند، نه با کپی نتیجه حالت مبنا.
مدل ذهنی: هدف → مقیاس/transform → topology/تاریخچه → اعتبارسنجی → نتیجه
ترتیب تصمیم را ثابت نگه دارید:
target use + reference scale → blockout → topology/transform decisions → modifier/destructive history → normals/naming/origin validation → geometry/interoperability evidence → READY / REWORK / HOLD
سه نوع مرجع را با هم یکی نکنید:
| لایه | چه چیزی را مشخص می‌کند؟ | چه چیزی را به‌تنهایی ثابت نمی‌کند؟ |
|---|---|---|
| واقعیت ابزار | Blender در Edit Mode ویرایش mesh با vertex، edge و face را پشتیبانی می‌کند | مناسب‌بودن topology، بودجه هندسه یا قرارداد نام‌گذاری شما |
| واقعیت قالب | glTF transform، mesh، primitive و attribute را صریح نمایش می‌دهد | این‌که هر دارایی باید glTF باشد یا دارایی شما آماده تولید است |
| طراحی MAKNOW | چه شواهد قابل‌مشاهده‌ای برای یک تصمیم محدود لازم است | مالکیت حقوقی، تأیید سازمانی یا کیفیتی که برای آن شواهدی وجود ندارد |
این تفکیک نگاه شما به عملیات رایج را تغییر می‌دهد. «Apply Transform» هدف نیست. «Export» هم هدف نیست. هدف این است که بدانید کدام فرض‌ها برای مصرف‌کننده مهم‌اند، کدام رابطه‌های ساخت ممکن است عمداً حفظ شوند و چه شواهدی به بازبین اجازه می‌دهد تصمیم شما را بازسازی کند.
جدول این درس فیلدهای تعیین‌کننده را در یک نمونه کنار هم قرار می‌دهد. نمودار جریان نیز ترتیب دروازه‌ها و شاخه‌های غیرموفق را نشان می‌دهد. اگر نمایش بصری در دسترس نباشد، نسخه متنی جدول و جریان برای انجام کار کافی است.
پایه‌های مشترک مدل‌سازی تولیدی
1. قابلیت Blender با معیار تولید یکی نیست
Blender 5.2 LTS روندهای مدل‌سازی، Edit Mode و مجموعه بزرگی از عملیات mesh را در اختیار شما می‌گذارد. mesh چندضلعی از vertex، edge و face ساخته می‌شوند و بسیاری از تغییرهای فرم در Edit Mode انجام می‌شوند. [BLENDERMODEL] [BLENDERMESH]
این قابلیت یک واقعیت فنی است، نه معیار کیفیت. quad، triangle یا ngon به‌تنهایی نتیجه تولید نمی‌سازد. هدف topology باید با کاربرد هدف، deformation، subdivision، shading، امکان ویرایش، export و محدودیت‌های بعدی مرتبط شود. یک ناحیه تخت و بدون deformation ممکن است قاعده‌ای را بپذیرد که برای سطحی تغییرشکل‌پذیر مناسب نیست. این درس شعارهایی مثل «همیشه quad» یا «ngon همیشه بد است» را جایگزین شواهد نمی‌کند.
2. سیستم واحد و مقیاس مرجع پیش از جزئیات می‌آیند
وقتی دارایی بین ابزارها یا افراد جابه‌جا می‌شود، سیستم واحد و مقیاس مرجع باید صریح باشند. یک mesh می‌تواند از نظر ظاهری درست باشد اما صد برابر بزرگ‌تر یا کوچک‌تر از قرارداد پروژه ساخته شده باشد. مقیاس می‌تواند روی Modifier، فیزیک، دوربین، export، جانمایی، دقت محاسبات و خودکارسازی مقصد اثر بگذارد.
به همین دلیل، بسته شواهد واحد و یک مشاهده قابل‌اندازه‌گیری برای مقیاس مرجع را ثبت می‌کند؛ مثلاً ابعاد bounding box یا یک اندازه مرجع مصنوعی. عبارت «تقریباً اندازه‌اش درست است» برای وضعیت مثبت کافی نیست.
3. وضعیت transform شیء باید قابل توضیح باشد
در glTF، یک node می‌تواند transform محلی خود را با matrix یا داده‌های translation/rotation/scale نمایش دهد؛ بنابراین transform بخشی از معنای قابل‌انتقال صحنه است. [GLTFSPEC] این موضوع به معنی «همیشه همه transform را Apply کن» نیست. بعضی رابطه‌های ساخت عمداً transform را حفظ می‌کنند. قرارداد شما باید بگوید چه چیزی باقی مانده، چرا باقی مانده و هدف چه انتظاری دارد.
یکی از تغییرهای آزمایشی Lab، non-uniform scale اعمال‌نشده را روی یک شیء فرزند ایجاد می‌کند. اگر یادگیرنده بدون سازگارکردن این وضعیت با هدف اعلام‌شده همچنان وضعیت مثبت بدهد، قرارداد شواهد شکسته است.
4. هدف topology را هدف دارایی تعیین می‌کند
کاربرد را نام‌گذاری کنید: سخت‌سطح بلادرنگ، ارگانیک تغییرشکل‌پذیر، سطح subdivision، رندر آفلاین ایستا، collision proxy یا هدف محدود دیگری. تعداد vertex و triangle فقط زمانی شواهد تصمیم‌اند که به بودجه یا انتظار هزینه نام‌دار وصل باشند. این درس هیچ آستانه جهانی برای triangle تعریف نمی‌کند.
5. وضعیت Normal یک شاهد هندسی مستقل است
Mirror، negative scale، تاریخچه transform و بعضی عملیات ویرایش می‌توانند جهت Normal یا فرض‌های shading را مبهم کنند. یک beauty render ممکن است مشکل را از زاویه‌ای مناسب پنهان کند. بنابراین وضعیت Normal باید جداگانه اعتبارسنجی و ثبت شود. وضعیت نامعلوم یا ناسازگار نباید صرفاً چون viewport «خوب به نظر می‌رسد» به موفقیت ارتقا پیدا کند.
6. Modifier stack و تاریخچه مخرب، تصمیم‌های مربوط به بازبینی‌پذیری‌اند
Modifier زنده می‌تواند هدف قابل‌ویرایش را حفظ کنند؛ Apply کردن Modifier می‌تواند آن هدف را به هندسه نهایی تبدیل کند. هیچ‌کدام ذاتاً درست یا غلط نیست. الزام این درس آن است که وضعیت مهم Modifier، ترتیب آن‌ها و مرحله‌های مخرب تعیین‌کننده قابل مشاهده باشد تا نفر بعدی بداند چه چیزی هنوز قابل تغییر است و چه چیزی تثبیت شده است.
7. نام‌گذاری و origin/pivot بخشی از تحویل‌اند
نام‌های موقتی مانند Cube.017 ممکن است در یک صحنه شخصی قابل تحمل باشند، اما انتخاب، نگاشت export، خودکارسازی و ارتباط تیمی را شکننده می‌کنند. برای اشیای تعیین‌کننده باید یک قرارداد نام‌گذاری کوچک اما واقعی وجود داشته باشد. وضعیت origin/pivot نیز باید با کاربرد هماهنگ باشد و در شواهد دیده شود، نه این‌که پشت یک تصویر صفحه تمیز پنهان بماند.
8. material_slot_count یک داده موجودی است، نه اثبات کیفیت متریال
تعداد Material slot می‌تواند برای بازبین نشان دهد ساختار mesh چه تعداد اتصال متریال دارد و هنگام handoff چه موجودی‌ای باید بررسی شود. این فیلد در این درس یک knowledge item غیرحیاتی است: آن را ثبت و با نمونه آزمایشی تطبیق دهید، اما از عدد آن درباره کیفیت PBR، درستی shader یا بافت نتیجه‌گیری نکنید. آن موضوعات در محدوده D3D-002 قرار دارند.
ساخت Production Mesh Modeling and Topology Evidence Pack v1
گام 1 — کاربرد هدف را پیش از صدور نتیجه مدل‌سازی اعلام کنید
بنویسید دارایی برای چه کاری است: پیش‌نمایش بلادرنگ دسکتاپ، اجرای موبایل، رندر آفلاین، deformation، ساخت subdivision یا هدف محدود دیگری. سپس target_constraint_scope را ثبت کنید. فقط زمانی STANDARD_DECLARED_TARGET را به‌کار ببرید که شواهد، هدف استاندارد اعلام‌شده را بدون استثنای ویژه پشتیبانی کنند. اگر آمادگی فقط برای یک هدف یا محدودیت نام‌دار معتبر است، CONSTRAINED_NAMED_TARGET_ONLY را ثبت کنید.
هدف یک برچسب تزئینی نیست؛ مشخص می‌کند کدام فرض‌های هندسه، transform، Manifold، تاریخچه و سازگاری بین‌ابزاری اهمیت دارند.
گام 2 — هویت، واحدها و مقیاس مرجع را به شواهد متصل کنید
asset_id، fixture_ref، unit_system و reference_scale را ثبت کنید. مقیاس مرجع باید قابل بررسی باشد. اندازه یک شیء، ابعاد bounding box یا یک اندازه‌گیری مصنوعی از حدس بصری قوی‌تر است.
اگر هویت یا مقیاس به شواهد قابل‌مشاهده متصل نمی‌شود، به‌جای حدس‌زدن قرارداد مفقود، EVIDENCE_INCOMPLETE را حفظ کنید.
گام 3 — وضعیت transform اشیای تعیین‌کننده را ثبت کنید
transform را با واژه «تمیز» خلاصه نکنید. وضعیت معنادار هر شیء را ثبت کنید: scale اعمال‌شده/اعمال‌نشده، non-uniform scale، rotation حفظ‌شده، negative scale، رابطه hierarchy یا هر واقعیت دیگری که برای هدف اهمیت دارد. برای یک تصمیم مثبت، وضعیت باقی‌مانده transform باید با هدف اعلام‌شده و فرض‌های مصرف‌کننده سازگار باشد.
تمایز اصلی «Apply شده یا نشده» به‌تنهایی نیست؛ مسئله این است که وضعیت «شناخته‌شده و سازگار با هدف» است یا «مبهم و متناقض».
گام 4 — هدف topology را بنویسید، نه یک باور کلی درباره topology
topology_intent و سیاستی را که از آن نتیجه می‌شود ثبت کنید. یک prop سخت‌سطح برای اجرای بلادرنگ ممکن است سیلوئت، shading پایدار، triangulation قابل پیش‌بینی، تراکم کنترل‌شده و handoff ساده را در اولویت بگذارد. یک mesh ارگانیک تغییرشکل‌پذیر ممکن است به جریان edge و رفتار deformation اهمیت بیشتری بدهد. روند subdivision نیز ممکن است به پیوستگی‌ای نیاز داشته باشد که برای یک شیء ایستای آفلاین ضروری نیست.
اگر سیاستی برای ngon دارید، محدوده مجاز آن و روش اعتبارسنجی را توضیح دهید. برچسبی مثل QUAD_FOCUSED بدون بیان هدف کافی نیست.
گام 5 — آمار هندسه را کنار بودجه هدف قرار دهید
vertex_count و triangle_count را همراه geometry_budget_policy ثبت کنید. اگر هدف حداکثر مشخصی دارد، شمارش مشاهده‌شده را با همان مقدار مقایسه کنید. اگر بودجه معناداری وجود ندارد، نبود آن را صریح ثبت کنید و عددی اختراع نکنید.
تعداد یک شاهد است؛ «زیاد» یا «کم» بودن یک تصمیم است و به زمینه نیاز دارد.
گام 6 — Normal و الزام Manifold را جداگانه اعتبارسنجی کنید
normal_state، manifold_requirement و در صورت تعیین‌کننده‌بودن، نتیجه مشاهده‌شده Manifold را ثبت کنید. یک هدف ممکن است هندسه بسته و Manifold بخواهد و هدف دیگری عمداً سطح باز داشته باشد. همین‌طور وضعیت Normal می‌تواند سازگار باشند در حالی که نقص دیگری در topology وجود دارد، یا ناسازگار باشند در حالی که یک زاویه رندر قابل قبول به نظر برسد.
این دروازه‌ها را مستقل نگه دارید تا موفقیت بصری یکی، شکست دیگری را پاک نکند.
گام 7 — هدف Modifier و تاریخچه مراحل مخرب را حفظ کنید
Modifier stack را با ترتیب معنادار ثبت کنید و برای اعمال یا تغییرهای برگشت‌ناپذیری که در handoff مهم‌اند، destructive_step_log بسازید. این log قرار نیست فهرست همه کلیک‌ها باشد؛ فقط تصمیم‌هایی را ثبت می‌کند که در غیر این صورت هنرمند یا ابزار بعدی مجبور می‌شود حدس بزند.
اگر یک مرحله مخرب توان ویرایشی مهمی را برای هدف از بین برده است، تا زمانی که قرارداد بازسازی نشده، از REWORK_REQUIRED یا وضعیت غیرموفق مناسب دیگری استفاده کنید.
گام 8 — نام‌گذاری، origin/pivot و تعداد Material slot را ثبت کنید
naming_contract را به اشیای تعیین‌کننده متصل کنید و origin_pivot_state را ثبت کنید. بررسی‌گر می‌تواند وجود نام‌های لازم را بررسی کند، اما مرجع سازمانی نام‌گذاری را برای شما تعیین نمی‌کند؛ بنابراین بسته شواهد قرارداد قابل‌مشاهده را از تأیید اختراعی جدا نگه می‌دارد.
در کنار آن، material_slot_count را به‌عنوان داده موجودی غیرحیاتی ثبت کنید. این عدد می‌تواند ساختار handoff را روشن کند، اما معیار کیفیت متریال یا PBR نیست و نبود آن نباید به‌تنهایی یک وضعیت مثبت را به وضعیت منفی تبدیل کند.
اگر قرارداد نام‌گذاری پیش از تحویل به هنرمند دوم حذف شود، فقط به این دلیل که mesh تغییر نکرده است وضعیت مثبت را حفظ نکنید.
گام 9 — provenance و محدودیت‌های شناخته‌شده را بدون اختراع ثبت کنید
فقط از شواهد مصنوعی، خودساخته، public-domain یا rights-cleared استفاده کنید. source_asset_ref، rights_provenance_ref و وضعیت تایپ‌شده provenance/حقوق را ثبت کنید. اگر provenance معلوم نیست، PROVENANCE_UNKNOWN را حفظ کنید. AI نباید یک داستان باورپذیر درباره منشأ دارایی بسازد.
محدودیت‌های شناخته‌شده نیز بخشی از قرارداد دارایی‌اند. یک محدودیت می‌تواند در وضعیت مثبت TARGET_SPECIFIC باقی بماند، به شرط آن‌که واقعاً محدود و قابل مشاهده باشد. محدودیت پنهان قابل قبول نیست.
گام 10 — سازگاری بین‌ابزاری را یک دروازه وابسته به هدف در نظر بگیرید
export موفق فقط نشان می‌دهد عملیات export انجام شده است. این موضوع ثابت نمی‌کند مصرف‌کننده scale، transform، هندسه، Normal، pivot، Material یا نام‌گذاری را مطابق قرارداد دارایی تفسیر می‌کند. [GLTFSPEC]
هدف نام‌دار و فرض‌هایی را که واقعاً بررسی شده‌اند ثبت کنید. اگر شواهد فقط export است، همین محدودیت را صریح بنویسید و آن را به اثبات سازگاری بین‌ابزاری ارتقا ندهید.
گام 11 — یک تصمیم محدود و شرط‌های آینده مرتبط ثبت کنید
ضعیف‌ترین وضعیتی را انتخاب کنید که شواهد قابل‌مشاهده واقعاً توجیه می‌کنند:
READY— همه شواهد تعیین‌کننده برای هدف استاندارد اعلام‌شده حاضر و سازگارند.TARGET_SPECIFIC— وضعیت مثبت فقط برای یک هدف محدود و نام‌دار معتبر است و محدودیت آشکار می‌ماند.REWORK_REQUIRED— یک تناقض مشخص و قابل اصلاح در مدل‌سازی یا handoff شناخته شده است.HOLD— یک تصمیم حاکم یا وابستگی مانع نتیجه‌گیری امن است.EVIDENCE_INCOMPLETE— شواهد تعیین‌کننده ناقص است.PROVENANCE_UNKNOWN— provenance یا شواهد حقوقی موردنیاز حل نشده است.METHOD_UNSUITABLE— روش مدل‌سازی یا handoff انتخاب‌شده نمی‌تواند قرارداد هدف را برآورده کند.
سپس دست‌کم یک شرط آینده مرتبط با یکی از نوع‌های review، migration، escalation، stop یا pivot ثبت کنید. همه پنج دسته را به‌صورت مکانیکی پر نکنید؛ stop یا pivot را فقط وقتی بنویسید که سناریوی واقعی به آن نیاز داشته باشد. وضعیت مثبت دائمی نیست و فقط تا زمانی معتبر است که فرض‌های حاکم تغییر نکرده باشند.
Lab عمداً وضعیت نهایی را خالی می‌گذارد. Lab شواهد قابل‌مشاهده و قواعد قطعی سازگاری را ارائه می‌دهد، نه answer key پنهان.
مثال کامل: یک prop سخت‌سطح مصنوعی، جدا از پاسخ Lab
HS-PROP-DEMO-01 را در نظر بگیرید؛ یک محفظه مکانیکی مصنوعی برای پیش‌نمایش بلادرنگ دسکتاپ نام‌دار. صحنه از متر استفاده می‌کند و اندازه مرجع ۰٫۴۵ متر است. همه اشیای تعیین‌کننده scale یکنواخت و سازگار دارند. هدف topology برابر HARD_SURFACE_REALTIME است؛ mesh حدود ۴۲۰۰ vertex و ۷۹۰۰ triangle دارد و سقف اعلام‌شده این نمونه ۱۲۰۰۰ triangle است. وضعیت Normal در بررسی صریح بخش آینه‌ای سازگارند. هدف به هندسه Manifold نیاز دارد و گزارش اعتبارسنجی می‌گوید این شرط پاس شده است. Mirror و Bevel در Modifier stack برای بازبینی زنده مانده‌اند و یک پاک‌سازی مخرب کوچک ثبت شده است. اشیای تعیین‌کننده از قرارداد نام‌گذاری پیروی می‌کنند، origin/pivot ثبت شده، تعداد Material slot نیز به‌عنوان داده موجودی ثبت شده و رکورد مصنوعی provenance وجود دارد.
این مثال فقط به این دلیل می‌تواند یک تصمیم مثبت محدود را پشتیبانی کند که شواهد با هم سازگارند. رندر زیبا عامل تصمیم نیست.
اکنون هر بار فقط یک فیلد را تغییر دهید:
| mutation | نخستین فرضی که می‌شکند | اقدام لازم |
|---|---|---|
| هدف به پیش‌نمایش بلادرنگ موبایل با سقف ۶۰۰۰ triangle تغییر می‌کند | بودجه هندسه | تصمیم را دوباره محاسبه کنید؛ وضعیت مثبت قبلی دیگر نتیجه نمی‌شود |
| یک شیء فرزند non-uniform scale اعمال‌نشده می‌گیرد | سازگاری transform | پیش از وضعیت مثبت، قرارداد transform را اعتبارسنجی/اصلاح کنید |
| بخش آینه‌ای Normal برعکس دارد | وضعیت Normal | تا اصلاح شواهد Normal، وضعیت غیرموفق را حفظ کنید |
| قرارداد نام‌گذاری پیش از تحویل به هنرمند دوم حذف می‌شود | هویت handoff | قاعده نام‌گذاری قابل‌مشاهده را بازگردانید یا محدودیت/وضعیت غیرموفق را حفظ کنید |
| فقط فایل exportشده به‌عنوان «شواهد interop» ارائه می‌شود | اتصال به فرض‌های مصرف‌کننده | بررسی‌های وابسته به هدف اضافه کنید؛ export موفق کافی نیست |
نکته مهم این است که برای هر mutation کل مدل از نو ساخته نمی‌شود. مسیر اصلاح، نخستین بُعد شکست‌خورده را جدا می‌کند و فقط دروازه‌های شواهدی متأثر از همان تغییر را دوباره اجرا می‌کند.
این مثال، مرجع پاسخ Lab نیست. Lab از شناسه‌های نمونه آزمایشی و مقادیر دیگری استفاده می‌کند و هیچ تصمیم نهایی از پیش پرشده‌ای ندارد.
خطاهایی که یک مدل ظاهراً تمیز را شکننده می‌کنند
1. «در viewport درست دیده می‌شود، پس برای تحویل آماده است.»
ظاهر به‌تنهایی درباره واحدها، transform، نام‌گذاری یا تاریخچه چیزی را قطعی ثابت نمی‌کند. اصلاح: بسته شواهد را فیلدبه‌فیلد کامل کنید.
2. «همیشه همه transform را Apply کن.»
این هم یک میان‌بُر است. بعضی رابطه‌های ساخت عمداً transform را حفظ می‌کنند. اصلاح: قرارداد هدف را اعلام کنید و وضعیت اعمال‌شده/اعمال‌نشده را نسبت به آن بسنجید. [GLTFSPEC]
3. «همیشه quad» یا «ngon همیشه بد است.»
کیفیت topology به رفتار هدف وابسته است. اصلاح: هدف topology، نیازهای deformation/subdivision، shading و رفتار مقصد را ثبت کنید.
4. «تعداد triangle خودش می‌گوید mesh سنگین است.»
بدون بودجه هدف، عدد معیار پذیرش نمی‌سازد. اصلاح: بودجه یا نبود آن را صریح کنید.
5. «Mirror کار کرده، پس وضعیت Normal هم درست است.»
Mirror، تاریخچه transform و shading می‌توانند مشکل Normal را پنهان کنند. اصلاح: وضعیت Normal را مستقل اعتبارسنجی کنید.
6. «Modifier را Apply کردم، پس فایل تمیزتر شد.»
هندسه نهایی ممکن است درست باشد اما قابلیت ویرایش یا دلیل تصمیم از بین رفته باشد. اصلاح: مرحله مخرب را ثبت کنید و محدودیت حاصل را آشکار نگه دارید.
7. «Cube.021 قابل فهم است؛ اسم مهم نیست.»
ابهام نام‌گذاری هزینه handoff و خودکارسازی را بالا می‌برد. اصلاح: یک قرارداد نام‌گذاری کوچک اما واقعی تعریف کنید.
8. «فایل export شد، پس interoperable است.»
export موفق، فرض‌های transform یا هندسه مصرف‌کننده را ثابت نمی‌کند. اصلاح: شواهد سازگاری بین‌ابزاری وابسته به هدف اضافه کنید. [GLTFSPEC]
9. «حالت مبنا پاس شد، پس انتقال هم همان قواعد را دارد.»
یک دارایی ارگانیک برای رندر آفلاین می‌تواند سیاست‌های متفاوتی برای topology، Manifold، Modifier و بودجه داشته باشد. اصلاح: نتیجه حالت مبنا را کنار بگذارید و تصمیم را از شواهد تغییرکرده دوباره بسازید.
برای یادگیرنده باتجربه: مدل‌سازی را یک قرارداد نسخه‌دار ببینید
اگر Blender را به‌خوبی می‌شناسید، ارزش این درس در یادگیری Extrude یا Bevel نیست. مسئله حرفه‌ای این است که هدف ساخت از وضعیت قابل‌تحویل جدا نشود.
یک الگوی فشرده:
asset_id، هدف و نسخه هندسه را با هم نسخه‌گذاری کنید؛- مقیاس مرجع و سیاست transform را پیش از پاک‌سازی نهایی قفل کنید؛
- Modifier stack زنده را به‌عنوان هدف قابل‌ویرایش ببینید و موارد Apply مهم را ثبت کنید؛
- آمار هندسه را فقط کنار بودجه هدف تفسیر کنید؛
- Normal، نام‌گذاری و origin را به‌عنوان شواهد مستقل handoff اعتبارسنجی کنید؛
- سازگاری بین‌ابزاری را با فرض‌های مصرف‌کننده بسنجید، نه با دکمه export؛
- هرگاه هدف، سیاست Modifier، مقیاس، بودجه هندسه یا فرض‌های مصرف‌کننده عوض شد، بسته شواهد را دوباره اجرا کنید.
این رویکرد اجازه می‌دهد صحنه ساخت انعطاف‌پذیر بماند و در عین حال ابهام‌های مهم هنگام handoff آشکار باشند. هدف افزایش تعداد قانون‌ها نیست؛ هدف کم‌کردن فرض‌های پنهان است.
موازنه‌ها بدون قانون جهانی topology
مدل‌سازی سخت‌سطح غیرمخرب در برابر مخرب: Modifier زنده می‌تواند قابلیت ویرایش و بازبینی را بهتر حفظ کنند، اما وابستگی و پیچیدگی stack را افزایش می‌دهند. مدل‌سازی مخرب ممکن است هندسه نهایی را ساده‌تر کند، اما امکان بازگشت به عقب و ثبت دلیل تصمیم را کاهش می‌دهد. برنده دائمی وجود ندارد؛ تاریخچه باید نسبت به هدف و نیازهای handoff سنجیده شود.
transform اعمال‌شده در برابر transform حفظ‌شده: Apply کردن transform می‌تواند فرض‌های مقصد را ساده کند. حفظ transform می‌تواند برای assembly، instancing یا رابطه‌های ساخت معنادار باشد. شرط مشترک این است که وضعیت و دلیل آن پنهان نماند.
topology متراکم در برابر topology سبک: هندسه بیشتر می‌تواند سیلوئت، جزئیات یا deformation را بهتر پشتیبانی کند، اما هزینه را بالا می‌برد. هندسه کمتر می‌تواند کارآمدتر باشد، اما ممکن است کیفیت یا قابلیت ویرایش را محدود کند. عدد فقط در کنار بودجه هدف معنا پیدا می‌کند.
تمرکز بر quad در برابر topology ترکیبی: چهارضلعی‌ها برای بسیاری از روندهای deformation و subdivision خوانا هستند؛ triangle و ngon نیز در زمینه‌های مشخص می‌توانند معتبر باشند. این درس فقط از روی برچسب topology نتیجه صادر نمی‌کند.
ساخت در Blender در برابر handoff با glTF: Blender محیط غنی ساخت است؛ glTF قالب تبادل/تحویل با معنای صریح برای transform و mesh است. [BLENDERMODEL] [GLTFSPEC] هنگام انتقال باید مشخص کنید کدام فرض‌های ساخت در نمایش مقصد باقی می‌مانند و کدام نیاز به سازگارکردن یا اعتبارسنجی دارند.
تمرین هدایت‌شده و مستقل
بخش A — حالت مبنا را بدون وضعیت نهایی از پیش پرشده بسازید
lab://D3D-001/D3D-001-LAB1 را باز کنید. فقط شواهد قابل‌مشاهده baseline_fixture.json را بخوانید و الگوی خالی evidence_pack.template.json را پر کنید. از هدف، واحد/مقیاس مرجع و سیاست هندسه شروع کنید؛ سپس transform، topology و Normal را ثبت کنید؛ و در پایان Modifier/تاریخچه، نام‌گذاری/origin، material_slot_count، provenance، محدودیت‌ها، شواهد سازگاری بین‌ابزاری و یک وضعیت محدود را اضافه کنید.
بررسی‌گر فقط قواعد قطعی قابل‌مشاهده را اجرا می‌کند و شواهد ارسال‌شده را به‌صورت قطعی به نمونهٔ آزمایشی ارسال‌شده‌ای که با fixture_ref اعلام کرده‌اید متصل می‌کند. پیام CONSISTENT یعنی فیلدهای ارائه‌شده با همان نمونه آزمایشی و قواعد منتشرشده سازگارند؛ این پیام تأیید انسانی، مجوز انتشار یا answer key پنهان نیست.
بخش B — چهار mutation را جداگانه تحلیل کنید
- هدف از رندر آفلاین به پیش‌نمایش بلادرنگ موبایل تغییر می‌کند و بودجه هندسه سخت‌تر می‌شود؛
- یک شیء فرزند non-uniform scale اعمال‌نشده می‌گیرد؛
- وضعیت Normal در بخش آینه‌ای ناسازگار می‌شود؛
- قرارداد نام‌گذاری پیش از handoff به هنرمند دوم حذف می‌شود.
برای هر mutation فقط نخستین فرض شکسته، پیامد و حداقل اصلاح را ثبت کنید. همه چیز را هم‌زمان بازطراحی نکنید.
بخش C — انتقال را از صفر دوباره محاسبه کنید
در فایل transfer_fixture.json دارایی دوم یک شیء ارگانیک برای رندر آفلاین است. هدف topology، الزام Manifold، راهبرد Modifier و سیاست بودجه هندسه آن عمداً با حالت مبنای سخت‌سطح متفاوت است. از الگوی انتقال استفاده کنید و وضعیت نهایی حالت مبنا را مرجع پاسخ ندانید.
موفقیت انتقال به این معنی نیست که هر دو دارایی باید READY شوند؛ یعنی بتوانید قاعده تصمیم را در زمینه تغییرکرده دوباره اجرا کنید و هرجا شواهد اقتضا می‌کنند، وضعیت‌های غیرموفق را حفظ کنید.
راستی‌آزمایی: بازبین باید آمادگی را از روی شواهد بازسازی کند
پیش از یک وضعیت مثبت، بازبین باید بتواند این زنجیره را دنبال کند:
- دارایی و هدف نام‌گذاری شده‌اند؛
- سیستم واحد و مقیاس مرجع صریح‌اند؛
- وضعیت transform اشیای تعیین‌کننده ثبت شده است؛
- هدف topology و آمار هندسه به هدف وصل شده‌اند؛
- وضعیت Normal و الزام Manifold جداگانه ارزیابی شده‌اند؛
- Modifier stack و تاریخچه مخرب قابل مشاهده‌اند؛
- قرارداد نام‌گذاری و شواهد origin/pivot وجود دارند؛
material_slot_countدر صورت ثبت، به‌عنوان داده موجودی قابل ردگیری است و با معیار کیفیت متریال اشتباه گرفته نمی‌شود؛- محدودیت‌های شناخته‌شده پنهان نشده‌اند؛
- provenance/حقوق موردنیاز اختراع نشده است؛
- شواهد سازگاری بین‌ابزاری از «export موفق شد» قوی‌تر است؛
- وضعیت نهایی و دست‌کم یک شرط آینده نام‌دار از شواهد موجود قوی‌تر نیستند؛ بسته به مورد از
review،migration،escalation،stopیاpivotاستفاده کنید.
اگر یکی از فیلدهای تعیین‌کننده مفقود است، از وضعیت غیرموفق تایپ‌شده استفاده کنید. EVIDENCE_INCOMPLETE شکست اخلاقی یا مهارتی نیست؛ نمایش درست عدم قطعیت است. خطا زمانی رخ می‌دهد که عدم قطعیت را برای رسیدن به نتیجه دلخواه پاک کنید.
بررسی‌گر Lab دارایی را تأیید نمی‌کند. شرط بازبینی انسانی این است که یک انسان بتواند بدون استدلال پنهان مدل، تصمیم محدود را از شواهد قابل‌مشاهده بازسازی کند.
ارزیابی و انتقال
ارزیابی نهایی چهار بخش مسدودکننده دارد:
- مرز متعلق به D3D-001 را توضیح دهید و یک موضوع مجاور خارج از محدوده را نام ببرید؛
- برای نمونه آزمایشی مصنوعی حالت مبنا،
Production Mesh Modeling and Topology Evidence Pack v1را بسازید؛ - تغییر آزمایشی مربوط به تبدیل هدف به پیش‌نمایش موبایل را تحلیل کنید، فیلد/وضعیت نامعتبر را مشخص کنید و حداقل اصلاح را بنویسید؛
- برای یک دارایی ارگانیک با هدف رندر آفلاین، الزامات topology، Manifold، Modifier و بودجه هندسه را از هدف جدید دوباره محاسبه کنید.
rubric پنج بُعد حیاتی دارد: identity_and_contract، exact_evidence_binding، negative_evidence، bounded_decision و transfer. اگر خروجی درس مجاور را جذب کنید، شواهد تعیین‌کننده را حدس بزنید، وضعیت منفی را پاک کنید یا نتیجه حالت مبنا را بدون محاسبه مجدد به انتقال کپی کنید، ارزیابی مسدودکننده رد می‌شود.
AI می‌تواند داده‌های نمونه آزمایشی را مرتب کند، شمارش‌ها را مقایسه کند یا فیلد مفقود را نشان دهد. تأیید نهایی کیفیت و سازگاری بین‌ابزاری باید همچنان از روی شواهد قابل‌مشاهده برای بازبین انسانی بازسازی‌پذیر باشد.
منابع، تازگی و مرز ادعاها
[D3D-001-K1 / FACT] Blender 5.2 یک نسخه فعال LTS است. مرجع: [BLENDERLTS]. این ادعا فقط درباره مبنای نگه‌داری نسخه است و سازگاری یک add-on، دارایی یا pipeline مشخص را ثابت نمی‌کند.
[D3D-001-K2 / FACT] Blender 5.2 مدل‌سازی mesh و روندهای Edit Mode برای vertex، edge و face را مستند می‌کند. مراجع: [BLENDERMODEL] [BLENDERMESH]. این ادعا درباره قابلیت و معنای ابزار است، نه کیفیت topology برای یک هدف خاص.
[D3D-001-K3 / FACT] glTF 2.0.1 transform گره‌ها، mesh، اجزای primitive و vertex attribute را صریح تعریف می‌کند. مرجع: [GLTFSPEC]. این معناها باعث می‌شوند فرض‌های transform و هندسه در شواهد تبادل داده قابل بررسی باشند، اما استفاده از glTF را برای همه دارایی‌های تولیدی الزامی نمی‌کنند.
[D3D-001-K4 / طراحی] فیلدهای شواهد، واژگان وضعیت، دروازه‌های پذیرش و قاعده بازبینی انسانی در این درس مرجع طراحی MAKNOW هستند. مستندات بیرونی این موارد را تعیین نمی‌کنند.
منابع رسمی در 2026-09-06 دوباره بررسی شدند و هویت یا مرز هیچ ادعایی تغییر نکرد. ادعاهای وابسته به Blender برای 2026-10-18 بازبینی مجدد زمان‌بندی شده‌اند. برای specification مربوط به glTF 2.0.1 بازبینی دوره‌ای اجباری تعریف نشده است؛ با این حال هر تغییر مادی در معنای مورد استناد Blender 5.2 LTS یا glTF باید باعث بازبینی زودتر شود.
شناسه و locator منابع مورد استفاده در derived_text/references/sources.json ثبت شده‌اند تا ادعاهای فنی به منابع رسمی آن‌ها قابل ردگیری باشند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ملاک‌های ارزیابی (rubric)
All five dimensions are critical. A blocking failure cannot be compensated by presentation quality.
| Dimension | Sufficient evidence | Blocking failure |
|---|---|---|
identity_and_contract | Owned V14/C01 lesson boundary is explicit and adjacent outcomes remain out of scope. | Adjacent lesson outcome absorbed or owned boundary unclear. |
exact_evidence_binding | Decisive FACT/INFERENCE/DESIGN claims trace to the correct authority class and source boundary. | External tool/format fact is used as MAKNOW approval or decisive evidence is invented. |
negative_evidence | At least one negative case is handled and typed HOLD/UNKNOWN/PARTIAL/DISPUTED states remain visible. | Known contradiction/unknown state is erased to produce success. |
bounded_decision | Decision is no stronger than evidence and names at least one applicable future trigger as review, migration, escalation, stop, or pivot; all five categories are not mechanically required. | State exceeds visible target/evidence or triggers are absent. |
transfer | Changed-context decision is rebuilt from new evidence rather than copied. | Baseline result is copied after target/context changes. |
AI support may organize supplied evidence and run deterministic checks. It may not invent asset budget, rights/provenance, interoperability success, quality/performance evidence, owner authority, or production approval.
Human review condition: A human reviewer must be able to reproduce the bounded decision from the visible evidence package without hidden model reasoning.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
از شواهد مصنوعی و قابل‌مشاهده، Production Mesh Modeling and Topology Evidence Pack v1 را بسازید. فایل آغازین هیچ وضعیت نهایی ازپیش‌پرشده‌ای ندارد.
fixture_ref را برابر یکی از شناسه‌های قابل‌مشاهده در CHECK_RULES.json قرار دهید و evidence_ref را به صورت fixture://<fixture_ref> بنویسید. برای تغییرهای آزمایشی، شناسهٔ همان mutation را استفاده کنید؛ بررسی‌گر آن تغییر را به‌طور قطعی روی fixture مبنا اعمال می‌کند و سپس شواهد ارائه‌شده را مقایسه می‌کند. بررسی‌گر هرگز وضعیت نهایی را برای شما انتخاب نمی‌کند.
ابتدا baseline_fixture.json را بررسی کنید، هر mutation را مستقل تحلیل کنید و سپس fixture انتقال را از هدف خودش دوباره بسازید. هر وضعیت انتخاب‌شده باید دست‌کم یک شرط آیندهٔ مرتبط با نوع review، migration، escalation، stop یا pivot داشته باشد؛ پر کردن هر پنج نوع اجباری نیست.
اجرا: python run_checks.py evidence/your_pack.json
CONSISTENT فقط یعنی JSON به fixture اعلام‌شده متصل است و با قواعد منتشرشده در CHECK_RULES.json سازگاری دارد؛ این نتیجه تأیید انسانی، اثبات حقوق، گواهی سازگاری بین‌ابزاری یا پاسخ پنهان نیست.
اتصال کامل وضعیت مثبت به fixture
برای READY یا TARGET_SPECIFIC، همهٔ فیلدهای حیاتی/الزامیِ وضعیت مثبت و هر الزام هدفی که در fixture ارسال‌شده وجود دارد باید ارائه شوند و با همان fixture تطبیق داشته باشند. material_slot_count فقط دادهٔ موجودی غیرحیاتی است: می‌توانید آن را ثبت کنید و checker در صورت ثبت، مقدارش را به fixture متصل می‌کند؛ اما نبود آن به‌تنهایی وضعیت مثبت را مسدود نمی‌کند.