[FAMILY GUIDE DOORS]

Opstart document voor het schrijven van een familie guideVoor: Revit Standards FoundationDoor: Mark MaasEerste versie: 18 December 2015Huidige versie: 20 december 2016

[woord vooraf]

• De Family Guide is bedoeld om afspraken te maken over zaken zoals de oriëntatie, het nulpunt en het juist gebruiken van (Shared) Parameters, Object Styles, naamgevingen van componenten, lijnstijlen en arceringen;

• Het is geen handleiding die omschrijft hoe de geometrie zelf gemodelleerd dient te worden. Dat kan immers op vele manieren, de ene modelleur modelleert alles in de Family zelf en een ander werkt wellicht met nested families en/of met shared components. Die vrijheid van modelleren kunnen en willen we u niet afnemen;

• De wijze hoe de geometrie precies gemodelleerd wordt mag geen verschil maken over hoe de Family zich in het project gedraagt. Als de kaders en uitgangspunten allemaal hetzelfde zijn dan zouden alle door Family probleemloos met elkaar uitgewisseld moeten kunnen worden;

• Bij dit uitwisselen zouden dan geen foutmeldingen mogen komen over een verkeerde hosting of Family type. Ook zouden draairichtingen niet mogen omklappen en zouden de kozijnen niet opeens naar links of rechts mogen schieten;

• Groeimodel van generiek naar product specifiek zonder informatieverlies;• Bestaande tags en schedules zouden ook niet verstoord mogen worden tijdens door het

inwisselen van een bepaalde Door Family. Ook zouden de object styles onveranderd moeten blijven en zouden er geen arceerpatronen toegevoegd worden. De kaders waarbinnen dit allemaal mogelijk is worden hier in dit document beschreven;

• Om wereldwijde afspraken te kunnen maken is het belangrijk dat we de basis uitgangspunten van Autodesk zoveel mogelijk respecteren. Pas daar waar bepaalde zaken niet door Autodesk zijn gedefinieerd gaan wij als Stichting Revit Standards een nieuwe definitie vaststellen.

[Wat is een deur?]

[Wat gaan we doen?]

• Uitleg opzet family guide Doors

• Discussie

– Parameters

– Object Styles

– Hoe verder?

• Competitie:

“Break on through (to the other side)”Wie maakt de slimste, mooiste of gekste deur?

[Uitgangspunten]

• Basis zoals deze door Autodesk is opgezet(Goede reden hebben om het anders te willen)

[Metric Door.rft]

Standaard template Doors Familie. Exterior is bovenzijde van het beeld. Boven is dus buiten en beneden is binnen.

[Metric Door.rft]

Exterior

Aanzicht buitenzijde. Schanierzijde is links

[Metric Door.rft]

Interior

[Wat weten we nu]

• Binnen en buitenzijde

• Schanierzijde

• Nulpunt ligt in het hart van de deur

• Room calculation point in nulpunt

• Width

• Height

• Depth blijft over

[Wat kunnen we bepalen]

• Nulpunt = hart deur

• Width = NLRS_C_breedte

• Height = NLRS_C_hoogte

• NLRS_C_diepte

• Hangzijde deur

[Wat kunnen we bepalen]

[Draairichting]

• Flip Controle uitzetten?

• Wanneer rechts of linksdraaiend?

• Internationale standaard?

De Flip control en de spiegelfunctie van Revit kunnen de tellingen verstoren als men probeert om linksdraaiende van rechtsdraaiende deuren te onderscheiden. Denk ook aan deuren die in Groupsvoorkomen en waarbij gebruik wordt gemaakt van gespiegelde Groups. Linksdraaiend is dan rechtsdraaiend geworden en andersom. Erg lastig te managen zeker als er meerdere modelleurs aan een project werken.

[Eerste Aanname]

[Wat weten we nu?]

[Draairichtingen…]

Amerikaans, Duits of Nederlands systeem aanhouden?

