3D Asset Optimization و Interoperability

وقتی Export موفق است اما Asset هنوز قابل تحویل نیست

یک asset نهایی در Blender درست دیده می‌شود. قرار است همان asset در یک realtime web viewer مصرف شود و در عین حال بتوان آن را به یک DCC دیگر تحویل داد. فایل GLB باز می‌شود، اما سه نشانه دارید: texture memory از بودجهٔ هدف بیشتر است، یک material feature به extensionای وابسته است که viewer مقصد پشتیبانی نمی‌کند، و بعد از round-trip یکی از transformها تغییر کرده است. اگر معیار شما فقط «Export succeeded» باشد، این asset ظاهراً آماده است؛ اگر معیار شما delivery contract باشد، هنوز سه کنترل مهم باز است.

در این درس 3D Delivery Budget and Interoperability Validation Pack v1 می‌سازید. این artifact قبل از هر تصمیم مثبت، target runtime، format/version، واحد و coordinate convention، بودجهٔ geometry/texture/material/draw primitives، سیاست LOD و compression، نیاز animation، transform/material validation، extension support، downstream check، round-trip، quality delta، provenance و وضعیت نهایی را کنار هم قرار می‌دهد. هدف این نیست که asset را «تا جای ممکن کوچک» کنید؛ هدف این است که آن را برای یک target مشخص، درون budget مشخص و با افت کیفیتِ قابل قبولِ همان پروژه قابل مصرف کنید.

glTF 2.0 در این درس نمونهٔ اصلی runtime asset delivery است؛ مشخصات رسمی Khronos آن را برای انتقال 3D scene data به‌صورت compact/extensible تعریف می‌کند و registry رسمی همچنان major version جاری را 2.0 معرفی می‌کند. وجود extension به معنی پشتیبانی خودکار در هر viewer نیست. برای مسیرهای DCC/film نیز OpenUSD یک خانوادهٔ specification برای scene description و interchange، از جمله USD Core، UsdPreviewSurface و USDZ منتشر می‌کند. این facts ابزار انتخاب هستند، نه مجوز برای اعلام interoperability. [GLTFSPEC] [GLTFREGISTRY] [OPENUSD]

خروجی درس: یک بستهٔ شواهد قابل audit که نشان دهد asset برای target اعلام‌شده INTEROPERABLE، INTEROPERABLE_WITH_KNOWN_DIFFERENCES، TARGET_SPECIFIC، REWORK_REQUIRED، HOLD، EVIDENCE_INCOMPLETE، PROVENANCE_UNKNOWN یا METHOD_UNSUITABLE است.

زمان فعال تقریبی: ۶۰ دقیقه.

مرز درس: این درس تصمیم‌گیرِ optimization و interoperability نهایی است. مهارت production modeling درس D3D-001 و مقایسهٔ Photogrammetry/NeRF/3D Gaussian Splatting درس D3D-003 را دوباره آموزش نمی‌دهد. اگر source asset از reconstruction آمده باشد، فقط شواهد لازم آن را به این delivery decision وارد می‌کنید.

پیش‌نیاز سخت — D3D-001

پیش از ادامه باید بتوانید برای یک production mesh حداقل این مرز را بیان کنید: ظاهر خوب در viewport جای scale، transforms، topology intent، normals، naming، geometry statistics و known limitations را نمی‌گیرد. اگر این مرز برای شما روشن نیست، ابتدا شواهد معادل D3D-001 را بازسازی کنید؛ این درس completion پیش‌نیاز را فرض یا جعل نمی‌کند.

Probe: یک mesh با ظاهر مناسب دارید اما unit scale ثبت نشده و transformهای object اعمال/ثبت نشده‌اند. آیا می‌توانید آن را فقط به دلیل render خوب وارد delivery validation کنید؟ پاسخ قابل قبول باید بگوید «نه؛ source geometry contract هنوز شواهد ناقص دارد» و دقیقاً missing field را نام ببرد.

پیش‌نیاز نرم — D3D-003

