Revit Mythen Titel

Mythos 1: BIM-Objekte müssen parametrisch sein
Als Revit-Einsteiger lernt man eine Eigenschaft der neuen Plattform besonders zu schätzen: ihre Parametrik. Schnell entsteht der Eindruck, dass alles, was nicht parametrisch ist, dem BIM-Gedanken entgegen läuft und damit nicht mehr zeitgemäß ist. Ist das so? Nun, um diese Frage zu beantworten, muss man differenzieren, welche Art von Bauteilen in welcher Leistungsphase betrachtet werden. Wird zunächst mit neutralen Familien entworfen, dann ist eine geeignete Parametrik an Bauteilen wünschenswert. Sind Bauteile dynamisch imstande auf Lage- oder Dimensionsänderungen zu reagieren, dann erlaubt dies eine sehr komfortable Entwurfserstellung. Exakt diese Flexibilität will man aber nicht mehr haben, wenn es darum geht, die Planung zu konkretisieren oder gar herstellerspezifische Bauteile in eine detailliertere Modellierung einzuführen. Spätestens nun kann es als Feature betrachtet werden, wenn die Parametrierung auf konkrete Produkte eingeschränkt wird. Nicht alle Bauteile werden auf Maß gefertigt. Daher macht es Sinn, dass auch nur die Produkte eingezeichnet werden können, die man tatsächlich bestellen kann.

Sinnvolle Parametrik
Wo spielt die Revit-Parametrik ihre Stärken aus? Nun, sie ist immer dann sinnvoll, wenn es möglich ist, ein Modell aufgrund einiger weniger Parameter zu beschreiben. Beispielsweise sind Bögen relativ gut parametrierbar, da es sich dabei um einfache geometrische Körper handelt, die sich anhand weniger Freiheitsgrade modellieren lassen. Auch sind Bögen typische Bauteile, bei denen zum Zeitpunkt der Modellierung die endgültige Dimension oftmals noch nicht klar ist, gewisse Flexibilität zunächst also wünschenswert wäre.

Ein Bogen hat im einfachsten Fall einen Durchmesser, einen Innenradius und einen Winkel. Anhand dieser drei Eingaben lässt sich bereits ein einfacher parametrierter Bogen erstellen. Nun lassen sich nach Belieben weitere Parameter einführen, die es erlauben, z. B. Anschlussstutzen oder Flanschverbindungen bezüglich ihrer Gestalt und Sichtbarkeit zu parametrieren. Ein einfaches Formteil wird so schnell zu einem universell-einsetzbaren Modell. Ansätze wie z. B. die ETIM Modeling Classes oder Revit Fabrication nutzen die Ähnlichkeiten in der Gestalt einzelner Bauteile, um so durch Eingabe einiger Dimensionen und Winkel ein für Planungszwecke ausreichend detailliertes Bauteil anhand von Schablonenobjekten zu beschreiben.

Grenzen der Parametrik
Parametrik kann auch zweckentfremdet werden. Dies wird in einem hinreichend großen Modell schnell für Ärger sorgen, denn schlechte Parametrik macht Modelle träge. In den meisten Fällen trifft man solch teure Parametrik dort an, wo möglichst viele Produkte einer Serie in einer Familie abgebildet werden sollen, diese sich aber je Produktvariante geometrisch so stark unterscheiden, dass keine einfache parametrische Gestaltbeschreibung gefunden werden kann. In diesem Fall trifft man oft auf eines der beiden folgenden Muster.

Die eierlegende Wollmilchsau
Zunächst einmal gibt es die Art Familie, bei der verzweifelt versucht wird, anhand unzähliger Parameter die nötigen Freiheitsgrade zu schaffen. Diese Familien sind, sofern Sie ihren Zweck erfüllen, zunächst einmal nicht problematisch. Allerdings beobachtet man bei der Migration auf neuere Revit-Versionen in einigen Fällen Konvertierungs-Probleme, falls zu komplexe Parametrik eingesetzt wurde. Auch erzeugt jede parametrische Abhängigkeit kleine Rechenaufwände, wenn Revit die entsprechenden Modellabschnitte regenerieren muss. Diese kleinen Beiträge können sich in großen Vorhaben zu einem zu komplexen Geflecht aus Abhängigkeiten aufsummieren.