[Wat weten we nu?]

Voorstel: NLRS afspraken conform DIN norm 1962, aangepast aan Revit

[Refplanes]

[Aanwezige Refplanes]

Name Is reference (strenght) Defines orgin

Center (left/Right) Center (left/Right) (Strong) Yes

left left (Strong) No

Right Right (Strong) No

Top Top (Strong) No

Interior (wall) Weak Reference No

Exterior (wall) Weak Reference No

Weak Reference Yes

[NLRS Refplanes]

Name Is reference (strenght) Defines orgin

NLRS_Frame/Mullion Calculation Not a Reference No

NLRS_Frame/Mullion Exterior Front (Strong) No

NLRS_Frame/Mullion Center Center (Front/Back) No

NLRS_Frame/Mullion Interior Back (Strong) No

[NLRS Refplanes]

De parameters breedte, hoogte en diepte definiëren een box waarbinnen zich de geometrie van het kozijn zich bevind. De maten zeggen dus alleen iets over de geometrie van het kozijn en niks over eventuele inbouwmaten of stelruimtes rondom het kozijn.

[NLRS Refplanes]

• Veel project specifiek

• Veel eigen voorkeuren

• Niet heel belangrijk….

Wellicht is het verstandig om een standaard Door template te maken waarin er een aantal refplanesalvast zijn aangemaakt. Aan de toevoeging “NLRS” is dan te zien dat het een door de RSF aangemaakte refplane gaat.

[Subcategories & Object Styles]

[Subcategories Door template]

[Wat willen we hoe laten zien?]

[Doel Subcategories]

• Grafische weergave geometrie!

• Clusteren van hoofdgroepen

• Dingen snel wel of niet laten zien

• Export naar IFC (generic models)

– IfcExport gebruiken!

Subcategories zijn primair bedoeld voor de grafische aansturing. Je kunt er ook mee mappen om naar IFC te exporteren. Maar dat is niet nodig indien er gebruik gemaakt wordt van de shared parameter IfcExportAs.

[Subcategories Door template]

[Subcategories Project]

[Subcategories Project]

[RS Subcategories Revit]

[RS Subcategories Revit]

[RS Subcategories Revit]

• Alle Object Styles in de family template

• Kans op type fouten bij aanmaken…

• Nog meer Object Styles nodig?

• Afspraken maken over nesten….

Object Styles kunnen het project behoorlijk vervuilen. Een overdaad aan Object Styles maakt het managen van het project lastig. Content welke uitgewisseld dient te worden zou geen andere Object Styles mogen bevatten als dat er in de standaard staat omschreven.

Subcategories zijn primair bedoeld voor de grafische aansturing. Je kunt er ook mee mappen om naar IFC te exporteren. Maar dat is niet nodig indien er gebruik gemaakt wordt van de shared parameter IfcExportAs.

[Shared parameters]

[RS parameters]

• NLRS_C_Hoogte

• NLRS_C_Hoogte_01

• NLRS_C_Breedte

• NLRS_C_Breedte_01

• NLRS_C_Diepte

• NLRS_C_Diepte_01

• NLRS_C_stelruimteLees de handleiding van de RS over een uitleg van de Shared Parameters. De RS maakt gebruik van generieke parameters omdat een lijst van omschrijvingen nooit volledig zal zijn. De lijst wordt langer en langer en daardoor onoverzichtelijk. Hierdoor ontstaan fouten.

[RS parameters]

“Eenvoudig doorkoppelen van project parameters”

Om te voldoen aan de RS is het meestal voldoende om de hoofdmaatvoering te koppelen aan de eigen gebruikte project parameters.

[Aanvullende parameters??]

• NLRS_C_dagmaat, wellicht toevoegen

• NLRS_C_profielbreedte? NLRS_C_sponninghoogte?

• NLRS_C_hoogte tafelpoot kastje van tante annie…