اگر asset از photogrammetry، NeRF یا 3D Gaussian Splatting آمده است، باید بتوانید representation را از delivery asset جدا کنید. novel-view quality به‌تنهایی ثابت نمی‌کند که یک editable mesh، metric scale یا target-compatible material دارید. اگر این تمایز شکننده است، یک bridge کوتاه بسازید: source representation، تبدیل‌های انجام‌شده، metric/geometry شواهد و provenance را قبل از optimization ثبت کنید.

مسیر مناسب را انتخاب کنید

بدون نگاه‌کردن به ادامه، چهار سؤال را جواب دهید:

1. اگر asset از نظر triangles زیر بودجه باشد ولی texture memory دو برابر سقف هدف باشد، آیا «optimized» است؟
2. اگر یک glTF از نظر syntax معتبر باشد اما extensionsRequired آن featureای بخواهد که viewer مقصد نمی‌شناسد، آیا interoperability ثابت شده است؟
3. اگر asset در target viewer درست دیده شود ولی بعد از round-trip یک node transform تغییر کند، چه چیزی هنوز باید باز بماند؟
4. اگر target از realtime web به offline USD-centric film pipeline عوض شود، آیا همان triangle budget و همان format decision را باید کپی کرد؟

۴/۴ → مسیر سریع: مستقیم به fixture و بستهٔ شواهد بروید. ۲–۳/۴ → مسیر اصلاح: فقط تمایز شکست‌خورده را بازسازی کنید. ۰–۱/۴ → مسیر پایه: مدل ذهنی و چهار مفهوم پایه را کامل بخوانید.

مسیر سریع سطح شواهد را کم نمی‌کند. در همهٔ مسیرها وضعیت نهایی باید از شواهد قابل مشاهده بازتولید شود.

خودسنجی مسیر: فقط وقتی یک امتیاز بدهید که این تمایز را گفته باشید: ۱) خیر — همهٔ بودجه‌های اعلام‌شده مهم‌اند، نه فقط triangles. ۲) خیر — اعتبار نحوی با پشتیبانی مصرف‌کننده یکی نیست. ۳) ادعای مثبت interoperability باید باز بماند تا transform drift حل شود. ۴) خیر — تغییر target یعنی بودجه‌ها و کنترل‌های format/validation باید از نو ساخته شوند. این خودسنجی فقط سطح راهنمایی را تعیین می‌کند و پاسخ lab را لو نمی‌دهد.

مدل ذهنی: Interoperability یک زنجیرهٔ کنترل است

جریان تصمیم این درس چنین است:

Delivery target → measurable budgets → optimize geometry/textures/materials → explicit format + extensions → downstream validation → round-trip + quality delta → disclose unsupported/changed features → bounded final state

این ترتیب مهم است. اگر ابتدا decimate کنید و بعد تازه target را تعریف کنید، نمی‌دانید چه چیزی را باید حفظ می‌کردید. اگر format را صرفاً بر اساس familiarity انتخاب کنید، ممکن است قابلیت لازم target یا DCC مقصد را از دست بدهید. اگر فقط screenshot مقایسه کنید، transform یا unit drift را ممکن است نبینید.

سه دسته شواهد را از هم جدا نگه دارید:

وضعیت نهایی یک امتیاز ترکیبی مبهم نیست. یک کنترل بحرانی می‌تواند تصمیم مثبت را ببندد حتی اگر بقیهٔ ستون‌ها عالی باشند.

چهار مفهوم پایه

۱. Target-first budget

«کم‌پلی»، «سبک» یا «برای وب مناسب» budget نیستند. budget باید به target و measurement متصل باشد: مثلاً سقف triangles، texture memory، material count، primitive count و quality delta. این thresholdها MAKNOW یا استاندارد جهانی نیستند؛ در lab همین درس مقادیر fixture-specific هستند تا بتوانید تصمیم را تمرین کنید. در پروژهٔ واقعی باید از performance envelope و target constraints همان محصول بیایند.

۲. Optimization به‌عنوان constrained transformation