Wird eine Parametrierung für einen Bauteiltypen zu komplex, kann es sich lohnen, nach Familien-Konfiguratoren Ausschau zu halten, die anhand weniger Benutzervorgaben eine passgenaue Familie erzeugen können. In der LINEAR-Welt werden solche Konfiguratoren u. a. für Behälter, zentrale Lüftungseinheiten oder Verteiler angeboten. Die resultierenden Familien sind schlank, auf das Wesentliche begrenzt und können mit komfortablen Eingabemasken erzeugt bzw. modifiziert werden.

Die Matroschka
Vereinzelt trifft man in der Praxis auch auf ein anderes Muster, welches wir der Anschaulichkeit halber als „Matroschka“-Familie bezeichnen möchten. In dieser Modellierungstechnik wird dem Anwender eine parametrische Produktfamilie vorgegaukelt, tatsächlich wird aber die Geometrie der abgebildeten Produkte redundant in sämtlichen Ausprägungen vorgehalten. Die Geometrie eines konkreten Typen wird nun über einen Satz Sichtbarkeits-Parameter gesteuert, der dafür sorgt, dass nur die gewünschte Geometrie angezeigt und alle anderen verborgen werden. Auch dies funktioniert, jedoch werden hier die Modelle um möglicherweise niemals genutzte Daten aufgebläht. Auch die Bereinigung nicht verwendeter Typen hat – im Gegensatz zu mehreren statischen Familien – bei einer „Matroschka“-Familie keine Chance, das Modell zu entlasten, da nur die Typdefinitionen (d. h. der Satz nötiger Ja/Nein-Parameter) entfernt werden können, nicht jedoch die redundant vorgehaltene Geometrie.

Fazit
Bauteilfamilien in Revit dürfen, müssen aber nicht zwangsweise parametrisch sein. Parametrik ist wichtig und gut, um Ähnlichkeitseffekte auszunutzen oder um eine gewisse Flexibilität in der Entwurfsphase zu ermöglichen. Sobald herstellerspezifische Bauteile betrachtet werden, der geometrische Entwicklungsgrad also erhöht wird, ist es vorteilhaft Familien einzusetzen, die entweder das eine konkrete Bauteil beschreiben oder sich über einen überschaubaren Satz von Parametern in die geforderte Gestalt bringen lassen.

Mythos 2: DWGs in Familien sind unbedingt zu vermeiden
In einigen Modellierungs-Guidelines wird empfohlen, lediglich Revit-native Familien einzusetzen, am besten sogar nur solche, die man selbst erzeugt hat. Die Einbettung von DWG-Blöcken gilt geradezu als verpönt. Besonders Herstellerfamilien seien noch dazu oft hoffnungslos veraltet und enthielten Fehler. Von dem puristischen Ansatz, jede Familie selbst zu erzeugen, wird jedoch meist nach einiger Zeit abgerückt. Spätestens, wenn sich herausstellt, dass die eigenen Konstrukteure auch nur mit Wasser kochen, die Familienerzeugung massiv Ressourcen bindet und man am Ende mit dem verfügbaren Content aus vertrauenswürdigen Quellen dennoch ganz gut fährt, selbst wenn ein Teil der verfügbaren Familien dem Anspruch auf DWG-Freiheit nicht gerecht werden kann.

