- Some Python 'build in functions' did not show up as a method. This error is fixed.
- The Revit API 2021 has deprecated the displayUnitType in Revit 2021. So based on the Revit version the script uses displayUnitType or ForgeTypeId.
- The LookUp node and MethodLookUp node should also work in Dynamo Sandbox or other software. So the UnwrapElement and the loading of some libraries are made conditional.
- The MethodLookUp node now also can deal with 'overloads'. Cases were more than 1 argument series for a method is possible in the API.
- The Example.dyn file in the Extra directory is also updated to the new functionality.
Pagina's op IkLeerBIM
donderdag 22 oktober 2020
Update IkLeerBIM Dynamo Package
vrijdag 11 september 2020
IFC: You don't know what you don't know - Until you do..
vrijdag 4 september 2020
Spouwmuren in BIM
- zie ook mijn artikel op LinkedIn-
Graag hoor ik jullie mening over het volgende, maar voel je niet verplicht. 😉
Mijn vraag gaat over het zo goed mogelijk modelleren van een spouwmuur in Revit en het exporteren naar IFC.
Alles los modelleren kan natuurlijk altijd. Maar het kost stomweg meer tijd om te maken laat staan te onderhouden. En je kan die tijd ook besteden aan extra details bijvoorbeeld. Hierbij een klein onderzoekje of een gelijkwaardige kwaliteit ook op een snellere manier gemaakt kan worden, in Revit en met behulp van Parts. Zelf ben ik geen ‘gebruiker’ van de IFC data, dus of het functioneel gelijkwaardig is in andere toepassingen kan ik slecht zelf beoordelen, vandaar mijn vraag.
- Welke van onderstaande 3 opties is voor jou gebruik gelijkwaardig aan het ‘los modelleren’ van een spouwmuur?
- En als geen van onderstaande gelijkwaardig is, welke komt dan het dichtste in de buurt. Waarom?
- Levert dit onderzoekje nieuwe inzichten op – of is het toch beter om ‘los’ te modelleren en de extra kosten voor lief te nemen.
p.s. Ik zag achteraf dat sommige data van de wand niet correct bleek te zijn |-( Maar voor het principe maakt het niet veel uit. Dus ik heb het even zo gelaten.
1.
Hieronder de basisuitvoering van een samengestelde wand in IFC.
Visueel zijn er geen losse bladen zichtbaar. Wel zit er onder de Material-tab een lijstje met materialen waar de spouwmuur uit is opgebouwd inclusief dikte.
2.
Hieronder een basis uitvoering met Parts in het bronbestand. En als IfcParts in de IFC. Het eerste wat opvalt is dat we nu echt de spouwbladen en materialen herkennen. En daarnaast dat de basiswand nog steeds aanwezig is. Deze bevat nog steeds alle oude data, behalve de Materialen Tab en de Material Property. In plaats daarvan zijn de bladen als Building Element Part aanwezig.
Parts missen standaard heel veel data. Maar die data is best toe te voegen met IFC parameters in Revit. En dat levert het volgende op.
Er zijn veel Properties gevuld. Maar FireRating, Load Bearing, Is External, Classification ontbreken. Die zijn ‘natuurlijk’ hetzelfde als het IfcObject waar de IfcPart deel van uit maakt. Veel Quantities lijken te ontbreken in Solibri. Solibri rapporteert alleen de Inhoud en de BoundingBox. Het host object heeft natuurlijk wel gewoon een lengte, hoogte en verschillende oppervlaktes in Solibri.
3.
Maar je kan de met extra data gevulde Parts ook exporteren als eigen IFC objecten, zie hieronder.
De oorspronkelijke host ontbreekt dan wel. En in plaats daarvan zitten er alleen 2 IfcWalls in het model. Deze bevatten alle Properties die horen bij een IfcWall. (inclusief de gevulde Pset_WallCommon) Eventueel kan je nu ook de spouw filteren zodat deze niet meegaat in de IFC. Wat ontbreekt is de ‘BaseQuantities’ tab. Maar Solibri geeft wel gewoon zijn eigen Quantities. (Eventueel zou je extra Quantities uit het bronbestand mee moeten kunnen sturen.) Wat Solibri niet meer kan is de Area van openingen opgeven. Een eventuele IfcOpening ontbreekt ook echt. En er is dus ook geen relatie tussen bijvoorbeeld een kozijn en de wand waar deze in zit. Maar is dat nodig?
Het enige verschil in de IFC export zit in het aanvinken van ‘Advanced \ Export parts as building elements’
Wat verder opvalt is de IfcName van de IfcWalls in de browserstructuur. Deze is met behulp van de IFC override parameter IfcName bepaald. En automatisch ingevuld met een script. Het is vrij eenvoudig om dit bijvoorbeeld terug te brengen tot alleen het materiaal. Bijvoorbeeld om de sortering in de IFC browser te vereenvoudigen.
Resume:
Voor een modellerende partij is het vaak handig om -tot op zekere hoogte- met samengestelde objecten te werken. Door het maken van Parts en deze (geautomatiseerd) van extra IFC data te voorzien kan er direct een IFC worden gemaakt met losse objecten. Of juist als IfcPart onderdeel van een host. De laatste 2 opties hebben hun eigen specifieke voor en nadelen.
voor meer info:
https://github.com/Autodesk/revit-ifc/issues/120
dinsdag 5 mei 2020
Update IkLeerBIM Dynamo Package
The whole goal of this Package is to help people who are already familiar with Dynamo. And understand how to make a for loop in Python. So they can find their way with the (Revit) API as comfortable as possible. You can search the internet later. Most Dynamo users will come to this point where they need to build just a little Python script because there is no Node available. Or they need to speed up a Dynamo script just a little.
To do this I needed to add 2 more Nodes:
API.FilterScriptGenerator
Will help you with your second problem: "How to grab elements from the Revit Database?" You can use the Dynamo Nodes off course. But can you do without? Now you can. And very easy. This Node will generate a complete Python Script. Copy this to clipboard, with a Node from Clockwork or Rhythm. Paste it in a Python Node. And tweak it to your needs.API.FilterScriptGenerator |
But, "The FilterElementCollector is no rocket science." I hear you say. No it isn't.
Still this Node has almost every option that the API gives us. And there are quite a few...
Beside filtering on 1 or multiple Classes or BuiltinCategories, you can Filter on all the Parameters you want. Use Views, Levels, Geometry and DesignOptions. And there is also an option so your Python Node also works for Linked documents.
Some Filter options can be achieved in multiple ways. If that is the case I tried to choose 1 or the other. I also skipped some very specialized Filters, because it is possible to also use e.g. BuiltinCategories. Most of this is documented in the Node.
And for those who know their stuff. This is not the most beautiful, clean and efficient script I ever wrote. But it works. ;-) So perhaps I will clean it up later (if I want to).
API.MethodLookUp
Helps to find the arguments needed for a method. In al lot of cases this will be enough. And if this is still confusing you can always use google and find more examples or an explanation.API.MethodLookUp |
With Lacing Longest and some sorting and grouping. |
woensdag 15 april 2020
First release IkLeerBIM Dynamo API helper (micro) Package
Just a few teasers on what this node does.
And remember, this Node is basically a temporary LookUp node. It is not build to use it as a part of script. But why would you. Use it to build your own Python script. Have fun.
This node eats almost everything and shows the class of the input |
Just give this node a list or a single item. It will flatten everything and uses only the first index. |
It will clean the output for empty / null etc. values. Unless you want to see everything off course. |
Sometimes you simply want readable names. But most of the times you do not... |
Because it slows down a little. And if you know what you are looking for, you simply use the Case Insensitive search. |