Optimization یعنی کم‌کردن هزینه بدون پاک‌کردن requirement حیاتی. سه سؤال همیشه کنار هم‌اند: چه چیزی کم شد؟ کدام شواهد نشان می‌دهد target budget بهتر شد؟ کدام check نشان می‌دهد quality یا semantics لازم از بین نرفته است؟ اگر فقط file size را کم کرده‌اید اما normal map، silhouette، rig یا material behavior شکسته، optimization موفق نیست.

۳. Interoperability به‌عنوان downstream proof

Export یک event است؛ interoperability یک claim است. برای claim به consumer واقعی یا حداقل validator/fixture نمایندهٔ target نیاز دارید. glTF می‌تواند meshes، materials، transforms و animation data را حمل کند، اما consumerها ممکن است extensionها یا rendering behavior متفاوتی داشته باشند. بنابراین valid file، loads successfully و behaves within declared target limits سه سطح متفاوت‌اند. [GLTFSPEC] [GLTFREGISTRY]

۴. Known differences و provenance

گاهی delivery بدون تفاوت ممکن نیست. ممکن است clearcoat را به material ساده‌تری bake/approximate کنید، shader اختصاصی را حذف کنید، یا برای target خاص variant بسازید. تفاوت مجاز باید نام‌گذاری و محدود شود؛ پنهان‌کردن آن interoperability نیست. همچنین provenance باید روشن باشد: synthetic، self-created، public-domain یا explicitly rights-cleared. AI نباید ownership یا permission را حدس بزند.

ساخت 3D Delivery Budget and Interoperability Validation Pack v1

گام ۱ — Delivery target را قبل از format بنویسید

حداقل این فیلدها را ثبت کنید: target name/version یا capability profile، realtime/offline، device class در صورت ارتباط، rendering/material constraints، animation requirement، memory/performance envelope و downstream DCC/runtimeهایی که واقعاً باید asset را مصرف کنند. اگر target مبهم است، تصمیم format هنوز premature است.

گام ۲ — Geometry budget را measurable کنید

triangle_budget و vertex_budget را از target بگیرید و observed values را جدا ثبت کنید. تعداد triangle به‌تنهایی کیفیت topology را توضیح نمی‌دهد؛ این درس outcome مدل‌سازی D3D-001 را دوباره باز نمی‌کند. اما برای delivery باید بدانید mesh در budget هست یا نه و هر reduction چه quality delta ایجاد کرده است.

راهبردهای ممکن شامل حذف geometry نامرئی، decimation کنترل‌شده، mesh simplification، variant/LOD policy و split کردن asset هستند. هیچ‌کدام به‌خودی‌خود «بهتر» نیست. اگر LOD mechanism در target standard نشده یا runtime-specific است، آن را target-specific ثبت کنید و به‌عنوان قابلیت core format جا نزنید.

گام ۳ — Texture memory را از resolution جدا کنید

یک texture 4K لزوماً «زیاد» یا «کم» نیست؛ تعداد textureها، channelها، format/compression و mip behavior روی memory اثر می‌گذارند. برای lab، memory observation آماده است تا تصمیم deterministic باشد. در pipeline واقعی، روش اندازه‌گیری را همراه شواهد ثبت کنید. کاهش resolution، channel packing یا compression فقط وقتی قبول است که material validation و quality delta هنوز داخل boundary پروژه بمانند.

گام ۴ — Materials و draw primitives را هزینه محسوب کنید

تعداد material و primitive می‌تواند روی draw overhead و portability اثر بگذارد. merge بی‌قاعده نیز می‌تواند editability یا material semantics را از بین ببرد. بنابراین هم material_count_budget و هم draw_primitive_budget را ثبت کنید و اگر consolidation انجام شد، mapping قبل/بعد را نگه دارید.

گام ۵ — Units، coordinate convention و transforms را صریح کنید

Round-trip یعنی فقط دوباره بازشدن فایل نیست. حداقل یک شناسهٔ node/object پایدار انتخاب کنید و position/rotation/scale یا matrix مربوط را قبل و بعد مقایسه کنید. tolerance باید از پروژه بیاید و در pack نوشته شود. برای audit، سه جزء را جدا ثبت کنید: transform_tolerance، transform_observation_ref و transform_delta_observed. اگر transform drift بیرون tolerance است، نتیجهٔ مثبت را نگه ندارید؛ علت ممکن است exporter، importer، axis conversion، unit conversion یا وضعیت authoring باشد و باید جدا بررسی شود.

