כמעט כל מדריך רוויט מזכיר משפחות (Families) כבר בעשר הדקות הראשונות, וכמעט אף אחד מהם לא עוצר להסביר מה זו בעצם משפחה ולמה ההבחנה הזו חשובה. הפער הזה מתגלה מאוחר יותר, בדרך כלל כקיר - מודליסט שיודע להציב דלת אבל לא יודע לבנות אחת, או לתקן אחת שמתנהגת מוזר בשטח.

משפחות הן לא נושא צדדי ברוויט, הן החומר שממנו רוויט עשויה. קירות, דלתות, ריהוט, מידות, ואפילו המפלסים והצירים שרצים דרך פרויקט - כולם משפחות מתחת למכסה המנוע. הבנה של איך הן עובדות היא הקפיצה הגדולה ביותר בין "יודע לצייר ברוויט" לבין "יודע לעבוד ברוויט".

מה זו בעצם משפחה

משפחה היא מיכל של גאומטריה ונתונים: צורה, מידות, חומרים, וכל מידע מותאם אישית שהפרויקט צריך, ארוזים יחד בהגדרה אחת שניתנת לשימוש חוזר. מציבים עשרה מופעים של אותה משפחת דלת במודל, ומקבלים עשרה עותקים של הגדרה אחת - לא עשרה אובייקטים נפרדים. משנים משהו במשפחה, וכל מופע ששותף לה מתעדכן בבת אחת. ההתנהגות הזו היא בדיוק מה שהופך את רוויט למסד נתונים עם תצוגה תלת-ממדית מחוברת, ולא לתוכנת שרטוט - וזה בדיוק אותו מנגנון שהמדריך "מה זה BIM?" של האתר מתאר ברמת המתודולוגיה: משפחה היא המקום שבו הרעיון הזה באמת חי בתוך התוכנה.

שלושת סוגי המשפחות

כל אלמנט בפרויקט רוויט שייך לאחת משלוש קטגוריות משפחה, וההבדל ביניהן חשוב הרבה יותר ממה שרוב המתחילים מניחים.

משפחות מערכת (System Families) מובנות בתוך רוויט עצמה: קירות, רצפות, גגות, תקרות, מדרגות, והגדרות פרויקט כמו מפלסים וצירים. אי אפשר לשמור משפחת מערכת לקובץ נפרד או לטעון אחת ממקום אחר - אפשר רק לשכפל סוג קיים בתוך פרויקט ולערוך את הפרמטרים שלו. זה מכוון: אלה האלמנטים שרוויט צריכה עליהם שליטה עמוקה ומובנית כדי לשמור על עקביות המודל.

משפחות נטענות (Loadable Families) חיות בקבצי rfa. חיצוניים ונטענות לפרויקט לפי הצורך: דלתות, חלונות, ריהוט, ארונות, אביזרים, צמחייה, ורוב התוכן ה"נרכש ומותקן" במבנה. כאן קורית כמעט כל עבודת בניית המשפחות המותאמות אישית, וכאן חיה ספריית התוכן של חברה.

משפחות In-Place נבנות ישירות בתוך פרויקט בודד עבור פיסת גאומטריה חד-פעמית - דלפק קבלה יוצא דופן, מדרגה פיסולית, קרניז מותאם אישית שלא יחזור על עצמו במקום אחר. משפחות In-Place שימושיות, אבל הן גם הכלי הכי לא נכון בשימוש ברוויט: כל משפחת In-Place חיה רק בפרויקט הזה (אי אפשר להשתמש בה שוב, לכמת אותה בצורה נקייה בין פרויקטים, או לשתף אותה דרך ספרייה), ושימוש כבד ב-In-Place הוא אחת הסיבות הנפוצות ביותר לכך שמודל נהיה איטי וקשה לתאם. כלל אצבע שכדאי להפנים מוקדם: אם פיסת גאומטריה עשויה לחזור על עצמה, או צריכה להופיע בטבלה עם נתונים אמיתיים, כמעט תמיד המקום שלה הוא במשפחה נטענת.

בתוך עורך המשפחות