Über die Performance eingebetteter DWGs
Eingebettete DWGs leiden im Wesentlichen darunter, dass die Assoziation mit einer der beliebtesten Todsünden unter Revit-Anwendern naheliegt: einer übermäßigen Verwendung eingebetteter DWG-Zeichnungen in Revit-Projekten. Schlimmer wird es nur noch, wenn man diese CAD-Modelle gar in einzelne Objekte auflöst. Die Fähigkeit, DWG-Zeichnungen als Unterlage zu verwenden, ist zweifelsohne ein wichtiger Baustein für den Umstieg von AutoCAD zu Revit, beispielsweise in Modernisierungsprojekten. Werden die Zeichnungen hier nicht verknüpft, sondern eingebettet und anschließend nicht aus den Modellansichten entfernt, kann bisweilen die Performance darunter leiden. Auf die Frage, was aber nun an eingebetteten DWGs in Familien so problematisch sein soll, werden folglich oftmals reflexartig Performance und Speicherbedarf als Argumente genannt. Aber teilen DWGs in Revit-Familien diese unschönen Eigenschaften überhaupt, die ihnen auf Projektebene durchaus zu Recht zugeschrieben werden?

Zunächst einige Grundlagen: Revit-Familien bringen eine gewisse Datenmenge mit sich; die minimal erreichbare Größe für leere Familiendateien liegt bei etwa 300-400 KB. Entscheidend ist nun, wie groß die zusätzliche Datenmenge ist, die benötigt wird, um das eigentliche Bauteil zu modellieren, sowie der Aufwand, der nötig ist, um es darzustellen. Bis auf wenige Ausnahmen sollten RFA-Dateien eigentlich niemals die Marke zu einem Megabyte überschreiten müssen. Aufgrund des Familie-Exemplar-Prinzips in Revit gilt aber nun glücklicherweise bezogen auf die reine Dateigröße der Grundsatz „Familien sind teuer, Exemplare billig“, weswegen die Dateigröße des Projekts sich als Mischkalkulation aus Familien und deren Exemplaren ergibt. Auch hier machen DWG-Familien keine Ausnahme, wie wir im Folgenden anhand leicht nachvollziehbarer Beispiele belegen möchten.

Viele gleiche Elemente
Das erste Experiment gestaltet sich wie folgt: Wir erzeugen in einem ansonsten leeren Revit-Projekt durch sukzessive Kopiervorgänge viele Exemplare einer einzelnen DWG-Familie (hier eine FKU90-Brandschutzklappe des Wildeboer-Katalogs 06/2021) und protokollieren in jedem Verdopplungsschritt den benötigten Festplattenspeicher, den benötigten Arbeitsspeicher nach Projektöffnung sowie die Zeit, die eine Ansichtserstellung (3D ohne Schnittbereich mit verdeckten Linien) in den Detailgraden grob, mittel und fein benötigt.

Während nun der initiale Einfüge-Vorgang das Projekt um etwa 140 kB vergrößert, wird jedes weitere Exemplar in der Projektdatei mit etwa 120 Byte codiert, wohingegen es zur Laufzeit im Arbeitsspeicher mit etwa 3 kB zu Buche schlägt. Dieser Fußabdruck vergrößert sich natürlich mit jedem Exemplar-Parameter, der angelegt und gefüllt wird, sodass in realen Projekten mit einer etwas höheren Speicherlast pro Exemplar gerechnet werden muss. Bezüglich der Performance lässt sich feststellen, dass der Aufwand für eine Ansichtserzeugung sich asymptotisch linear mit der Anzahl darzustellender Elemente entwickelt, was erwartungsgemäß ist. Nun ist dieses konstruktive Beispiel mitnichten repräsentativ für ein reales Projekt. Allerdings lässt sich mit diesem einfachen Experiment dennoch sehr eindrucksvoll zeigen, dass viele Exemplare einzelner DWG-Familien keine nennenswerten Auffälligkeiten in der Ressourcenauslastung zeigen.