گام ۶ — Format و extensionها را دو سطحی ثبت کنید

برای glTF، core version و extensionsUsed/Required را از asset استخراج کنید. Khronos registry extensionهایی برای material features، compression و قابلیت‌های دیگر نگه می‌دارد. used_extensions، required_extensions و target_supported_extensions را جدا ثبت کنید. اگر feature در required_extensions است ولی target support matrix آن را ندارد، INTEROPERABLE مجاز نیست. تا وقتی extension لازم پشتیبانی نمی‌شود، TARGET_SPECIFIC مجاز نیست و وضعیت باید non-success مانند REWORK_REQUIRED بماند. می‌توانید feature را حذف/approximate کنید، target را عوض کنید یا variant target-specific بسازید؛ سپس همهٔ hard gateها را دوباره validate کنید. فقط پس از پاس‌شدن hard gateها، TARGET_SPECIFIC می‌تواند برای یک قید صریح portability معتبر باشد. [GLTFREGISTRY]

برای OpenUSD، به‌جای فرض‌کردن «USD همه‌چیز را نگه می‌دارد»، featureهای مورد نیاز pipeline را به schema/material/composition expectations مشخص وصل کنید. UsdPreviewSurface عمداً یک preview/interchange surface است و همهٔ shading concepts را پوشش نمی‌دهد؛ USDZ نیز delivery/package constraintهای خودش را دارد. [OPENUSD]

گام ۷ — Downstream check و round-trip را از هم جدا کنید

• downstream_viewer_check: آیا consumer هدف asset را با behavior لازم مصرف می‌کند؟
• round_trip_check: آیا asset پس از عبور از مسیر تعریف‌شده، semantic fields مهم را در tolerance نگه می‌دارد؟

ممکن است اولی PASS و دومی FAIL شود. این تناقض نیست؛ دو claim متفاوت هستند.

گام ۸ — Quality delta را کنار cost reduction نگه دارید

برای هر optimization، baseline و optimized observation داشته باشید. metric می‌تواند بسته به پروژه silhouette error، image comparison، normal/material parameter delta، animation deviation یا human review rubric باشد. در lab، یک quality_delta_pct fixture-specific استفاده می‌شود. آن را universal quality metric تلقی نکنید.

گام ۹ — یک تقدم قطعی برای وضعیت نهایی به‌کار ببرید

اولین قاعده‌ای که با شواهد دیده‌شده جور است، وضعیت اصلی را تعیین می‌کند؛ بنابراین یک مجموعه شواهد به چند برچسب هم‌ارز ختم نمی‌شود.

1. METHOD_UNSUITABLE — محدودیت صریح روش/مسیر نشان می‌دهد قیدهای اعلام‌شده با این روش برآورده نمی‌شوند.
2. PROVENANCE_UNKNOWN — منشأ یا مجوز لازم برای انتشار حل نشده است.
3. HOLD — تصمیم یا تأیید بیرونی در انتظار است؛ از جمله تفاوت محدود شناخته‌شده‌ای که هنوز صریحاً پذیرفته نشده است.
4. EVIDENCE_INCOMPLETE — شواهد فنی تصمیم‌ساز ناقص/نامعتبر است و هیچ شرط با اولویت بالاتر برقرار نیست.
5. REWORK_REQUIRED — شواهد تصمیم‌ساز کامل است اما یک کنترل قابل اصلاح در بودجه، پشتیبانی یا اعتبارسنجی شکست خورده است.
6. TARGET_SPECIFIC — کنترل‌های سخت پاس‌اند اما یک قید صریح target-specific عمداً portability را محدود می‌کند.
7. INTEROPERABLE_WITH_KNOWN_DIFFERENCES — کنترل‌های سخت پاس‌اند و دست‌کم یک تفاوت محدود با description، impact، acceptance_status=ACCEPTED و acceptance_ref ثبت شده است.
8. INTEROPERABLE — همهٔ کنترل‌های سخت پاس‌اند و نه تفاوت شناخته‌شده‌ای باقی است و نه قید portability هدف‌محور.