(oppassen voor je het weet wordt de lijst weer veel te lang…)

Om te voldoen aan de RS is het meestal voldoende om de hoofdmaatvoering te koppelen aan de eigen gebruikte project parameters.

Mijn_eigen_standaard =>NLRS_C_breedte

[Gebruik Shared Parameters]

• Alleen datgene wat je wilt opnemen in een schedule

• Hoofdmaatvoering: Breedte en hoogte veelal voldoende

• Overige secundaire parameters kunnen gewoon project parameters zijn…

• Gebruik reporting parameters voor zaken zoals de dagmaat

[Vakvullingen]

• Zijlicht links

• Bovenlicht

• Rechter zijlicht

• Tweede vak rechts naast de deur

• Melkmeisje naast deur

• Hoe allemaal benoemen?

[Vakvullingen]

Ook hier is het voorstel om de vakken generiek te gaan benoemen. We handteren het dambord principe. Het Startpunt is de linker bovenhoek. Elk vak kan dan aangestuurd worden met project parameters. Bijvoorbeeld Breedte_C2 of hoogte_B1

[Nog op te lossen..]

• Shared nested Family => IFC Export

• Shared nested Family => conflicten in groups

• Viewrange problemen Doors and Windows

[Viewrange problemen..]

[Viewrange problemen..]

[Viewrange problemen..]

Family category: Generic Models

Family category: Windows and Doors

[Viewrange problemen..]

Vandaar dat er vaak gewerkt wordt met generiek families i.p.v. de Doors of Windows familie voor het modelleren van stijlen en dorpels. E.a. buck in Revitzorgt ervoor dat je bovenop de geometrie gaat kijken i.p.v. dat deze netjes wordt doorgesneden. Ook worden onderdelen soms zichtbaar in de plattegronden terwijl je dit niet zou verwachten. De elementen hiden in de plan views is een veelgebruikte work-around.

[Nog meer om op te lossen..]

• Hoe om te gaan met spiegelen en de flipcontrol?

• Hosted en unhosted Doors en Windows in Revit

• Shared families voor en nadelen

• Wanneer kiezen voor categorie generic, doorsof windows?

• Workplane based ja of nee?

[Nog meer om op te lossen..]

Een Door opgebouwd uit verschillende shared nested

familys zal bij een IFC export uiteen vallen. Elke genest

shared component zal worden gezien als een aparte

deur. Indien de verschillende kozijn onderdelen niet op

shared worden gezet dan worden ze wel gebundeld tot

één door.

Shared Nested components kunnen conflicten

veroorzaken binnen Groups.

Shared Nested components gemaakt met in de Doors

of Windows categorie worden ook getoond in de

schedules.

Hoe om te gaan met kozijnen die hosted en unhosted

zijn maar eigenlijk hetzelfde kozijn representeren? Dit

omdat een kozijn geplaatst in een sparing van een

gelinkt model veelal als unhosted gemodelleerd zal

worden.

Welke parameters zijn er nu echt noodzakelijk en

missen er nu nog in de shared parameter lijst?

Welke instance eigenschappen willen we allemaal

koppelen aan het kozijn en ?

Hoe gaan we het onderscheid maken tussen links- en

rechtsdraaiende deuren? Hoe voorkomen we dat we

dit om zeep helpen met een flip control of de mirror

functie?.

Vult u maar aan…

[Door contest]

“Break on through (to the other side)”

• Starks als de familie guide klaar is…

• Mooie testcase!

• Input van verschillende partijen

• Aanscherpen family guide Doors

• Praktijkgericht en toepasbaar

• Doel: Content waar we branche breed wat aan hebben!

[Door contest]

“wie bouwt er de slimste, mooiste of gekste deur?”

Graag zie ik jullie opmerkingen tegemoet. We nemen het mee tijdens onze verder uitwerking.

Mailen naar: revitstandards@gmail.com

[Einde..]

“Bedankt voor het doornemen”