Viele verschiedene Elemente
Nun, da klar ist, dass nicht die Zahl der Elemente, sondern die Zahl der dahinterliegenden Familien die Projektgröße beeinflusst, schauen wir uns in einem zweiten Experiment an, wie die Speicherauslastung sich abhängig von der Anzahl einzelner DWG-Familien im Projekt verhält. Wir zeichnen daher mit dem LINEAR CAD-Browser 256 zufällig ausgewählte Familien verschiedener Hersteller und Produktgruppen in ein leeres Revit-Projekt ein und protokollieren die Speicherlasten.

Es lässt sich beobachten, dass der reservierte Hauptspeicher des Revit-Prozesses sich weitestgehend unbeeindruckt zeigt. Erst ab 64 verschiedenen Familien im Projekt bemerkt man einen leichten Anstieg. Die Projektgröße skaliert erwartungsgemäß linear mit der Anzahl der Familien im Projekt, wobei der durchschnittliche Speicherbedarf im Projekt etwa 300 KB pro Familie beträgt. Der nötige Arbeitsspeicher hingegen kann im Mittel mit etwa 1,2 MB pro verwendeter Familie abgeschätzt werden. Nun ist es so, dass die meisten Familien nicht bloß einmal im Projekt verwendet werden. Daher erweitern wir dieses Experiment, indem wir die 256 Familien wie zuvor sukzessive verdoppeln und erneut den Speicher sowie die Aufwände für Ansichtserstellung beobachten.

Auch in diesem Beispiel, welches vom Aufbau schon deutlich näher an reale Projekte heranreicht, lässt sich kein Performancenachteil der DWG-Familien feststellen. Nun ist die Modellgröße im Wesentlichen von der Zahl der Elemente und der enthaltenen Informationsdichte abhängig, weswegen es schwer ist, allgemeine Einschätzungen zu geben. Allerdings unterschreiten die mittleren Kosten pro Exemplar schon bei einer mittleren Wiederholungszahl von vier mit knapp 75 KB auf dem Speichermedium ganz deutlich gängige Faustregeln, nach denen die Projektgröße etwa 100 KB pro Bauteil nicht überschreiten sollte. Ganz zu schweigen davon, dass neben den Produktfamilien viele leichtgewichtige Systemelemente für Leitungen etc. zum Einsatz kommen. Es bleibt also noch ausreichend Platz für zusätzliche alphanumerische Information an den Elementen.

4a

Gibt es auch gute Gründe DWGs einzubetten?
Es ist wohl unbestritten, dass DWGs keine gute Basis sind, wenn man eine parametrische Revit-Familie modellieren möchte. Allerdings gibt es auch Quellformate wie das der VDI 3805, dessen Parametrik sich in der Regel nicht auf die von Revit abbilden lässt und für die man daher rein prinzipiell schon einzelne Familien generieren muss, um den „Matroschka-Effekt“ zu vermeiden. Aus Sicht der Softwareentwicklung ist es also nur vorteilhaft, ein Ausgabeformat zu liefern, da ein Code für alles sich leichter warten und erweitern lässt. Für sich allein genommen hat diese Begründung allerdings noch ein wenig den Anschein einer unzulässigen Abkürzung, die man aus Bequemlichkeit gewählt hat.

Ein viel gewichtigerer Grund für das Festhalten an der DWG-Einbettung ist der, dass Revit die Generierung von geometrischen Körpern mit Kantenlängen unterhalb von 1/32 Zoll (etwa 0,78 mm) ablehnt. Dies lässt sich in der Regel nicht automatisiert beheben und kann daher zu gravierenden Darstellungsfehlern führen. Enthält ein VDI 3805-Modell eine Kante unterhalb dieses Schwellwerts – bewusst oder unbewusst modelliert – so kann die resultierende Geometrie nicht fehlerfrei als Revit-native Familie generiert werden. Hingegen funktioniert die Transformation von VDI 3805 zu DWG nahezu immer reibungslos. Überraschenderweise zeigt sich weiterhin, dass die Geometrien in DWG-Importen in der Regel effizienter gespeichert werden als bei einer Umwandlung in Revit-native Geometrien mithilfe des Auflösen-Features im Familien-Editor. In Stichproben ließ sich zeigen, dass dieser Effekt bis zu 30 % der Gesamtgröße betragen kann, abzüglich des Overheads einer leeren Familie ergab sich in einzelnen Fällen somit eine Steigerung um etwa 100 %.