اگر چند شرط هم‌زمان برقرار بود، مورد بالاتر برنده است. AI می‌تواند فیلدها را مرتب و سازگاری قطعی را بررسی کند؛ اجازه ندارد اندازه‌گیری، حق استفاده، پشتیبانی مصرف‌کننده یا تأیید انسانی را حدس بزند.

مثال کارشده: فایل باز می‌شود، اما سه کنترل شکست خورده‌اند

نمونهٔ منفی کارشده از fixture مصنوعی worked_example_three_failures.json استفاده می‌کند و از baseline تمیز mutationها جداست. سقف‌ها 120k triangles، 100k vertices، 64 MiB texture memory، 12 material و 18 draw primitive هستند و quality delta مجاز این fixture حداکثر 2% است. target از KHR_draco_mesh_compression پشتیبانی می‌کند، اما KHR_materials_clearcoat را پشتیبانی نمی‌کند. projection کامل ۱۶ فیلد در D3D-004-T1 نیز موجود است.

برای همهٔ فیلدهای قفل‌شده از جدول کامل D3D-004-T1 استفاده کنید؛ این جدول target، format/version، units، coordinate convention، tris/verts، texture memory، materials/primitives، LOD، compression/extensions، animation/skin/morph، unsupported features، downstream، round-trip، quality delta، provenance و وضعیت را یکجا نگه می‌دارد.

فایل باز شده است، اما وضعیت نهایی باید حداقل REWORK_REQUIRED باشد. سه اصلاح مستقل دارید: texture memory را بدون عبور quality delta از budget پایین بیاورید؛ clearcoat را برای target به representation پشتیبانی‌شده تبدیل یا variant target-specific بسازید؛ و transform drift را تا داخل tolerance حل کنید.

بعد از اصلاح فرضی، مشاهدهٔ جدید 58 MiB texture memory، بدون required unsupported extension، round-trip PASS و quality delta 1.6% است. اگر clearcoat به approximation ساده‌تر تبدیل شده، تفاوت محدود را همراه اثر آن و acceptance_ref انسانی ثبت کنید. فقط رکورد صریح ACCEPTED می‌تواند INTEROPERABLE_WITH_KNOWN_DIFFERENCES را پشتیبانی کند؛ تا وقتی پذیرش در انتظار است، تقدم قطعی به HOLD می‌رسد.

نکتهٔ کلیدی: عددهای این مثال استاندارد glTF یا budget عمومی وب نیستند؛ فقط contract همین fixture هستند.

پنج شکست رایج

۱. «باز شد، پس interoperable است»

یک viewer ممکن است file را parse کند ولی material feature، animation، transform یا unit semantics را ناقص مصرف کند. اصلاح: capability + downstream behavior + round-trip را جدا ثبت کنید.

۲. «همهٔ assetها باید زیر یک triangle budget باشند»

offline film، mobile AR و web product viewer constraints یکسان ندارند. اصلاح: budget را از delivery target بگیرید، نه از عدد مشهور یا تجربهٔ پروژهٔ قبلی.

۳. «Extension رسمی یعنی همه پشتیبانی می‌کنند»

registry رسمی بودن extension را توضیح می‌دهد، نه support هر consumer را. اصلاح: target support matrix را شواهد مستقل نگه دارید. [GLTFREGISTRY]

۴. «Optimization یعنی file size کمتر»

ممکن است size کم شود اما texture memory، draw count یا quality رفتار بدتر شود. اصلاح: هر optimization را به cost metric + semantic/quality check جفت کنید.

۵. «USD یا glTF را انتخاب کنیم و مسئله حل است»

این formatها نقش‌های متفاوتی دارند و consumer support تعیین‌کننده است. اصلاح: format را بعد از target/use-case انتخاب کنید و known unsupported features را صریح نگه دارید.

