بهینه‌سازی کتابخانه رویت فقط حذف فایل نیست

حجم فایل رویت یک نشانه است، نه تشخیص مشکل. دو دفتر ممکن است کتابخانه‌هایی با حجم کاملاً متفاوت داشته باشند و تجربه‌ای برعکس یکدیگر داشته باشند. آنچه مشکل را پیش‌بینی می‌کند، تعداد فمیلی‌هایی است که وزن غیرضروری دارند: هندسه‌ی CAD واردشده‌ای که بازسازی نشده، فمیلی‌هایی با چند لایه‌ی تودرتو و پارامترهایی که کاربردی ندارند، اما در هر ریجنریت دوباره محاسبه می‌شوند.

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

همه‌ی راهنماهای معتبر درباره‌ی عملکرد رویت از یک نقطه شروع می‌کنند: اجرای Purge Unused، آن هم بیش از یک‌بار. مرحله‌ی اول، فمیلی‌ها، تایپ‌ها و متریال‌هایی را که هیچ نمونه‌ای در مدل ندارند حذف می‌کند. مراحل بعدی مواردی را پاک می‌کنند که پس از مرحله‌ی اول آزاد شده‌اند، زیرا حذف یک فمیلی ممکن است فمیلی تودرتوی زیر آن را نیز بی‌استفاده کند.

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

بیشتر کتابخانه‌ها به دلیل کار داخلی نامرتب نشده‌اند، بلکه به دلیل فایل‌هایی که از سایت تولیدکنندگان یا سایت‌های محتوای رایگان دانلود شده‌اند و به دلیل کمبود زمان، بدون بررسی مستقیماً در پروژه بارگذاری شده‌اند. فمیلی‌های دانلودی رایج‌ترین منبع هندسه‌ی اضافه، فرمول‌هایی که به پارامترهای حذف‌شده ارجاع می‌دهند و Object Styles ناسازگار با استاندارد دفتر هستند.

هر فمیلی دانلودی را تا زمانی که جداگانه باز، بررسی و پاک‌سازی نشده، تأییدنشده در نظر بگیرید، نه در همان پروژه‌ای که فوراً به آن نیاز داشت. پیش از ورود به کتابخانه‌ی مشترک، هندسه را بررسی کنید، پارامترهای تایپ بی‌استفاده را حذف کنید و متریال‌هایی را که روی By Category تنظیم نشده‌اند اصلاح کنید. فمیلی‌ای که از این مرحله عبور نکند، بعدها هزینه‌ی اصلاح بیشتری نسبت به پاک‌سازی در روز اول دارد.

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

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

فمیلی‌ها معمولاً اولین مورد بررسی هستند، اما تنها عامل نیستند. در همین بازبینی این موارد را نیز بررسی کنید:

• هشدارها (Warnings) که رسیدگی نشده و انباشته شده‌اند؛ هرکدام یک مشکل حل‌نشده است که رویت آن را نگه می‌دارد.
• ویوتمپلیت‌ها و ویوهای بی‌استفاده که پروژه را شلوغ می‌کنند و ممکن است بدون اطلاع کسی، تنظیمات را تغییر دهند.
• تصاویری که با وضوح کامل بارگذاری شده‌اند و در مدل کوچک شده‌اند؛ رویت فایل کامل را نگه می‌دارد.
• فمیلی‌های In-Place در جایی که باید از فمیلی قابل‌استفاده‌ی مجدد استفاده می‌شد.
• فایل‌های CAD واردشده در جایی که Link یا هندسه‌ی بومی کافی بود.

هیچ‌کدام از این موارد به‌تنهایی مشکل بزرگی ایجاد نمی‌کند، اما مجموع آن‌ها تفاوت میان مدلی است که سریع باز می‌شود و مدلی که باز شدنش زمان زیادی می‌برد.

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

این استاندارد لازم نیست پیچیده باشد و سه مورد برای آن کافی است:

• یک الگوی ثابت نام‌گذاری که دسته و نوع را مشخص می‌کند.
• ساختار پوشه‌ای که با روش واقعی جست‌وجوی افراد هماهنگ است، نه با روند اتفاقی رشد کتابخانه.
• یک نفر یا یک تیم که مسئول تأیید فمیلی‌های جدید پیش از ورود به کتابخانه‌ی مشترک است.

