استفاده از طراحی برای تغییر در سالیدورک

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

پیگیری مراجع

هدف این تکنیک‌ها این است که به ما کمک کند تا ارجاعات بین فیچرهای یک پارت را سازماندهی کنیم؛ به طوری که بتوانیم تغییراتی ایجاد کنیم که در ابتدا برنامه ریزی نکرده بودیم(و سرانجام در اسمبلی‌ها) بدون اینکه ارجاعات را خراب کند، یا باعث ایجاد خطا شود یا نیاز به تعمیر مدلِ زیادی داشته باشد. مشکل اساسی در اینجا، چرندیاتی است که الگوی مدل‌سازی مبتنی بر تاریخ، دهه‌هاست از آنها چشم‌پوشی کرده است: این الگو، تغییرات در طراحی هوشمند(design intent) را به خوبی مدیریت نمی‌کند. کاربران باتجربه با سناریوی ایجاد یک تغییر به ظاهر ساده و مشاهده روشن شدن FeatureManager با علامت‌های قرمز X و علامت تعجب (که خطاهای زیادی به همراه دارد) آشنا هستند. کاربران همچنین با سعی در حذف یک فیچر کوچک، و اصرار نرم‌افزار که باید ۱۵ فیچر مهم دیگر را نیز با خود حذف کند، آشنا هستند. در اصل، شما باید مراجع خود را پیگیری کنید.اگر روی یک وجه اسکچ بکشید، فیچری که وجه را ایجاد کرده است، به یک مرجع(reference) تبدیل می‌شود. اگر یک گوشه‌ از مستطیل ما لبه‌ای داشته باشد که توسط یک فیلت ایجاد شده باشد، آنگاه این فیلت بخشی از چیدمان والد/فرزندی برای اسکچ اولیه است. همان طور که پارت‌های شخصی شما پیچیده‌تر می‌شوند، نحوه واکنش این مدل‌ها به تغییرات، اهمیت روزافزونی پیدا می‌کند، زیرا هر تغییر می‌تواند به طور بالقوه زمان بیشتری را از شما بگیرد.ما در فصل 20 با موضوع مدل‌سازی درون‌زمینه‌ای(in-context)، درباره‌ی پیامدهای بیش از حد آزاد بودن در رابطه‌های درون‌زمینه‌ای نکات بیشتری را توضیح خواهیم داد. یک چیز این است که مدل‌ها را برای اولین بار به سرعت بسازید. ویرایش‌ها(Edits) باید زمان کمی طول بکشند و و نیازی به دوباره کاری زیاد نداشته باشند. بنابراین چگونه با طراحی برای تغییر، از این سناریوی آخرالزمانی اجتناب می‌کنید؟

تجسم مدل‌سازی افقی

این رویکرد بهتر به روش‌های مختلفی تجسم می‌شود. یک تکینک آن را مدل‌سازی افقی یا روش "درخت گسترده" می‌نامد؛ به طوری که به جای زنجیره‌ای طولانی از فیچرها، ما یک لیست از فیچرها را داریم که همه‌ی آنها مبتنی بر صفحات(planes) و اسکچ‌هاهستند به طوری که تنها یک زوج از والدین وجود دارند(و بدون پدر بزرگ و مادر بزرگ‌ها). قواعد برای این نوع از مدل‌سازی طوری هستند که ارجاع به هندسه‌ی سه‌بعدی مجاز نیست. تنها، ارجاع به اَشکال هندسی مرجع پایدار(stable reference geometry) و اسکچ‌های اولیه(initial) مجاز است. برای دریافت نکات بیشتر درباره‌ی این تکنیک، می‌توانید به این آدرس مراجعه کنید. 

درک مدل‌سازی انعطاف پذیر در سالیدورک

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

مدل‌سازی انعطاف‌پذیر، توسط Richard Gebhard ایجاد شد و او در این آدرس مجموعه‌ای از ویدیوهای آموزشی و اطلاعات دیگر را ارائه داده است. 

استفاده از اسکچ‌های اسکلت

چه می‌شود اگر تعدادی اسکچ و فیچرِ صفحه(plane) داشته باشیم که برای تمرکز دادن کنترل بقیه فیچرها استفاده شوند؟ چه می‌شود اگر هر فیچر، تا حد امکان به فیچرهای اسکلتی(skeleton) مرتبط شود؟ فیچرهایی مانند فیلت، shell و درافت‌های عمدی یا همان زاویه‌های خروج(draft by design)، نیاز به انتخاب از هندسه‌ی سالید دارند اما دیگر فیچرها، از قبیل فیچرهایی که از اسکچ‌ها ایجاد شده‌اند، تنها می‌توانند با رجوع(reference) به این اسکچ‌ها و صفحات اسکلتی اصلی ایجاد شوند. 

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

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

این سناریو همچنین پتانسیل استفاده بهتر از پردازش چند رشته‌ای(multithreaded processing) را دارد زیرا منطق کمتر خطی، و بیشتر موازی است. طراحی مناسب برای تغییر، نظمی است که باید مطمئن شوید با هر مدل، هر روز آن را دنبال می‌کنید.

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