Mythe 1: BIM-objecten moeten parametrisch zijn
Als Revit-nieuwkomer leer je één kenmerk van het nieuwe platform bijzonder waarderen: de parametrisatie. Je krijgt al snel de indruk dat alles wat niet parametrisch is, in strijd is met het idee van BIM en daarom niet meer van deze tijd is. Maar is dat echt zo? Om deze vraag te kunnen beantwoorden, is het nodig om te onderscheiden welk type component in welke planningsfase wordt behandeld. Als eerst generieke families worden gebruikt om te ontwerpen, dan is geschikte parametrisering van componenten wenselijk. Als componenten dynamisch kunnen reageren op veranderingen in positie of dimensie, maken ze een zeer comfortabel ontwerpproces mogelijk. Het is echter precies deze flexibiliteit die niet meer gewenst is wanneer het aankomt op het finaliseren van het ontwerp of zelfs het introduceren van fabrikantspecifieke componenten in een meer gedetailleerd model. Uiterlijk op dit punt kan het als een eigenschap worden beschouwd als de parametrisering beperkt is tot specifieke producten. Niet alle componenten zijn op maat gemaakt. Daarom is het logisch dat alleen producten die daadwerkelijk kunnen worden besteld, kunnen worden ingevoegd.
Nuttige parametrie
Waar toont Revit parametrie zijn sterke punten? Het is zinvol wanneer het mogelijk is om de geometrie van een object te beschrijven op basis van een paar parameters. Bochten zijn bijvoorbeeld relatief eenvoudig te parametriseren, omdat het eenvoudige geometrische lichamen zijn die kunnen worden gemodelleerd met behulp van minder vrijheidsgraden. Bochten zijn ook componenten waarvan de uiteindelijke afmeting vaak nog niet duidelijk is op het moment van modelleren, dus enige flexibiliteit is in eerste instantie wenselijk.
In het eenvoudigste geval heeft een bocht een diameter, een binnenradius en een hoek. Op basis van deze drie specificaties kan al een eenvoudige geparametriseerde bocht worden gemaakt. Nu kunnen naar wens extra parameters worden toegevoegd, waarmee bijvoorbeeld verbindingsstukken of flensverbindingen in vorm en zichtbaarheid kunnen worden geparametriseerd. Een eenvoudige aanpassing wordt al snel een universeel model. Methoden zoals ETIM Modeling Classes of Revit Fabrication gebruiken de overeenkomsten van de vorm voor individuele componenten om een voldoende gedetailleerde geometrie te beschrijven voor ontwerpdoeleinden op basis van sjabloonobjecten door enkele afmetingen en hoeken te definiëren.
Grenzen van parametrie
Parametrie kan ook worden afgeleid van het beoogde doel. Dit zal snel problemen veroorzaken in grotere modellen, omdat slechte parametrische gegevens de prestaties van het model vertragen. In de meeste gevallen komt zo'n dure parametrie voor wanneer een reeks producten binnen één familie moet worden gerepresenteerd, maar de productvarianten geometrisch zodanig verschillen dat er geen gemeenschappelijke parametrische vormbeschrijving kan worden gevonden. In dit geval kom je vaak een van de volgende twee patronen tegen.
Allerleiambachten
Ten eerste is er het soort familie waar wanhopige pogingen worden gedaan om de nodige vrijheidsgraden te creëren op basis van talloze parameters. Deze families zijn, als ze aan hun doel voldoen, in eerste instantie niet problematisch. Echter, bij het migreren naar nieuwere Revit versies zie je in sommige gevallen conversieproblemen als er te complexe parametrische families zijn gebruikt. Ook genereert elke parametrische afhankelijkheid kleine rekeninspanningen wanneer Revit de corresponderende modelsecties moet regenereren. Deze kleine bijdragen kunnen oplopen tot een te complex netwerk van afhankelijkheden in grote projecten.
Als de parametrisatie te complex is voor een componenttype, kan het de moeite waard zijn om op zoek te gaan naar familieconfiguratoren die een op maat gemaakte familie kunnen genereren op basis van minder gebruikersspecificaties. In de LINEAR-wereld worden dergelijke configuratoren aangeboden voor bijvoorbeeld tanks, luchtbehandelingskasten of manifolds. De resulterende families zijn slank, beperkt tot de essentie en kunnen worden gecreëerd of gewijzigd met een comfortabele gebruikersinterface.
De matroesjka
Af en toe komen we in de praktijk een ander patroon tegen, dat we ter illustratie de "Matroesjka"-familie willen noemen. Bij deze modelleertechniek wordt de gebruiker wijsgemaakt dat er sprake is van een parametrische productfamilie. Maar in feite wordt de geometrie van de gerepresenteerde producten in al zijn vormen overbodig gehouden. De geometrie van een specifiek type wordt nu gecontroleerd door een set zichtbaarheidsparameters, die ervoor zorgen dat alleen de gewenste geometrie wordt weergegeven en alle andere verborgen blijven. Dit werkt ook, maar hier kunnen de modellen worden opgeblazen door gegevens die nooit worden gebruikt. In tegenstelling tot meervoudige statische families, heeft het opschonen van ongebruikte types ook geen kans om het model in een "Matryoshka" familie te ontlasten, omdat alleen de typedefinities (d.w.z. de set van noodzakelijke ja/nee parameters) kunnen worden verwijderd, maar niet de redundant vastgehouden geometrie.
Conclusie
Componentfamilies in Revit kunnen, maar hoeven niet noodzakelijk parametrisch te zijn. Parametrie is belangrijk en handig om gelijksoortigheidseffecten te benutten of om enige flexibiliteit toe te staan in de ontwerpfase. Zodra fabrikantspecifieke componenten worden overwogen, d.w.z. de mate van geometrische ontwikkeling wordt verhoogd, is het voordelig om families te gebruiken die ofwel de ene specifieke component beschrijven of in de vereiste vorm kunnen worden gebracht via een duidelijke set parameters.
Mythe2: Dwg-bestanden in families moeten worden vermeden
Sommige modelleerrichtlijnen raden je aan om alleen families te gebruiken die native zijn voor Revit, bij voorkeur families die je zelf hebt gemaakt. Het insluiten van DWG-blokken wordt bijna afgekeurd. Vooral fabrikantenfamilies worden vaak beschouwd als hopeloos verouderd en bevatten fouten. De puristische aanpak om elke familie zelf te genereren wordt echter meestal na enige tijd overboord gegooid. Op het laatst als blijkt dat je ontwerpers toch ook maar mensen zijn, legt het genereren van families een enorme beslag op de middelen en doe je het uiteindelijk toch nog redelijk goed met de beschikbare inhoud uit betrouwbare bronnen, zelfs als een deel van de beschikbare families niet kan voldoen aan de claim om vrij te zijn van DWG-bestanden.
Over de prestaties van embedded DWG-bestanden
Embedded DWG-bestanden lijden voornamelijk onder het feit dat ze worden geassocieerd met een van de grootste doodzonden onder Revit-gebruikers: overmatig gebruik van embedded DWG-tekeningen in Revit-projecten. Het wordt nog erger als je deze CAD modellen "explodeert" in individuele objecten. De mogelijkheid om DWG tekeningen te gebruiken als "achtergrondlaag" is ongetwijfeld een belangrijke bouwsteen voor de overgang van AutoCAD naar Revit, bijvoorbeeld in herontwikkelingsprojecten. Als de tekeningen niet gekoppeld maar ingesloten zijn en vervolgens niet uit de modelweergaven worden verwijderd, zal dit waarschijnlijk ten koste gaan van de prestaties. Op de vraag welke problemen er zijn met embedded DWG-bestanden in families, worden prestaties en geheugenvereisten vaak als argument genoemd. Maar hebben DWG-bestanden in Revit families überhaupt deze lelijke eigenschappen, die er op projectniveau terecht aan worden toegeschreven?
Eerst wat basisprincipes: Revit families bevatten een bepaalde hoeveelheid gegevens. De minimale grootte van lege familiebestanden is ongeveer 300-400 KB. De beslissende factor is nu de extra hoeveelheid gegevens die nodig is om het eigenlijke onderdeel te modelleren en de moeite die nodig is om het weer te geven. Op enkele uitzonderingen na mogen RFA-bestanden nooit groter zijn dan één megabyte. Door het family-instance principe in Revit is het principe "families zijn duur, instanties zijn goedkoop" gelukkig wel van toepassing op de pure bestandsgrootte, waardoor de bestandsgrootte van het project resulteert als een gemengde berekening van families en hun instanties. Zelfs hier zijn DWG-families geen uitzondering, zoals we in het volgende willen demonstreren met eenvoudig te begrijpen voorbeelden.
Veel identieke elementen
Het eerste experiment is als volgt: In een verder leeg Revit-project kopiëren we achtereenvolgens vele instanties van een enkele DWG-familie (hier een FKU90 brandklep uit de Wildeboer-catalogus 06/2021) en loggen we de benodigde ruimte op de harde schijf bij elke verdubbeling, het benodigde geheugen na het openen van het project en de tijd die het maken van een aanzicht (3D zonder snijgedeelte met verborgen lijnen) vereist in de detailniveaus grof, middel en fijn.
Terwijl het proces van het aanvankelijk toevoegen van de familie het project vergroot met ongeveer 140 kB, wordt elke extra instantie in het projectbestand toegevoegd met ongeveer 120 bytes, terwijl het tijdens runtime wordt verwerkt met ongeveer 3 kB. Deze voetafdruk neemt natuurlijk toe met elke instantieparameter die wordt aangemaakt en gevuld, zodat voor echte projecten een iets hogere opslagbelasting per instantie moet worden berekend. In termen van prestaties ontwikkelt de inspanning voor het genereren van een view zich asymptotisch lineair met het aantal elementen dat moet worden gerepresenteerd, wat te verwachten is. Nu is dit constructieve voorbeeld geenszins representatief voor een echt project. Met dit eenvoudige experiment kan echter indrukwekkend worden aangetoond dat veel gevallen van individuele DWG-families geen noemenswaardige verschillen in het gebruik van bronnen vertonen.
Veel verschillende elementen
Nu er bewijs is dat niet het aantal elementen, maar het aantal families erachter de projectgrootte beïnvloedt, laten we nog eens kijken hoe het geheugengebruik verandert afhankelijk van het aantal individuele DWG-families in het project. Met de LINEAR CAD browser voegen we daarom 256 willekeurig geselecteerde families van verschillende fabrikanten en productgroepen toe aan een leeg Revit project en loggen we de opslagbelasting.
Het is te zien dat het gereserveerde hoofdgeheugen van het Revit proces grotendeels onveranderd blijft. Pas vanaf 64 verschillende families in het project treedt een lichte toename op. Zoals verwacht neemt de projectomvang lineair toe met het aantal families in het project, waarbij de gemiddelde geheugenbehoefte in het project ongeveer 300 KB per familie is. Het benodigde geheugen daarentegen kan worden geschat op gemiddeld ongeveer 1,2 MB per gebruikte familie. De meeste families worden niet slechts één keer gebruikt in het project. Daarom breiden we dit experiment uit door achtereenvolgens de 256 families te verdubbelen en opnieuw het geheugen en de benodigde verwerkingscapaciteit voor het maken van weergaven te observeren.
Zelfs in dit voorbeeld, dat qua structuur veel dichter bij echte projecten ligt, kan geen prestatienadeel van de DWG-families worden vastgesteld. De grootte van het model hangt sterk af van het aantal elementen en de informatiedichtheid, waardoor het moeilijk is om algemene schattingen te geven. Echter, met een gemiddeld aantal herhalingen van iets minder dan 75 KB op de opslag, is de gemiddeld benodigde capaciteit per instantie al aanzienlijk lager dan de gebruikelijke vuistregels, volgens welke de projectgrootte niet groter mag zijn dan ongeveer 100 KB per component. En dan hebben we het nog niet eens over het feit dat er naast de productfamilies veel lichtgewicht systeemelementen voor leidingen enzovoort worden gebruikt. Er is nog voldoende ruimte voor extra alfanumerieke informatie op de elementen.
Zijn er misschien ook goede redenen om DWG-bestanden in te sluiten?
Het staat buiten kijf dat DWG-bestanden geen goede basis zijn als je een parametrische Revit familie wilt modelleren. Er zijn echter ook parametrische bronformaten zoals VDI 3805, die meestal geen mapping toelaten naar die van Revit en waarvoor je dus puur uit principe individuele families moet genereren om het "Matryoshka effect" te vermijden. Vanuit het oogpunt van softwareontwikkeling is het alleen maar voordelig om een uitvoerformaat aan te bieden omdat één code voor alles gemakkelijker onderhouden en uitgebreid kan worden. Deze rechtvaardiging lijkt echter nog steeds een ontoelaatbare afkorting te zijn die uit puur gemak is gekozen.
Een meer overtuigende reden om vast te houden aan de DWG-inbedding is dat Revit het genereren van geometrische lichamen met randlengtes kleiner dan 1/32 inch (ongeveer 0,78 mm) weigert. Dit kan meestal niet automatisch worden opgelost en kan daarom leiden tot ernstige weergavefouten. Als een VDI 3805-model een rand bevat met een lengte onder deze drempel - bedoeld of onbedoeld gemodelleerd - kan de resulterende geometrie niet zonder fouten worden gegenereerd als een Revit native familie. De transformatie van VDI 3805 naar DWG verloopt echter bijna altijd soepel. Verrassend genoeg worden de geometrieën in DWG imports meestal efficiënter opgeslagen dan wanneer ze geconverteerd worden naar Revit native geometrieën met behulp van de resolutiefunctie in de familie-editor. Steekproeven toonden aan dat dit effect kan oplopen tot 30% van de totale grootte, minus de overhead van een lege familie, wat in individuele gevallen resulteert in een toename van ongeveer 100%.
Conclusie DWG-mythe
De bewering dat ingesloten DWG-bestanden in families tot problemen leiden, kan niet met feiten worden gestaafd. Het is waar dat er families zijn die gebaseerd zijn op veel te gedetailleerde componententekeningen op verschillende websites, die niet alleen veel geheugen in beslag nemen, maar ook onnodig veel rekentijd vergen in hun verwerking.
In dit geval is niet het meegeleverde DWG-bestand het probleem, maar de inhoud ervan, die niet is geoptimaliseerd voor gebruik in de context van BIM. Aan de andere kant biedt de omweg via het DWG-formaat momenteel de enige stabiele manier om VDI 3805-conforme geometrieën te genereren in Revit, waardoor dit de enige betrouwbare methode is als VDI-fabrikantencatalogi moeten worden geconverteerd naar Revit-families. We moeten het dus minder hebben over de datacontainer van onze componentfamilies en meer over de kwaliteit van de daadwerkelijke inhoud. Dit is een perfecte overgang naar onze laatste mythe.
Mythe 3: Alleen gecertificeerde families zijn goede families
Bij het zoeken naar geschikte component families, komen Revit gebruikers vaak de belofte tegen dat bepaalde catalogi gecertificeerd zijn en andere niet. Waar gaat dit over? Zijn niet-gecertificeerde families überhaupt nog wel te vertrouwen?
Nou, het is net als met het kopen van boodschappen: als je onbekende bronnen wantrouwt, dan doe je in principe al iets goed. Als een familie afkomstig is van een online archief, dan ben jij alleen verantwoordelijk voor de kwaliteitscontrole. Als een onderdelenfabrikant daarentegen officiële productcatalogi aanbiedt, is het belangrijk dat de fabrikant ook de uiteindelijke kwaliteitsborging op zich neemt en de onderdelencatalogus goedkeurt voor gebruik in de te ondersteunen softwareomgevingen. Maar daar is geen certificaat voor nodig, zoiets zou vanzelfsprekend moeten zijn. Geen yoghurtfabrikant zou het nodig vinden om "gegarandeerd eetbaar" op zijn producten te schrijven.
Zuivere conformiteitscertificaten, die worden uitgegeven door een enkele softwarefabrikant, moeten daarom in het beste geval worden beoordeeld als een marketinggrap - in het slechtste geval als documentatie van verlies van controle. Als je kijkt naar de noodzakelijke criteria voor zo'n certificaat, dan blijft vaak alleen de belofte over dat de respectieve inhoud classificatiesleutels en attributen heeft voor bepaalde toepassingsprogramma's. Wat positief klinkt, betekent uiteindelijk dat de respectieve inhoud geen classificatiesleutels en attributen heeft. Wat positief klinkt, betekent uiteindelijk dat de betreffende software geen eenvoudige manier biedt om om te gaan met onbekende inhoud voor gebruikers, laat staan dat het bedrijfseigen standaarden kan koppelen aan interne specificaties. De verklaring "Bevat identifiers voor software XYZ" kan gelezen worden als "Software XYZ biedt geen classificatiemechanisme". Evenzo kan "Beschikt over attributen voor rekenprogramma's van bedrijf XYZ" eenvoudigweg vertaald worden naar "Wij bepalen uw bedrijfsnormen, niet u". Als u dus glossy brochures leest waarin gecertificeerde componentencatalogi worden aangeboden, vraag uzelf dan altijd af of dit überhaupt toegevoegde waarde voor u heeft, of dat een individuele fabrikant certificaten afgeeft volgens zelfgemaakte beperkingen.
Of een keurmerk voor Revit families überhaupt iets waard is, hangt af van de objectiviteit van de onderliggende criteria en hun transparante documentatie. Objectief meetbare criteria zijn hier bijvoorbeeld de resulterende gegevensvariabelen, de parametrische complexiteit en het aantal facetten dat nodig is voor een driedimensionale weergave in het gewenste detailniveau. Een goede familie zou ook niet onnodig moeten werken met het voorzien van vides en - voor zover mogelijk - een vereenvoudigde geometrische representatie moeten bieden waarbij onessentiële details niet expliciet gemodelleerd worden. Maar zelfs zulke objectief meetbare grootheden zeggen op zichzelf helaas weinig. Sommige families, zoals pijptoebehoren, vereisen bijvoorbeeld al in de eerste ontwerpfase bepaalde details zodat de functie van het onderdeel in de weergave kan worden herkend. Andere kunnen voor de meeste toepassingen praktisch zonder noemenswaardige verliezen worden uitgewisseld met een lichtgewicht kubus met connectoren. Als je een kwaliteitscontrole wilt uitvoeren voor families in gebruik, kun je ze niet loskoppelen van de algemene context en moet je vasthouden aan de evaluatie in de constante afstemming van kosten en baten voor het totale project.
Wat moet je doen?
Het vaststellen van geschikte kwaliteitskenmerken voor Revit families en de ontwikkeling van geïntegreerde testmechanismen op basis hiervan is een spannende vraag waarop de auteur naar beste weten nog geen definitief antwoord heeft gegeven. Op basis van vele jaren ervaring kunnen we je het volgende advies geven:
- Zet vraagtekens bij algemene uitspraken in richtlijnen. Revit is de laatste 10 jaar geëvolueerd, publiek beschikbare richtlijnen vaak niet. Niet alles wat ooit zijn reden had, is nog steeds relevant voor de huidige versies.
- Ruim je model regelmatig op en optimaliseer pas nadat je gemeten hebt. Er is geen speciale technische eigenschap die DWG-families bijzonder moeilijk schaalbaar maakt. Achter bijna elke slecht presterende familie zit een slechte modellering, onafhankelijk van de geometriecontainer.
- Als het probleem niet het geheugen is maar de algemene prestaties, probeer dan de werkweergaven te beperken tot het gebied waarin je wilt werken. Selecteer een geschikt niveau van detail en weergave en schakel de weergave uit van modelcomponenten die niet relevant zijn voor uw huidige taak.
Tot slot kunnen we je één dringend advies geven: Vermijd het gebruik van families uit internetrepositories als je jezelf niet vertrouwt om ze te testen. In de loop van ons onderzoek kwamen we een aantal interessante stukken tegen, waarbij een rechthoekige flens van drie megabyte (bestaande uit alleen een kubus en leegtes) een speciale vermelding verdient. De genoemde familie is overigens Revit-native.
Dr. Christian Waluga