پل باتجربه: یک source، چند delivery variant

در pipeline واقعی ممکن است یک high-fidelity source asset داشته باشید و چند variant تحویل تولید کنید: web، mobile، desktop realtime و DCC interchange. اشتباه رایج این است که یکی از variantها را source-of-truth اعلام کنید و بعد هر target را از روی آن زنجیره‌ای تبدیل کنید. هر تبدیل اضافه drift و provenance پیچیده‌تر ایجاد می‌کند.

یک الگوی امن‌تر:

1. source-of-truth و provenance را جدا قفل کنید؛
2. برای هر target، delivery contract مستقل بسازید؛
3. optimization recipe و tool version را version کنید؛
4. هر variant را مستقیم با target خودش validate کنید؛
5. تفاوت‌های target-specific را به‌عنوان defect عمومی جا نزنید؛
6. اگر change در source رخ داد، affected variants را requalify کنید.

در این مدل INTEROPERABLE claim همیشه نسبت به target و version مشخص معنا دارد، نه نسبت به «دنیا».

glTF، OpenUSD و انتخاب format

glTF

برای runtime asset delivery طراحی شده و core scene/mesh/material/transform/animation semantics و extension mechanism دارد. برای web/realtime معمولاً گزینهٔ مهمی است، اما extension support و renderer behavior باید در target واقعی بررسی شود. [GLTFSPEC] [GLTFREGISTRY]

OpenUSD

برای scene description و interchange/composition در pipelineهای DCC/film قدرت زیادی دارد. specificationهای رسمی Core، UsdPreviewSurface و USDZ مسیرهای متفاوتی از scene composition تا preview material و packaged delivery را پوشش می‌دهند. این به معنی support کامل همهٔ features در همهٔ consumerها نیست. [OPENUSD]

دو-فرمتی یا چند-variant

گاهی source/interchange در USD و runtime delivery در glTF منطقی‌تر است. هزینهٔ آن conversion کنترل‌ها، mapping rules و validation بیشتر است. تصمیم زمانی دفاع‌پذیر است که هر مرز تبدیل شواهد مستقل داشته باشد.

هیچ «format برندهٔ همیشگی» وجود ندارد. trade-off را با target، editability، composition، runtime constraints، material fidelity، animation و tool support ببندید.

تمرین هدایت‌شده و مستقل

تمرین هدایت‌شده — Baseline Web Delivery

lab را با مرجع پایدار lab://D3D-004/D3D-004-LAB1 باز کنید. در راهنمای learner، از fixtures/baseline_observations.json استفاده کنید، evidence/evidence_pack.template.json را کپی کنید و فقط از مشاهده‌های موجود پر کنید. اگر شواهد تصمیم‌ساز وجود ندارد، حدس نزنید؛ missing_decisive_evidence را پر کنید و تقدم وضعیت اصلی را به‌کار ببرید.

سپس اجرا کنید:

python run_checks.py evidence/my_pack.json

checker درستیِ خودِ مشاهده‌ها را تأیید و asset را تصویب نمی‌کند؛ فقط ساختار/دامنهٔ داده و سازگاری وضعیت اعلام‌شده با تقدم قطعیِ منتشرشده را از روی شواهد قابل مشاهده بررسی می‌کند.

Mutation 1 — Budget cut

در fixture مربوط، triangle و texture-memory budget نصف شده‌اند. baseline verdict را کپی نکنید. مشخص کنید کدام کنترل‌ها با target جدید نامعتبر می‌شوند، minimal اصلاح چیست و آیا quality شواهد دوباره لازم است.

Mutation 2 — Unsupported material extension

یک material feature به KHR_materials_clearcoat وابسته شده، در حالی که capability profile target آن را پشتیبانی نمی‌کند. یکی از مسیرهای اصلاح/variant/target-specific را انتخاب و دلیل را ثبت کنید. اینکه extension ratified است، support target را ثابت نمی‌کند.

Mutation 3 — Round-trip semantic drift

