ساخت فمیلی پارامتریک رویت، از پارامتر تا تست

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

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

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

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

سه نوع فرمول بیشتر نیازهای واقعی را پوشش می‌دهند:

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

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

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

1. بارگذاری فمیلی در یک پروژه‌ی واقعی، نه فقط در پنجره‌ی ادیتور.
2. رفتار چند نمونه‌ی هم‌زمان با مقادیر متفاوت پارامترها.
3. خوانایی و درستی مقادیر در یک اسکجوال واقعی، نه فقط در پنل ویژگی‌ها.

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

هر فمیلی به منطق پارامتریک پیچیده نیاز ندارد. محصولی که فقط در چند اندازه‌ی ثابت تولید می‌شود، با یک Type Catalog و چند تایپ ثابت بهتر پوشش داده می‌شود تا با فمیلی‌ای که ده پارامتر و پنج فرمول دارد و هرگز خارج از همان چند اندازه استفاده نمی‌شود.

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

سبک‌بودن فمیلی به هندسه نیز بستگی دارد. جزئیاتی که فقط در مقیاس‌های بزرگ دیده می‌شوند، باید در Detail Level مناسب نمایش داده شوند و مش یا فایل CAD واردشده باید با هندسه‌ی بومی رویت جایگزین شود.

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

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