Fazit DWG Mythos
Die Aussage, dass eingebettete DWGs in Familien zu Problemen führen, kann in ihrer Pauschalität nicht mit Fakten belegt werden. Richtig ist, dass auf diversen Sammelbörsen im Netz Familien auf Basis von viel zu detaillierten Bauteilzeichnungen existieren, die nicht bloß speicherintensiv sind, sondern auch unnötige Rechenzeit in ihrer Handhabung benötigen. 
Hier ist nicht die enthaltene DWG das Problem, sondern der Inhalt ebendieser, der nicht für die Verwendung im Kontext BIM optimiert wurde. Andererseits bietet der Umweg über das DWG-Format aktuell die einzige stabile Möglichkeit, VDI 3805-konforme Geometrien in Revit zu generieren, was diesen Weg alternativlos macht, wenn VDI-Herstellerkataloge in Revit-Familien überführt werden sollen. Wir müssen uns also weniger über den Datencontainer unserer Bauteilfamilien unterhalten, als mehr über die Qualität der eigentlichen Inhalte. Dies bildet eine perfekte Überleitung zu unserem letzten Mythos.
 

Mythos 3: Nur zertifizierte Familien sind gute Familien
Auf der Suche nach geeigneten Bauteilfamilien begegnet dem Revit-Anwender oftmals das Versprechen, dass gewisse Kataloge zertifiziert sind, andere wiederum nicht. Was steckt dahinter? Kann man Familien ohne Zertifikat überhaupt noch trauen?

Nun, es ist wie beim Einkauf von Lebensmitteln auch: Misstrauen Sie unbekannten Quellen, dann machen Sie prinzipiell schon einiges richtig. Entstammt eine Familie einem Online-Sammelbecken, dann sind Sie allein für die Qualitätssicherung zuständig. Bietet dagegen ein Komponenten-Hersteller offizielle Produktkataloge an, ist wichtig, dass dieser auch die abschließende Qualitätssicherung übernimmt und den Bauteilkatalog zur Verwendung in den zu unterstützenden Softwareumgebungen freigibt. Dazu braucht es aber kein Zertifikat, so etwas sollte eigentlich eine Selbstverständlichkeit sein. Kein Joghurt-Hersteller käme auf die Idee, „garantiert essbar“ auf seine Produkte zu schreiben.
Reine Konformitäts-Zertifikate, die ein einzelner Softwarehersteller ausspricht, sind daher bestenfalls als Marketing-Gag zu bewerten, schlimmstenfalls als Dokumentation des eigenen Kontrollverlusts. Schaut man sich die notwendigen Kriterien für eine solche Zertifizierung an, dann bleibt oftmals nur das Versprechen, dass der jeweilige Content Klassifizierungsschlüssel und Attribute für gewisse Anwendungsprogramme besitzt. Was so positiv klingt, bedeutet letztlich, dass die jeweilige Software ihrem Anwender keine einfache Möglichkeit bietet, um mit unbekannten Inhalten umzugehen, geschweige denn, dass diese firmeneigene Standards auf interne Vorgaben mappen kann. Die Aussage „Enthält Kennungen für Software XYZ“ lässt sich als „Software XYZ bietet keinen Klassifizierungsmechanismus“ lesen, ebenso übersetzt sich „Besitzt Attribute für Berechnungsprogramme der Firma XYZ“ schlicht und ergreifend zu „Ihren Firmenstandard bestimmen wir, nicht Sie“. Daher: Wenn Sie in Hochglanzbroschüren sehen, dass Bauteilkataloge zertifiziert sind, fragen Sie sich immer, ob dieses Siegel überhaupt einen Mehrwert für Sie bietet, oder ob ein einzelner Hersteller entlang hausgemachter Limitationen Zertifikate ausspricht.

