Opstartdocument welke als leidraad genomen zal worden voor het verder uitschrijven van de familie guides voor de Doors en Windows familie.

1. [FAMILY GUIDE DOORS]
Opstart document voor het schrijven van een familie guide
Voor: Revit Standards Foundation
Door: Mark Maas
Eerste versie: 18 December 2015
Huidige versie: 20 december 2016

2. [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.

3. [Wat is een deur?]

4. [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?

5. [Uitgangspunten]
• Basis zoals deze door Autodesk is opgezet
(Goede reden hebben om het anders te willen)

6. [Metric Door.rft]
Standaard template Doors Familie. Exterior is
bovenzijde van het beeld. Boven is dus buiten en
beneden is binnen.

7. [Metric Door.rft]
Exterior
Aanzicht buitenzijde. Schanierzijde is links

8. [Metric Door.rft]
Interior

9. [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

10. [Wat kunnen we bepalen]
• Nulpunt = hart deur
• Width = NLRS_C_breedte
• Height = NLRS_C_hoogte
• NLRS_C_diepte
• Hangzijde deur

11. [Wat kunnen we bepalen]

12. [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 Groups
voorkomen 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.

13. [Eerste Aanname]

14. [Wat weten we nu?]

15. [Draairichtingen…]
Amerikaans, Duits of Nederlands systeem aanhouden?

16. [Wat weten we nu?]
Voorstel: NLRS afspraken conform DIN norm 1962, aangepast aan Revit

17. [Refplanes]

18. [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

19. [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

20. [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.

21. [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 refplanes
alvast zijn aangemaakt. Aan de toevoeging “NLRS” is
dan te zien dat het een door de RSF aangemaakte
refplane gaat.

22. [Subcategories & Object Styles]

23. [Subcategories Door template]

24. [Wat willen we hoe laten zien?]

25. [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.

26. [Subcategories Door template]

27. [Subcategories Project]

28. [Subcategories Project]

29. [RS Subcategories Revit]

30. [RS Subcategories Revit]

31. [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.

32. [Shared parameters]

33. [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_stelruimte Lees 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.

34. [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.

35. [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

36. [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

37. [Vakvullingen]
• Zijlicht links
• Bovenlicht
• Rechter zijlicht
• Tweede vak rechts naast de deur
• Melkmeisje naast deur
• Hoe allemaal benoemen?

38. [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

39. [Nog op te lossen..]
• Shared nested Family => IFC Export
• Shared nested Family => conflicten in groups
• Viewrange problemen Doors and Windows

40. [Viewrange problemen..]

41. [Viewrange problemen..]

42. [Viewrange problemen..]
Family category: Generic Models
Family category: Windows and Doors

43. [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 Revit
zorgt 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.

44. [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, doors
of windows?
• Workplane based ja of nee?

45. [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…

46. [Door contest]
“Break on through (to the other side)”

47. • 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?”

48. Graag zie ik jullie opmerkingen tegemoet. We
nemen het mee tijdens onze verder
uitwerking.
Mailen naar: revitstandards@gmail.com
[Einde..]
“Bedankt voor het doornemen”