از mutation_roundtrip_semantic_drift.json استفاده کنید: target همچنان asset را load می‌کند، اما transform یک node پایدار پس از round-trip از tolerance اعلام‌شده عبور می‌کند. وضعیت را دوباره محاسبه کنید و مشخص کنید پس از repair کدام شواهد باید دوباره اجرا شوند؛ verdict آماده در fixture وجود ندارد.

Independent transfer — Offline USD-centric film pipeline

asset دوم realtime triangle budget ندارد، اما composition/material interchange سخت‌گیرانه است. budget matrix را از نو بسازید. اگر triangle ceiling دیگر decisive نیست، آن را فقط به دلیل وجود در baseline نگه ندارید. در عوض composition، material representation، referenced assets، transform/scale و downstream DCC checks را شواهد کنید.

چه زمانی بستهٔ شواهد قابل قبول است؟

پیش از وضعیت نهایی این سؤال‌ها باید جواب قابل audit داشته باشند:

1. target و version/capability profile مشخص است؟
2. همهٔ budgetها قبل از judging نوشته شده‌اند و observed values جدا هستند؟
3. format/version و required/used extensions ثبت شده‌اند؟
4. unit/coordinate/transform checks وجود دارند؟
5. material و downstream behavior فقط از screenshot حدس زده نشده‌اند؟
6. round-trip و downstream check جدا هستند؟
7. quality delta با threshold همان پروژه مقایسه شده است؟
8. unsupported features/known differences پنهان نشده‌اند؟
9. provenance ref صریح است؟
10. وضعیت نهایی از شواهد قوی‌تر نیست؟

Machine checker می‌تواند consistency را بررسی کند؛ human reviewer هنوز باید target suitability، acceptance of known differences و release authority را تأیید کند.

ارزیابی و انتقال

برای پاس‌شدن، learner باید پنج نوع شواهد ارائه کند:

• Retrieval: توضیح دهد چرا successful export با interoperability یکی نیست و یک non-goal این درس را نام ببرد.
• Application: 3D Delivery Budget and Interoperability Validation Pack v1 را برای baseline fixture کامل کند.
• Diagnosis: بعد از نصف‌شدن triangle/texture budgets، invalidated fields و اصلاح path را مشخص کند.
• Decision: اگر required extension در target پشتیبانی نمی‌شود، وضعیت را بیش از شواهد مثبت نکند.
• Transfer: برای offline USD-centric pipeline، کنترل‌ها را از target جدید بازسازی کند و budget realtime را کورکورانه کپی نکند.

Blocking misconception: «Blender export موفق بوده و فایل جای دیگری باز شده؛ پس interoperability ثابت است.» اگر این گزاره بدون target-specific شواهد پذیرفته شود، assessment fail است.

آخرین شواهد این درس خودِ pack، lab checks، known-difference/provenance record و transfer decision است. همین‌ها مرز تکمیل این درس را می‌سازند؛ هیچ‌کدام به‌تنهایی مجوز release یا اثبات interoperability خارج از target اعلام‌شده نیستند.

منابع و freshness

• [GLTFSPEC] Khronos glTF 2.0.1 Specification — semantics هستهٔ asset/scene/mesh/transform/material و extension mechanism. foundational/stable.
• [GLTFREGISTRY] Khronos glTF Registry — در refresh تاریخ 2026-09-06، major version جاری را 2.0 معرفی می‌کند و registry extensionها را نگه می‌دارد. practice-evolving.
• [OPENUSD] OpenUSD Specifications — index رسمی specificationهای USD Core، UsdPreviewSurface و USDZ. practice-evolving.
• [BLENDERLTS] Blender LTS — در refresh تاریخ 2026-09-06، Blender 5.2 LTS و 4.5 LTS را maintained معرفی می‌کند. این فقط tool-baseline context است؛ LTS بودن هیچ asset یا add-on را production-ready نمی‌کند.

Freshness این درس TOOL_VOLATILE است. claimهای evolving باید حداکثر تا 2026-10-18 یا زودتر در صورت تغییر معنی‌دار registry/tool/spec recheck شوند. هیچ refreshی نباید Golden package را silent rewrite کند؛ تغییر مستلزم requalification/version جدید است.