مدل‌سازی سه‌بعدی و هوش مصنوعی — دامنه‌ی آینده · فصل ۱ — Blender، UV/PBR، Reconstruction و Optimization · 338
UV، PBR و AI-assisted Texturing
با ابزار یا اصطلاحات 3D آشناست اما pipeline production، quality و interoperability را end-to-end کنترل نمی‌کند. موضوع جاری: «UV, PBR و AI-assisted Texturing». می‌تواند «UV, PBR و AI-assisted Texturing» را در یک asset pipeline محدود اجرا و quality/interoperability evidence لازم را ثبت کند.
خلاصهٔ درس
با ابزار یا اصطلاحات 3D آشناست اما pipeline production، quality و interoperability را end-to-end کنترل نمی‌کند. موضوع جاری: «UV, PBR و AI-assisted Texturing».
می‌تواند «UV, PBR و AI-assisted Texturing» را در یک asset pipeline محدود اجرا و quality/interoperability evidence لازم را ثبت کند.
خروجی این درس
می‌تواند «UV, PBR و AI-assisted Texturing» را در یک asset pipeline محدود اجرا و quality/interoperability evidence لازم را ثبت کند.
پیش‌نیازها
یک متریال زیبا هنوز می‌تواند برای تولید قابل‌قبول نباشد
فرض کنید روی یک شیء سه‌بعدی در Blender کار می‌کنید. با کمک AI یک طرح ظاهری جذاب برای سطح ساخته‌اید و زیر یک HDRI همه‌چیز حرفه‌ای به نظر می‌رسد. اگر همین ظاهر را معیار نهایی بگیرید، چند مسئلهٔ مهم ممکن است پنهان بماند: بخشی از UVها ناخواسته روی هم افتاده باشند، Roughness با برداشت نادرست از فضای رنگ خوانده شود، قرارداد Normal روشن نباشد، یا تیم نتواند تشخیص دهد کدام بخش از بافت از مرجع تحویلی آمده و کدام بخش با کمک AI تولید یا بازسازی شده است.
در این درس قرار نیست فقط «تکسچر زیباتری» بسازید. خروجی شما یک مدرک قابل‌ممیزی است: UV-PBR Texture Set and Provenance Ledger v1. در این خروجی باید هدف UV، سیاست هم‌پوشانی و texel density، نقش کانال‌های PBR، برداشت رنگ/داده، قرارداد Normal، سابقهٔ کمک AI، منبع و وضعیت حقوق، ویرایش‌های دستی، رفتار متریال زیر نورهای متفاوت و مقصد سازگاری بین‌سامانه‌ای کنار هم ثبت شوند.
Blender می‌تواند برای یک mesh چند UV map نگه دارد و متریال را با مختصات یک UV map مشخص تغذیه کند؛ اما این توانایی دربارهٔ درست بودن seam، هم‌پوشانی یا density شما داوری نمی‌کند. glTF 2.0 نیز مدل PBR از نوع metallic-roughness و معنای مشخصی برای اتصال texture coordinateها دارد، ولی وجود TEXCOORD_n به‌تنهایی ثابت نمی‌کند چیدمان UV کم‌اعوجاج یا مناسب تولید است. [BLENDERUV] [BLENDERUVUSE] [GLTFSPEC] [GLTFPBR]
خروجی درس: UV-PBR Texture Set and Provenance Ledger v1 همراه با شواهد قابل‌مشاهده و یکی از وضعیت‌های محدود ACCEPT، TARGET_SPECIFIC، REWORK_REQUIRED، HOLD، EVIDENCE_INCOMPLETE، PROVENANCE_UNKNOWN یا METHOD_UNSUITABLE.
زمان فعال برنامه‌ریزی‌شده: ۶۰ دقیقه.
مرز درس: D3D-002 مالک تصمیم‌های مربوط به هدف UV، معنای کانال‌های PBR، اعتبارسنجی فضای رنگ و Normal، ثبت خاستگاه در AI-assisted Texturing، آزمون زیر نور تغییرکرده و شواهد سازگاری با مقصد است. این درس دستاورد مدل‌سازی تولید در D3D-001 یا بازسازی سه‌بعدی در D3D-003 را جذب نمی‌کند و دربارهٔ انتشار تجاری، مالکیت حقوقی یا اختیار انتشار حکم نمی‌دهد.
پیش‌نیاز HARD — D3D-001
پیش از ورود به این درس باید بتوانید مرزی را که از D3D-001 به این درس می‌آید توضیح دهید. فقط شواهدی را همراه بیاورید که D3D-002 واقعاً به آن نیاز دارد و دستاورد D3D-001 را در این درس جذب نکنید. اگر این مرز برایتان مبهم است یا شواهد هم‌ارز در دسترس نیست، پیش از ادامه از یک پل محدود یا مسیر شواهدی هم‌ارز استفاده کنید؛ تکمیل پیش‌نیاز را حدس نزنید.
مسیر را با شواهد انتخاب کنید، نه با میزان اطمینان ذهنی
قبل از شروع چهار سؤال را پاسخ دهید:
- اگر بافت در Viewport خوب دیده شود، آیا همین موضوع ثابت می‌کند سیاست هم‌پوشانی و texel density برای مقصد درست است؟
- چون Base Color و Roughness هر دو فایل تصویری‌اند، آیا باید هر دو را «دادهٔ رنگی» در نظر گرفت؟
- اگر بخشی که با AI ساخته شده از نظر ظاهری عالی باشد اما منبع و وضعیت حقوق آن روشن نباشد، آیا مجموعهٔ بافت می‌تواند وضعیت مثبت بگیرد؟
- اگر دارایی دوم عمداً UV قرینه داشته باشد و مقصد به ORM بسته‌بندی‌شده نیاز داشته باشد، آیا می‌توان تصمیم دارایی اول دربارهٔ UV یکتا و نقشه‌های جدا را بدون محاسبهٔ دوباره کپی کرد؟
۴ از ۴ → مسیر سریع. ۲ تا ۳ → مسیر اصلاح. ۰ تا ۱ → مسیر پایه. تفاوت مسیر فقط در میزان راهنمای مرحله‌ای است؛ معیار شواهد برای همه یکسان می‌ماند.
خودسنجی مسیر: در Q1 باید ظاهر را از شواهد UV جدا کنید؛ در Q2 دادهٔ رنگی را از دادهٔ عددی/متریال تشخیص دهید؛ در Q3 حق ندارید خاستگاه نامعلوم را با حدس پر کنید؛ در Q4 باید تصمیم را از شواهد مقصد جدید دوباره بسازید، نه این‌که حالت مبنا را پاسخ مرجع فرض کنید.
مدل ذهنی: اول مقصد، بعد شواهد، آخر حکم
ترتیب کار را ثابت نگه دارید:
هدف UV → سنجش اعوجاج/چگالی → قرارداد کانال‌های PBR → اعتبارسنجی فضای رنگ و Normal → ثبت منبع/خاستگاه AI → آزمون نور تغییرکرده → بررسی متریال در مقصد → ACCEPT / REWORK / HOLD
سه سطح را با هم قاطی نکنید:
| سطح | چه چیزی را می‌گوید؟ | به‌تنهایی چه چیزی را ثابت نمی‌کند؟ |
|---|---|---|
| واقعیت ابزار/قالب | Blender از UV map پشتیبانی می‌کند؛ glTF نقش‌های بافت و اتصال UV set را تعریف می‌کند | کیفیت seam، هم‌پوشانی، density یا خاستگاه دارایی شما |
| شواهد دارایی | این دارایی مشخص چه چیدمان، بافت، منبع و مقصدی دارد | این‌که می‌توان شواهد مفقود را «احتمالاً درست» فرض کرد |
| قاعدهٔ طراحی MAKNOW | برای یک وضعیت محدود چه شواهدی باید حاضر باشد | مالکیت حقوقی بیرونی، همسانی همهٔ رندررها یا مجوز انتشار |
موفق شدن Export فقط نشان می‌دهد عملیات خروجی‌گیری انجام شده است. رندر زیبا نیز فقط ظاهر یک نما زیر یک تنظیم مشخص را نشان می‌دهد. هیچ‌کدام جای Provenance Ledger را نمی‌گیرد.
پایه‌های مشترک
1. UV map یک تصمیم دربارهٔ مختصات است، نه گواهی کیفیت
در Blender، UV مختصات تصویر را به faceهای mesh متصل می‌کند و یک mesh می‌تواند بیش از یک UV map داشته باشد. این قابلیت اجازه می‌دهد متریال از UV set مشخص استفاده کند؛ اما صرف وجود UVMap دربارهٔ seam مناسب، اعوجاج قابل‌قبول، density هماهنگ یا هم‌پوشانی عمدی/ناخواسته چیزی ثابت نمی‌کند. [BLENDERUV] [BLENDERUVUSE]
در این درس ابتدا هدف را ثبت می‌کنید. مقادیری مثل UNIQUE_REQUIRED یا MIRROR_ALLOWED قرارداد مقصد هستند، نه قانون جهانی UV.
2. نقش‌های PBR باید به یک مدل متریال نام‌دار متصل شوند
در glTF 2.0 مدل اصلی PBR از metallic-roughness استفاده می‌کند. Base Color، Metallic/Roughness، Normal، Occlusion و Emissive نقش‌های مشخص متریال‌اند. در بافت metallic-roughness مربوط به glTF، کانال سبز Roughness و کانال آبی Metallic را حمل می‌کند. Base Color RGB با انتقال sRGB تفسیر می‌شود و Metallic/Roughness داده‌های غیررنگی/خطی هستند. [GLTFSPEC] [GLTFPBR]
این واقعیت‌ها به معنی یک چیدمان واحد برای همهٔ مقصدها نیست. اگر مقصد شما بسته‌بندی خاصی دارد، همان مقصد باید قرارداد کانال‌ها را صریح اعلام کند.
3. انتخاب UV set بخشی از رفتار قابل‌انتقال متریال است
glTF می‌تواند با texCoord مشخص کند هر بافت از کدام texture-coordinate set استفاده کند و این مقدار به TEXCOORD_n روی primitive مربوط می‌شود. این معنا مشخص می‌کند بافت از کدام مختصات استفاده کند؛ اما کیفیت آن مختصات را تأیید نمی‌کند. [GLTFSPEC]
4. کمک AI و کیفیت متریال دو سؤال مستقل‌اند
در MAKNOW، AI-assisted Texturing باید زنجیرهٔ خاستگاه داشته باشد: AI چه کاری انجام داده، منبع/مرجع چه بوده، وضعیت حقوق و خاستگاه از کجا آمده و چه ویرایش انسانی انجام شده است. سپس خود متریال همان بررسی‌های UV، PBR، نور و سازگاری با مقصد را می‌گذراند که یک مجموعهٔ بافت بدون AI باید بگذراند. ظاهر خوبِ تولیدشده با AI، خاستگاه ناشناخته را حل نمی‌کند؛ خاستگاه روشن نیز Roughness نادرست را اصلاح نمی‌کند. این بخش مرجع طراحی MAKNOW است و ادعا نمی‌کند Blender یا glTF دربارهٔ حقوق تصمیم می‌گیرند.
ساخت UV-PBR Texture Set and Provenance Ledger
گام 1 — پیش از سنجش بافت، دارایی و مقصد را نام‌گذاری کنید
ابتدا asset_id و interoperability_target را ثبت کنید. یک شیء سه‌بعدی برای یک مقصد بلادرنگِ نام‌دار ممکن است نیازهای UV و بسته‌بندی متفاوتی با یک دارایی سینمایی یا صحنهٔ ساخت داشته باشد. اگر مقصد مبهم باشد، معیار «درست بودن» مدام جابه‌جا می‌شود.
STANDARD_DECLARED_TARGET را فقط زمانی استفاده کنید که شواهد برای مقصد استاندارد اعلام‌شده و بدون محدودیت ویژه کافی است. اگر نتیجه فقط زیر یک قرارداد محدود و نام‌دار معتبر است، از CONSTRAINED_NAMED_TARGET_ONLY استفاده کنید و در صورت کفایت شواهد، وضعیت مثبت را به TARGET_SPECIFIC محدود نگه دارید.
گام 2 — هدف UV را پیش از سنجش کیفیت ثبت کنید
uv_set، هدف seam و uv_overlap_policy را بنویسید. سپس هم‌پوشانی مشاهده‌شده و اعوجاج را در برابر همین هدف بررسی کنید. هم‌پوشانی ناخواسته با قرینه‌سازی عمدی یکی نیست. از سوی دیگر، قرینه بودن یک UV island فقط به دلیل عمدی بودن پذیرفته نمی‌شود: اگر مقصد به جزئیات bakeشدهٔ یکتا نیاز داشته باشد، قرینه‌سازی می‌تواند با قرارداد مقصد ناسازگار باشد.
سؤال مفید این است: آیا چیدمان مشاهده‌شده با قاعدهٔ اعلام‌شده برای مقصد سازگار است؟ سؤال «قرینه‌سازی ذاتاً خوب است یا بد؟» در این درس پاسخ تولید نمی‌دهد.
گام 3 — stretch و texel density را به مقصد وابسته نگه دارید
uv_stretch_check باید نشان دهد دارایی در برابر قاعدهٔ تعریف‌شده برای همین پروژه یا نمونهٔ تمرینی چگونه عمل کرده است. texel_density_policy نیز سیاست هماهنگی جزئیات را ثبت می‌کند. عدد جهانی نسازید. یک دارایی اصلی، مجموعهٔ ماژولار و شیء کوچک بلادرنگ می‌توانند محدودیت‌های متفاوت داشته باشند. شواهد خوب هم قاعده را نشان می‌دهد و هم مقدار مشاهده‌شده را.
گام 4 — نقشهٔ کانال‌ها را کامل فهرست کنید
برای هر نقش متریال این موارد را نگه دارید:
- نقش، مانند
base_color،metallic،roughness،normal،occlusionو در صورت استفادهemissive؛ - مرجع تصویر/نقشه؛
- UV set؛
- برداشت رنگ/داده؛
- وضوح بافت؛
- محل کانال در صورت بسته‌بندی؛
- مرجع شواهد.
با این کار جملهٔ مبهم «تکسچرها حاضرند» به یک قرارداد متریال قابل‌بررسی تبدیل می‌شود.
گام 5 — برداشت فضای رنگ را بخشی از معنای متریال بدانید
برای مقصد اعلام‌شدهٔ glTF metallic-roughness، Base Color RGB دادهٔ رنگی با انتقال sRGB است؛ Metallic و Roughness داده‌های متریال و خطی‌اند. [GLTFSPEC] اگر Roughness را با برداشت sRGB بخوانید، فقط پیش‌نمایش را عوض نکرده‌اید؛ مقدار عددی ورودی متریال نیز تغییر کرده است.
در Lab همین درس، Normal و Occlusion نیز طبق قرارداد مقصد به‌عنوان دادهٔ غیررنگی/خطی ثبت می‌شوند. بررسی‌گر اگر یک وضعیت مثبت بر برداشت ناسازگار تکیه کند، تناقض را گزارش می‌کند؛ تصویر را اصلاح نمی‌کند و پاسخ را هم انتخاب نمی‌کند.
گام 6 — قرارداد Normal را صریح بنویسید
normal_convention یک فیلد الزامی برای شواهد مثبت است. عبارت «از این زاویه درست دیده می‌شود» کافی نیست. ناسازگاری میان قراردادهای مختلف tangent-space می‌تواند پس از انتقال به شکل برجستگی وارونه یا سایه‌پردازی ناسازگار دیده شود. هدف Ledger این است که این فرض پنهان نماند.
گام 7 — بسته‌بندی کانال‌ها را قرارداد مقصد ببینید
نقشه‌های جدا معمولاً بررسی و عیب‌یابی ساده‌تری دارند. بافت بسته‌بندی‌شده می‌تواند تعداد منابع را کم کند، اما وابستگی بیشتری میان معنای کانال‌ها و مقصد ایجاد می‌کند. هیچ‌کدام به‌طور مطلق «بهتر» نیست.
در نمونهٔ انتقال این درس، مقصد نام‌دار ORM را صریحاً این‌گونه تعریف می‌کند: R=Occlusion، G=Roughness، B=Metallic. این قرارداد متعلق به همان مقصد و نمونهٔ تمرینی است. نباید آن را به جملهٔ «glTF همیشه ORM می‌خواهد» تبدیل کنید. glTF معنای Metallic/Roughness را تعریف می‌کند؛ اشتراک یک تصویر و اضافه شدن Occlusion به همان بافت تصمیم مقصد/ساخت است و باید مستند شود. [GLTFSPEC]
گام 8 — زنجیرهٔ AI، منبع و خاستگاه را ثبت کنید
چهار جزء را جدا نگه دارید:
ai_assist_method: AI دقیقاً چه کمکی کرده است؛source_asset_ref: منبع یا مرجع تحویلی/مصنوعی چیست؛rights_provenance_ref: سند وضعیت حقوق/خاستگاه کجاست؛manual_edit_log: پس از کمک AI چه ویرایش انسانی انجام شده است.
عبارت «AI خودش ساخته، پس منبع ندارد» شواهد نیست. اگر خاستگاه از داده‌های موجود روشن نمی‌شود، وضعیت ناموفق مناسب مانند PROVENANCE_UNKNOWN را حفظ کنید.
گام 9 — پیش از اعتماد به ظاهر، نور را عوض کنید
یک HDRI خاص ممکن است مشکل Roughness، Normal یا تعادل مقدارها را پنهان کند. در Lab دست‌کم دو وضعیت نور نام‌دار را بررسی می‌کنید و مشاهدهٔ خودتان را می‌نویسید. این آزمون قرار نیست همسانی همهٔ رندررها را تضمین کند؛ هدف این است که تأیید متریال فقط به یک نور خوش‌نما وابسته نباشد.
پس شواهد نور تغییرکرده همچنان محدود است و دربارهٔ همهٔ پاسخ‌های دوربین، tone mapperها، رندررها یا نمایشگرها ادعای جهان‌شمول نمی‌کند.
گام 10 — سازگاری را قوی‌تر از «Export شد» بسنجید
مدل متریال، اتصال UV set، معنای کانال‌ها، قرارداد بسته‌بندی و قرارداد Normal مقصد را بررسی کنید. ممکن است فایل بدون خطا Export شود اما مقصد Roughness را از کانال اشتباه بخواند یا بافت به UV set دیگری وصل شده باشد. در این حالت موفقیت Export، سازگاری متریال را ثابت نکرده است.
گام 11 — وضعیت را از شواهد قوی‌تر نکنید
وضعیت مثبت فقط زمانی مجاز است که شواهد تعیین‌کنندهٔ موردنیاز مقصد حاضر و سازگار باشد:
ACCEPT: شواهد برای مقصد استاندارد اعلام‌شده کافی است؛TARGET_SPECIFIC: شواهد فقط برای مقصد محدود و نام‌دار کافی است؛REWORK_REQUIRED: مسیر قابل‌استفاده است اما اصلاح لازم دارد؛HOLD: مقصد، مرجع یا بازبینی تعیین‌کننده هنوز باید منتظر بماند؛EVIDENCE_INCOMPLETE: شواهد لازم ناقص است؛PROVENANCE_UNKNOWN: منشأ/حقوق روشن نشده است؛METHOD_UNSUITABLE: روش بافت‌سازی/متریال با مقصد اعلام‌شده سازگار نیست.
برای هر تصمیم دست‌کم یک شرط آینده‌نگر و واقعاً کاربردی برای بازبینی، مهاجرت، ارجاع، توقف یا تغییر مسیر ثبت کنید. لازم نیست هر پنج دسته را مکانیکی پر کنید. هرجا سناریو به شرط توقف یا تغییر مسیر نیاز دارد، همان شرط را صریح بنویسید.
مثال کامل: یک مورد ابزارِ مصنوعی جدا از پاسخ آزمایشگاه
برای آموزش، دارایی مجزایی با شناسهٔ SYNTH-TOOLCASE-WEX-01 را در نظر بگیرید. مقصد آن یک متریال استاندارد glTF 2.0 metallic-roughness با UV یکتا است. در Ledger، UV set نام‌دار، نبود هم‌پوشانی ناخواسته، بررسی تعریف‌شدهٔ stretch/density، نقشه‌های جدا برای Base Color/Metallic/Roughness/Normal/Occlusion، خاستگاه مصنوعیِ روشن، دو مشاهدهٔ نور و شواهد اتصال متریال ثبت شده‌اند.
نکتهٔ آموزشی، وضعیت از پیش پرشده نیست؛ قابلیت ردیابی است:
| ردیف شواهد | چه چیزی دیده می‌شود؟ | بازبین چه چیزی را می‌تواند بازسازی کند؟ |
|---|---|---|
| هدف UV | unique required + UV set نام‌دار | آیا هم‌پوشانی مشاهده‌شده با قاعده تناقض دارد؟ |
| نقش‌های PBR | نقش صریح برای هر نقشه | آیا نقش‌ها و اتصال‌های ضروری وجود دارند؟ |
| برداشت انتقال | Base Color=SRGB، داده‌های عددی=LINEAR | آیا معنای عددی اشتباهی تغییر کرده است؟ |
| خاستگاه | منبع مصنوعی + مرجع حقوق + ویرایش‌های دستی | آیا وضعیت منبع ثبت شده یا حدس زده شده است؟ |
| نور | دو وضعیت + مشاهده | آیا متریال فراتر از یک نور بررسی شده است؟ |
| سازگاری | مقصد نام‌دار + شواهد اتصال | آیا شاهد از «Exporter اجرا شد» قوی‌تر است؟ |
حالا فقط Roughness را از LINEAR به SRGB تغییر دهید و مقصد را ثابت نگه دارید. برداشت شواهد دیگر با قرارداد متریال سازگار نیست. اگر یادگیرنده بدون اصلاح همچنان وضعیت مثبت را حفظ کند، تصمیم او از شواهد قوی‌تر شده است.
در تغییر آزمایشی دیگر، چیدمان یکتا را با UV islandهای قرینهٔ عمدی جایگزین کنید. این تغییر لزوماً خطای جهانی نیست. باید از مقصد بپرسید: آیا جزئیات قرینه برای این مقصد و این ناحیه مجاز است؟ اگر قاعده همچنان UNIQUE_REQUIRED باشد، شواهد با قرارداد تناقض دارد. اگر مقصد به محیط اجرای نام‌داری تغییر کند که قرینه‌سازی را مجاز می‌داند، تصمیم باید برای همان مقصد از نو ساخته شود.
Lab اجرایی از نمونهٔ تمرینی دیگری استفاده می‌کند و در فایل شروع هیچ وضعیت نهایی آماده‌ای وجود ندارد.
حالت‌های خطایی که اعتماد کاذب می‌سازند
1. «واقعی به نظر می‌رسد، پس UV خوب است»
ظاهر یک نما همهٔ خطاهای هم‌پوشانی یا density را نشان نمی‌دهد. اصلاح: UV مشاهده‌شده را با قاعدهٔ هم‌پوشانی و density نوشته‌شده مقایسه کنید.
2. «هر چیزی که فایل تصویری است، رنگ محسوب می‌شود»
Base Color و Roughness هر دو تصویرند، اما معنای یکسان ندارند. اصلاح: برداشت هر نقش را ثبت و با مدل متریال مقصد کنترل کنید. [GLTFSPEC]
3. «AI ساخته، پس چیزی برای خاستگاه وجود ندارد»
AI ورودی منبع، مرجع، پرسش حقوق و سابقهٔ ویرایش را حذف نمی‌کند. اصلاح: زنجیرهٔ موجود را ثبت کنید؛ اگر مسئله روشن نمی‌شود، حدس نزنید.
4. «جهت Normal فقط مسئلهٔ ظاهر است»
قرارداد اشتباه می‌تواند پس از انتقال سایه‌پردازی یا برجستگی را وارونه یا ناسازگار کند. اصلاح: قرارداد را در یک فیلد نام‌دار ثبت و در زنجیرهٔ مقصد بررسی کنید.
5. «ORM بسته‌بندی‌شده همیشه حرفه‌ای‌تر است»
بسته‌بندی یک تصمیم دربارهٔ منابع و چیدمان است. اصلاح: آن را به مقصد مشخص ببندید و نگاشت کانال‌ها را صریح نگه دارید.
6. «فایل Export شد، پس سازگار است»
Export می‌تواند با اتصال UV یا برداشت کانال نادرست هم موفق شود. اصلاح: قرارداد متریال را در مقصد بررسی کنید.
7. «حالت مبنا پذیرفته شده، پس انتقال هم همان جواب را دارد»
در انتقال، فرض‌های هم‌پوشانی و بسته‌بندی تغییر کرده‌اند. اصلاح: وضعیت حالت مبنا را کنار بگذارید و فقط از شواهد تغییرکرده نتیجه بسازید.
پل برای یادگیرندهٔ باتجربه: ساخت texture را یک قرارداد متریال نسخه‌دار ببینید
اگر با Blender و texturing آشنا هستید، ارزش این درس در توضیح دوبارهٔ دکمه‌های UV Editor نیست. مسئلهٔ حرفه‌ای این است که صحنهٔ ساخت و قرارداد متریال مقصد را هماهنگ نگه دارید، بدون این‌که فرض کنید معنای این دو همیشه یکسان است.
یک الگوی فشرده:
asset_id، نسخهٔ هندسه، شناسهٔ UV set و مقصد متریال را با هم نسخه‌بندی کنید؛- منبع/خاستگاه بافت را از خروجی‌های مشتق‌شده جدا نگه دارید؛
- برداشت رنگ/دادهٔ هر نقش را صریح ثبت کنید؛
- بسته‌بندی را مبدل ویژهٔ مقصد بدانید، نه معنای پایهٔ خود بافت؛
- پیش از تأیید دست‌کم یک آزمون زیر نور تغییرکرده انجام دهید؛
- با هر تغییر در UV، مقصد اجرا، بسته‌بندی، قرارداد Normal یا خاستگاه، Ledger را دوباره اجرا کنید.
در این تعریف، قابلیت انتقال به معنی «همه‌جا دقیقاً یکسان دیده شود» نیست؛ یعنی شواهد آن‌قدر روشن باشد که وقتی دارایی جابه‌جا شد، بدانید دقیقاً چه چیزهایی باید دوباره راستی‌آزمایی شوند.
گزینه‌ها و بده‌بستان‌ها بدون برندهٔ دائمی
UV یکتا در برابر قرینه‌سازی عمدی. UV یکتا مختصات ناحیه‌ها را جدا نگه می‌دارد؛ قرینه‌سازی عمدی برای نواحی اعلام‌شده مختصات را بازاستفاده می‌کند. انتخاب به جزئیات مقصد، bake، نامتقارنی و محدودیت‌های اجرا وابسته است. از هیچ‌کدام مزیت عملکردی جهانی استنباط نکنید؛ الزام شواهدی این درس اعلام هدف و تشخیص هم‌پوشانی ناخواسته است.
نقشه‌های جدا در برابر نقشهٔ بسته‌بندی‌شده. نقشه‌های جدا مرز نقش‌ها را در Ledger آشکار نگه می‌دارند. نقشهٔ بسته‌بندی‌شده چند نقش اعلام‌شده را در یک منبع ویژهٔ مقصد ترکیب می‌کند و آن نقش‌ها را به قرارداد کانال‌های مقصد وابسته می‌سازد. اثر کارایی، ذخیره‌سازی یا خواندن باید برای همان مقصد اندازه‌گیری شود، نه این‌که از نوع بسته‌بندی فرض شود.
ساخت کاملاً دستی در برابر AI-assisted. کار دستی هم می‌تواند خاستگاه روشن یا ضعیف داشته باشد؛ AI-assisted نیز همین‌طور. MAKNOW کیفیت را از روی نام ابزار نمره نمی‌دهد. وقتی از AI کمک گرفته می‌شود، منبع/خاستگاه، وضعیت حقوق، سابقهٔ ویرایش و بررسی‌های مستقل متریال باید ثبت شوند.
ساخت در Blender در برابر مقصد glTF. Blender از چند UV map پشتیبانی می‌کند؛ glTF 2.0 یک بازنمایی محدود و قابل‌انتقال بین‌سامانه‌ای تعریف می‌کند. توانایی ساخت و قرارداد تبادل را جدا نگه دارید و از هیچ‌کدام همسانی همهٔ رندررها یا یک فرایند جهانی استنباط نکنید. [BLENDERUV] [GLTFSPEC] [GLTFPBR]
وضوح بیشتر در برابر density کنترل‌شده. پیکسل بیشتر چیدمان بد را اصلاح نمی‌کند و یکنواختی جزئیات را تضمین نمی‌کند. وضوح را همراه با مقصد، قاعدهٔ density، بودجهٔ حافظه/کارایی و شواهد کیفیت بسنجید.
تمرین هدایت‌شده و مستقل
تمرین هدایت‌شده — بستهٔ شواهد حالت مبنا را بسازید
به lab://D3D-002/D3D-002-LAB1 بروید. از learner/evidence/evidence_pack.template.json یک نسخهٔ کاری با نام خودتان بسازید و سپس fixtures/baseline_fixture.json را بررسی کنید. فقط شواهد قابل‌مشاهده را منتقل کنید. پاسخ پنهانی وجود ندارد.
decision را در آخر پر کنید. علاوه بر استدلال، دست‌کم یک شرط کاربردی و نام‌دار از دسته‌های review، migration، escalation، stop یا pivot ثبت کنید؛ اگر سناریو شرط توقف یا تغییر مسیر می‌خواهد، آن را صریح بنویسید. سپس اجرا کنید:
python run_checks.py evidence/my_pack.jsonبررسی‌گر تناقض‌ها را در برابر CHECK_RULES.json گزارش می‌کند. خروجی CONSISTENT فقط یعنی بستهٔ شواهد با قواعد آشکار تناقض داخلی ندارد؛ به معنی تأیید نیست.
تغییر آزمایشی A — قرینه‌سازی عمدی
mutation_mirrored_uvs.json را اعمال کنید. دقیقاً مشخص کنید کدام فیلد یا قاعدهٔ مقصد باید دوباره بررسی شود. پاسخ «قرینه‌سازی همیشه غلط است» قابل‌قبول نیست.
تغییر آزمایشی B — Roughness با sRGB
mutation_roughness_srgb.json را اعمال کنید. خطا را از برداشت تصویر تا معنای متریال ردیابی کنید و حداقل اصلاح و راستی‌آزمایی دوبارهٔ لازم را بنویسید.
تغییر آزمایشی C — خاستگاه نامعلوم
mutation_unknown_ai_provenance.json را اعمال کنید. شواهد مفقود را با وضعیت ناموفق مناسب حفظ کنید و هیچ منبع یا مجوز تازه‌ای نسازید.
انتقال مستقل — UV قرینه + ORM بسته‌بندی‌شده
از transfer/transfer_fixture.json و transfer/transfer_evidence_pack.template.json استفاده کنید. مقصد جدید برای ناحیهٔ اعلام‌شده قرینه‌سازی عمدی را می‌پذیرد و ORM را به‌صورت R=Occlusion، G=Roughness، B=Metallic تعریف می‌کند. هم‌پوشانی، بسته‌بندی و برداشت داده را از مقصد جدید دوباره محاسبه کنید. نتیجهٔ حالت مبنا برای این نمونهٔ تمرینی مرجع پاسخ نیست.
راستی‌آزمایی: بازبین باید بتواند تصمیم را بدون دیدن فرایند شما بازسازی کند
پیش از تحویل از خودتان بپرسید آیا فردی که هنگام ساخت کنار شما نبوده، فقط با همین بستهٔ شواهد می‌تواند مسیر تصمیم را بازسازی کند؟
یک بستهٔ شواهد قوی به این سؤال‌ها پاسخ می‌دهد:
asset_idو UV set دقیق چیست؟- قاعدهٔ هم‌پوشانی چه بوده و چه هم‌پوشانی‌ای مشاهده شده است؟
- stretch و قاعدهٔ texel density چگونه بررسی شده‌اند؟
- مدل متریال مقصد چیست؟
- هر نقش متریال از کدام نقشه می‌آید؟
- هر نقشه به‌عنوان دادهٔ رنگی یا غیررنگی چگونه تفسیر می‌شود؟
- قرارداد Normal و قرارداد بسته‌بندی چیست؟
- AI چه کاری کرده، منبع چه بوده، شواهد حقوق/خاستگاه چیست و انسان چه ویرایشی انجام داده است؟
- زیر دست‌کم دو وضعیت نور چه تغییری دیده شده است؟
- مقصد سازگاری دقیقاً چیست و چه چیزی را بررسی کرده‌اید؟
- چه شواهدی هنوز مفقود یا مورد اختلاف است؟
- چرا وضعیت نهایی از شواهد قوی‌تر نیست؟
- چه شرایطی
review،migration،escalation،stopیاpivotرا فعال می‌کند؟
بررسی‌گر فقط تناقض قواعد را پیدا می‌کند. مالکیت را اثبات نمی‌کند، خاستگاه نمی‌سازد، کیفیت بصری ثبت‌نشده را حدس نمی‌زند و مجوز انتشار صادر نمی‌کند. مسئولیت بازبینی انسانی باقی می‌ماند.
ارزیابی و انتقال
S1 — بازیابی: مرز درس را حفظ کنید
توضیح دهید D3D-002 دقیقاً مالک چه دستاوردهایی است و یک دستاورد مجاور که متعلق به این درس نیست نام ببرید. در پاسخ باید واقعیت‌های بیرونی ابزار/قالب را از مرجع طراحی MAKNOW جدا کنید.
S2 — کاربرد: خروجی حالت مبنا
از نمونهٔ تمرینی مصنوعیِ حالت مبنا یک UV-PBR Texture Set and Provenance Ledger v1 کامل بسازید. وضعیت مثبت الزامی نیست؛ وضعیت باید با شواهد متناسب باشد. فیلد تعیین‌کنندهٔ مفقود یا ادعای موفقیت بدون پشتوانه مانع پذیرش است.
S3 — تشخیص: از UV یکتا به UV قرینه
تغییر آزمایشی تبدیل UV یکتا به UV islandهای قرینهٔ عمدی را تحلیل کنید. فرض شکسته‌شده، پیامد و کوچک‌ترین تغییر لازم در مقصد/شواهد را پیش از صدور وضعیت تازه مشخص کنید.
S4 — انتقال: مقصد بلادرنگ با ORM بسته‌بندی‌شده
برای دارایی دوم در مقصد نام‌دار، تصمیم را از نو بسازید. اتصال کانال‌ها، برداشت رنگ/داده، قاعدهٔ UV، خاستگاه، نور و شواهد سازگاری را نشان دهید. کپی کردن وضعیت حالت مبنا مانع پذیرش است.
همهٔ مسیرها با پنج بُعد مشترک سنجیده می‌شوند: هویت/قرارداد، اتصال دقیق شواهد، شواهد منفی، تصمیم محدود و انتقال. تصویر صفحهٔ زیبا جای شواهد تعیین‌کننده را نمی‌گیرد.
منابع، تازگی و مرز ادعا
منابع بیرونی این درس عمداً محدود نگه داشته شده‌اند:
- [BLENDERUV] مستندات Blender 5.2 LTS، بخش UVs & Texture Space: پشتیبانی از UV mapهای صریح و متعدد را نشان می‌دهد؛ seam، هم‌پوشانی یا density درست برای تولید را تعیین نمی‌کند.
- [BLENDERUVUSE] مستندات Blender 5.2 LTS، بخش UV Map Node: انتخاب یک UV map مشخص برای مختصات بافت در متریال را پشتیبانی می‌کند؛ کیفیت چیدمان UV را اثبات نمی‌کند.
- [GLTFSPEC] مشخصات Khronos glTF 2.0 (2.0.1): نقش‌های متریال، اتصال texture-coordinate set و معنای اصلی کانال/انتقال را پشتیبانی می‌کند؛ همسانی رندررها یا تأیید تولید را تضمین نمی‌کند.
- [GLTFPBR] مرور رسمی Khronos دربارهٔ glTF PBR: زمینهٔ مدل PBR قابل‌انتقال بین‌سامانه‌ای را توضیح می‌دهد؛ آستانه‌های پذیرش MAKNOW را تعریف نمی‌کند.
این منابع رسمی در 2026-09-06 دوباره بررسی شدند. معنای فنی مورد استناد همچنان در همان مرز ادعای بیان‌شده در درس قرار دارد. بازبینی بعدی برای 2026-10-18 برنامه‌ریزی شده است، مگر آن‌که معنای فنیِ استنادشده در Blender یا glTF زودتر تغییر مادی داشته باشد.
الزام‌های مربوط به خاستگاه، واژگان وضعیت، شرط‌های بازبینی و منطق پذیرش متعلق به مرجع طراحی MAKNOW هستند. هر بار از منبع رسمی استفاده می‌کنید، این مرز را حفظ کنید.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ملاک‌های ارزیابی (rubric)
All five dimensions are critical. A visually attractive screenshot cannot compensate for a missing decisive dimension.
| Dimension | Sufficient evidence | Blocking failure |
|---|---|---|
| Identity and contract | D3D-002 boundary is explicit; D3D-001/D3D-003 and release/rights outcomes remain outside scope | adjacent scope is absorbed |
| Exact evidence binding | UV/PBR/color-data/provenance/target claims trace to the correct FACT or MAKNOW DESIGN authority | tool/format docs are treated as production approval |
| Negative evidence | at least one mutation is diagnosed; missing/disputed evidence remains typed | unsupported success is forced |
| Bounded decision | state is no stronger than evidence and names at least one applicable review/migration/escalation/stop/pivot condition; an explicit stop/pivot condition is present when the case requires it | decisive field missing or trigger set empty |
| Transfer | second runtime decision is recomputed from mirrored-UV + packed-ORM target evidence | baseline verdict is copied |
Human review must reproduce the decision from visible evidence. CONSISTENT checker output is not approval.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
این آزمایش کاملاً محلی، مصنوعی، دارای حقوق روشن و عمداً حل‌نشده است. هیچ اعتبارنامهٔ سامانهٔ تولیدی، دادهٔ خصوصی، مرحلهٔ انتشار تجاری، وابستگی پولی به سرویس ابری، عملیات تخریبی بیرونی یا کلید پاسخ پنهان در آن وجود ندارد.
- از
evidence/evidence_pack.template.jsonیک فایل کاری تازه بسازید. fixtures/baseline_fixture.jsonرا بخوانید و فقط شواهد قابل‌مشاهده را منتقل کنید.decision.final_state، استدلال و دست‌کم یک شرط آینده‌نگرِ واقعاً کاربردی را خودتان بنویسید؛ لازم نیست هر پنج دستهٔ شرط را به‌صورت مکانیکی پر کنید.python run_checks.py evidence/your_pack.jsonرا اجرا کنید.- سه تغییر آزمایشی را جداگانه اعمال و تصمیم را دوباره محاسبه کنید.
- در پایان
transfer/transfer_fixture.jsonرا مستقل حل کنید؛ حکم حالت مبنا را کپی نکنید.
CHECK_RULES.json منبع آشکار قواعد است و pack_rules.py همین قواعد را فقط برای سنجش سازگاری و شواهد مصرف می‌کند. خروجی CONSISTENT به معنی تأیید یا افشای پاسخ مورد انتظار نیست.