این همان پایه‌ای است که هر پروژه‌ی ساخت فمیلی رویت از آن شروع می‌شود، چه فمیلی‌ها جدید باشند و چه بازسازی شوند.

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

در این مرحله درباره‌ی دامنه‌ی کار واقع‌بین باشید. اگر فقط چند فمیلی محدود دارید و کسی از حجم فایل شکایتی ندارد، به مشاور نیازی نیست، از جمله ما؛ ابتدا Purge Unused را اجرا کنید و فایل را با گزینه‌ی Compact File ذخیره کنید. کمک بیرونی برای کتابخانه زمانی لازم است که کتابخانه میان یک تیم مشترک است، مشکل اصلی خود استاندارد است و مجموعه‌ای از فمیلی‌های پراکنده، اصلاح تدریجی را از بازسازی کندتر می‌کند.

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

• سطح جزئیات (Detail Level) برای پنهان‌سازی. هندسه‌ی ریز، مانند دستگیره‌ها، پیچ‌ها و پروفیل‌های تزئینی، فقط به سطح Fine اختصاص داده شود تا نماهای Coarse و Medium نیازی به ترسیم آن نداشته باشند.
• Symbolic Lines برای نماهای پلان. نماد پلانی که با Symbolic Lines و Masking Region ترسیم شده، از برش هندسه‌ی کامل سه‌بعدی سبک‌تر و خواناتر است و مطابق استاندارد دفتر چاپ می‌شود.
• آرایه، Void و فمیلی‌های تودرتو فقط در جای ضروری. هرکدام از این موارد، در هر بار به‌روزرسانی هندسه‌ی فمیلی، محاسبات بیشتری ایجاد می‌کند. فمیلی تودرتویی که هرگز به‌تنهایی در اسکجوال شمارش یا جایگزین نمی‌شود، معمولاً بهتر است مستقیماً در فمیلی میزبان مدل شود.

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

فایلی که در نسخه‌ی جدیدتر رویت ذخیره شده، در نسخه‌ی قدیمی‌تر باز نمی‌شود و فمیلی‌ای که در نسخه‌ی قدیمی‌تر ساخته شده، هر بار که در پروژه‌ای با نسخه‌ی جدیدتر بارگذاری شود، ارتقا پیدا می‌کند. در نتیجه، وقتی کتابخانه در نسخه‌ی قدیمی باقی می‌ماند، زمان ارتقا در هر پروژه و برای هر عضو تیم دوباره صرف می‌شود و نسخه‌های ارتقایافته به‌جای کتابخانه، در فایل‌های پروژه پراکنده می‌شوند.

راه‌حل، یک قاعده‌ی ساده است: هنگام انتقال دفتر به نسخه‌ی جدید رویت، کل کتابخانه یک‌بار ارتقا داده شود، نمونه‌ای از فمیلی‌های ارتقایافته در یک پروژه‌ی آزمایشی تست شود و کتابخانه‌ی نسخه‌ی قبلی، برای پروژه‌هایی که در همان نسخه ادامه پیدا می‌کنند، به‌صورت فقط‌خواندنی (Read-only) نگه داشته شود. نسخه‌ی هر پوشه باید از نام آن مشخص باشد تا کسی فمیلی را از پوشه‌ی اشتباه بارگذاری نکند.

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

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

ابزارهای بررسی دسته‌ای زمانی ارزش استفاده دارند که کتابخانه به اندازه‌ی کافی مرتب باشد تا نتیجه‌ی آن‌ها معنادار شود. کنترل‌کننده مدل با چک‌ستی بر اساس قواعد دفتر شما قدم بعدی است؛ اجرای آن روی کتابخانه‌ای نامرتب فقط فهرست بلندی تولید می‌کند که کسی بر اساس آن اقدام نمی‌کند.

یک بازه‌ی زمانی ثابت تعیین کنید؛ اجرای فصلی برای یک دفتر پرکار پیش‌فرض مناسبی است و در هر نوبت، سه مورد را بررسی کنید:

1. فمیلی‌های جدید بر اساس استاندارد نام‌گذاری و Object Styles.
2. حجم فایل‌ها در مقایسه با حد مجاز هر فمیلی.
3. تایپ‌های تکراری که دوباره به کتابخانه وارد شده‌اند.