משפחות נטענות ו-In-Place נבנות שתיהן בעורך המשפחות (Family Editor), סביבת עריכה נפרדת מהפרויקט הראשי. כמה מושגים נושאים שם את רוב המשקל:

  • קטגוריית משפחה - קובעת איך המשפחה מתנהגת ומוכמתת (משפחת דלת חייבת להיות בקטגוריית Doors כדי לארח פתח בקיר ולהופיע בטבלת דלתות). נבחרת כשמתחילים מתבנית משפחה, ולא כדאי לשנות אותה בקלות ראש בהמשך.
  • מישורי ייחוס וקווי ייחוס (Reference Planes/Lines) - הפיגום הבלתי נראה שהגאומטריה ננעלת אליו. בניית הפיגום הזה נכון לפני שרטוט הגאומטריה היא מה שגורם למשפחה "לזוז" נכון כשהפרמטרים שלה משתנים; קפיצה ישר לגאומטריה היא הסיבה הנפוצה ביותר למשפחה שנשברת כששנים את הגודל שלה.
  • סוגי משפחה (Family Types) - קבוצת הווריאציות בעלות השם שמשפחה בודדת מציעה (משפחת דלת עשויה להציע סוג "36x84" וסוג "30x80"), כל אחד עם ערכי הפרמטרים שלו, כשכולם חולקים הגדרה גאומטרית בסיסית אחת.
  • הגדרות נראות (Visibility) - שולטות אם חלקים מהגאומטריה מופיעים בתוכנית, בתלת-ממד, או ברמת פירוט גסה מול עדינה, כך שמשפחה נראית מתאימה בכל קנה מידה במקום להעמיס פרטי אביזרים על תוכנית בקנה מידה קטן.

פרמטרים: Type מול Instance

פרמטרים הם מה שהופך משפחה ליותר מגאומטריה סטטית, וקבלת ההחלטה הנכונה בין Type ל-Instance היא ההחלטה המשמעותית ביותר בבניית משפחה.

פרמטר Type חל על כל המופעים של אותו סוג משפחה בבת אחת - משנים אותו בדלת אחת מ"סוג 36x84", וכל דלת מאותו סוג בפרויקט מתעדכנת. פרמטר Instance חל רק על העותק הבודד שעורכים, ומאפשר לכל מופע מוצב להשתנות באופן עצמאי (כיוון פתיחת דלת, או סיבוב של פריט ריהוט, הם פרמטרי Instance טבעיים; רוחב המשקוף של הדלת כמעט תמיד לא).

ככלל, ברירת המחדל צריכה להיות פרמטרי Type - הם נותנים יותר שליטה על עקביות וניתנים לחיבור זה לזה בנוסחאות. פונים לפרמטר Instance רק כשעותקים בודדים באמת צריכים להשתנות. אילוץ אמיתי שכדאי לתכנן סביבו: נוסחאות יכולות לקשר רק פרמטרי Type לפרמטרי Type אחרים, ופרמטרי Instance לפרמטרי Instance אחרים - ערבוב בין השניים בתוך נוסחה לא עובד, כך שההחלטה בין Type ל-Instance צריכה להתקבל לפני שמתחילים לכתוב נוסחאות, לא אחרי.

פרמטרים משותפים (Shared Parameters) פותרים בעיה אחרת: פרמטר שמוגדר פעם אחת בקובץ פרמטרים משותפים (קובץ טקסט פשוט שרוב המשרדים שומרים תחת בקרת גרסאות), וכל משפחה או פרויקט יכולים לעשות בו שימוש חוזר - מבטיח את אותו הפרמטר עצמו, לא רק את אותו השם, בכל ספריית התוכן של החברה. זה חשוב כי רק פרמטרים משותפים יכולים להיות גם מתויגים וגם מוכמתים בטבלה - פרמטר שחי רק בתוך משפחה אחת, בלי הגדרת פרמטר משותף מאחוריו, לא יכול להיכנס לטבלה או תגית ברמת הפרויקט. מי שבונה תוכן שמיועד לשימוש חוזר בין פרויקטים צריך להגדיר פרמטרים כמשותפים מהיום הראשון, לא לתקן את זה בדיעבד.

משפחות מקוננות וקטלוגי סוגים

משפחות מורכבות נבנות לעיתים קרובות ממשפחות פשוטות יותר המקוננות בתוכן - משפחת דלת מקוננת עם משפחת פרזול נפרדת, כך שאפשר להחליף פרזול בלי לבנות מחדש את כל הדלת. קינון שומר על כל חלק ניתן לניהול ומאפשר לרכיבים משותפים (ציר, ידית, גוף תאורה בתוך משפחת ריהוט) לחיות ולהתעדכן במקום אחד.