Abb. 6a
Abb. 6a und 6b: Speicherbedarf und Performance der Ansichtserzeugung in Projekten mit unterschiedlicher Exemplaranzahl

Ob nun ein Gütesiegel für Revit-Familien überhaupt etwas taugen kann, kommt am Ende natürlich auf die Objektivität der dahinterstehenden Kriterien sowie deren transparente Dokumentation an. Objektiv messbare Kriterien wären hier beispielsweise resultierende Datengrößen, die parametrische Komplexität und die Zahl der Facetten, die für eine dreidimensionale Darstellung im bevorzugten Detaillierungsgrad nötig sind. Auch sollte eine gute Familie nicht unnötigerweise mit Abzugskörpern arbeiten sowie – soweit möglich – eine vereinfachte geometrische Darstellung anbieten, bei der unwesentliche Details nicht explizit modelliert werden. Aber auch solch objektiv messbare Größen sagen leider allein für sich genommen noch wenig aus. So benötigen manche Familien wie Rohrzubehör bereits in ersten Entwurfsplänen gewisse Details, damit die Funktion des Bauteils in der Darstellung erkannt werden kann. Andere lassen sich praktisch ohne nennenswerte Verluste für einen Großteil der Anwendungsfälle gegen einen leichtgewichtigen Quader mit Anschlüssen tauschen. Will man also einen Qualitätscheck eingesetzter Familien machen, dann darf man diese nicht aus dem Gesamtkontext lösen und muss sich mit der Bewertung im Spannungsfeld zwischen Kosten und Nutzen für das Gesamtprojekt aufhalten.

Was soll man also tun?
Die Etablierung geeigneter Qualitätsmerkmale für Revit-Familien und eine darauf aufbauende Entwicklung integraler Prüfmechanismen ist eine spannende Frage, auf die es nach bestem Wissen des Autors bislang keine abschließende Antwort gibt. Aus langjähriger Erfahrung können wir Ihnen folgende Hinweise an die Hand geben:

  • Hinterfragen Sie Pauschalaussagen in Guidelines. Revit hat sich in den letzten 10 Jahre weiterentwickelt, öffentlich zugängliche Guidelines oft nicht. Nicht alles, was vielleicht einmal eine Berechtigung hatte, ist in aktuellen Versionen noch relevant.
  • Bereinigen Sie Ihr Modell regelmäßig und optimieren Sie erst, wenn Sie gemessen haben. Es gibt keine technische Besonderheit, die DWG-Familien besonders schlecht skalieren lassen. Vielmehr steckt hinter nahezu jeder unperformanten Familie eine schlechte Modellierung, unabhängig vom Geometriecontainer.
  • Ist nicht Speicher, sondern die generelle Arbeitsperformance das Problem, dann versuchen Sie die Arbeitsansichten möglichst auf den Bereich zu begrenzen, in dem Sie arbeiten wollen. Wählen Sie einen angemessenen Detail- und Darstellungsgrad und deaktivieren Sie die Anzeige der Modellbestandteile, die für Ihre aktuelle Aufgabe nicht relevant sind.

Schlussendlich bleibt nur der eindringliche Hinweis: Vermeiden Sie es, Familien aus Sammelbörsen einzusetzen, wenn Sie sich nicht zutrauen, diese selbst auf Herz und Nieren zu prüfen. Im Rahmen der Recherche sind wir auf einige interessante Lehrstücke gestoßen, wobei der drei Megabyte schwere Rechteck-Flansch (bestehend aus lediglich einem Quader und einem Abzugskörper) besondere Erwähnung verdient hat. Die genannte Familie ist übrigens Revit-nativ. 


Dr. Christian Waluga