עבור משפחות שמגיעות עם עשרות או מאות וריאציות גודל וקונפיגורציה - קטלוג שלם של קו מוצר של יצרן, לדוגמה - קטלוג סוגים (Type Catalog) (קובץ טקסט נלווה שמפרט את ערכי הפרמטרים של כל סוג) מאפשר למשתמש לטעון רק את הסוגים הספציפיים שהפרויקט באמת צריך במקום כל הווריאציות בבת אחת, ושומר על קובץ הפרויקט רזה יותר.

מעבר למשפחות רגילות: Adaptive Components

עבור גאומטריה שהיא באמת לא סטנדרטית - חופה מרובת פאונים, פאנל חזית פרמטרי שצריך להתפתל ולהימתח לאורך משטח מעוקל - מסגרת המשפחות הרגילה של רוויט נגמרת מבחינת גמישות. Adaptive Components הם סוג משפחה מתקדם יותר, בנוי סביב נקודות אדפטיביות שיכולות להיצמד למשטח או מסלול מארח ולהניע גאומטריה באופן פרוצדורלי - קרוב יותר לתכנון פרמטרי/חישובי אמיתי מאשר משפחה רגילה וקשיחה. זהו כלי מתקדם יותר בכוונה, שכדאי ללמוד ברגע שבניית משפחות רגילות הפכה לטבע שני, לא לפני כן.

איך בונים משפחה נכון

כמה הרגלים מבדילים בין משפחה שמתנהגת בצורה צפויה לבין אחת שנשברת בפעם הראשונה שמישהו משנה את הגודל שלה:

  1. מתחילים מתבנית המשפחה הנכונה. התבנית קובעת את הקטגוריה ואת מישורי הייחוס ברירת המחדל - התחלה מתבנית לא נכונה (תבנית Generic Model עבור משהו שאמור להיות משפחת דלת אמיתית, לדוגמה) גורמת לבעיות שמתגלות הרבה יותר מאוחר.
  2. בונים את פיגום מישורי הייחוס והפרמטרים לפני כל גאומטריה. נועלים מידות למישורי ייחוס, נותנים שם ברור לכל מישור ופרמטר, ורק אז מתחילים למדל.
  3. מכופפים (Flex) את המשפחה כל הזמן תוך כדי בנייה. משנים כל פרמטר לערכי הקיצון שלו תוך כדי עבודה, לא רק בסוף - משפחה שנבדקת רק פעם אחת, אחרי שהיא "מוכנה", נוטה לחשוף את האילוצים השבורים שלה באמצע פרויקט חי במקום בזמן הבנייה.
  4. שומרים על גאומטריה פשוטה כמו שהמקרה מאפשר. פירוט מיותר שלעולם לא ייראה בקנה המידה האמיתי של הדפסת הפרויקט בעיקר מאט את המודל.
  5. מתעדים ונותנים שמות בעקביות. שמות פרמטרים, שמות סוגים, ושמות משפחות שעוקבים אחרי מוסכמת שמות של המשרד הם מה שהופך ספריית משפחות לניתנת לחיפוש ואמינה חודשים אחר כך, לא רק שמישה לשימוש על ידי מי שבנה אותה.

ניהול ספריית משפחות

הערך של משרד בתוכן הרוויט שלו מצטבר עם הזמן, אבל רק אם הוא מאורגן. הנוהגים שמבדילים בין ספרייה שאנשים באמת סומכים עליה לבין אחת שאנשים עוקפים בשקט: מיקום מקור יחיד (לא מפוזר בין תיקיות פרויקטים), מוסכמת שמות וקטגוריזציה שמיושמת בעקביות, שלב סקירה לפני שתוכן חדש נוסף לכלל החברה, וביקורת תקופתית שתופסת משפחות שהתרחקו מהסטנדרטים. זה בדיוק סוג המשאב שספריית המשפחות והתבניות החינמית של האתר קיימת כדי לספק - נקודת התחלה של משפחות בדוקות ועובדות, במקום להתחיל את התוכן של כל פרויקט מתבנית ריקה.

איפה זה נכנס למסלול הלמידה שלכם

משפחות הן שלב 3 בסדר הלמידה שהאתר ממליץ עליו במקום אחר - אחרי שליטה בממשק ומעטפת מודלית בסיסית, ולפני גיליונות ותיעוד. זה השלב שרוב הלומדים העצמאיים מתפתים לדלג עליו במהירות, וזה השלב שקובע אם שאר רוויט "נכנס" למקום או נשאר אוסף של טריקים מנותקים.

אם אתם רוצים לבנות את המיומנות הזו עם משוב אמיתי במקום ניסוי וטעייה על פרויקט חי - בדיוק בשביל זה בנינו את הקורסים שלנו.