Hi, I am curious and wondering if there is any kind of machine learning to recognize the opening part of a window family and output as points or size or something that can be used further with dynamo.
The idea is to get the height and width of opening part of window and use raybounce to figure out the height from floor.
It would be simpler just to get the geometry associated with the glass subcategory (and or the glass material) and use that.
Sure - easy. In that case just pull out the geometry for the swing lines. UV coordinates are right there.
This is more of an issue of Revit content building than machine learning.
You can put a formula in the family so it directly reports the open area. (Reporting Parameetrs)
You can nest families so you can identify which ones open and which ones donât and schedule accordingly. (As the case with this - it is probably 4 windows mulled together in real world construction.)
You can apply a different material to the operable panel and have that scheduled.
Plenty of options without ray bouncing all over for no reason.
4 Likes
Very well said.
1 Like
It does raise an interesting case though, as often people work with content they arenât responsible for - e.g. an engineer dealing with architectural models to assess free open air. Open BIM thinking will push us towards this in future I think as weâre all still very much designing content internally to work with our own scripts and tools. ML might play a part, if not just regulation on content behaviour required by engineers set by such organisations like BIMMEPaus. We saw some push in the past down under with ANZRS but it fizzled out unfortunately - our associations are still too busy patting each other on the back and fawning over yellow trace.
3 Likes
@aaronrumple Those are interesting approaches and I will definitely look up on these possibilities.
It just seems as it would require a lot of the window families.
The idea with machine learning was that it wouldnât require much of the family and therefore be a lot more versatile and it would still recognize the opening by it self.
Machine learning required the use of large data sets to find patterns. Youâre not going to have enough windows in your data set to use machine learning. It has to have patterns to look for. Whatâs it going to look for?
Revit was designed to put the intelligence in the objects. So, no. It isnât asking too much of a window family to report the information. In fact - it is exactly how Revit was designed to work. Put the I in the BIM and get information out.
By all means - if you have the resources to make a machine learning app that can accomplish this - give it a go. Just sounds like a lot of work for very little payback.
4 Likes
I agree with @aaronrumpleâs approach and getting this geometrically via more traditional means. By material sounds like the best option if youâre trying to isolate the glass part of the family.
As for ML, you still need to train your ML model. I think this would be substantially more effort than the geometric approach as youâd need to categorise what a window is, and more importantly, what it is not (say a door or a vent cover etc).
1 Like
Which is why Adsk should get their sh*t together and put the standards in the software. Instead they are taking the opposite approach and heading toward a âopenâ system. And I donât mean that in a good way. I mean open in the sense that the end user has to do the heavy lifting. Shared parameters are a disaster. It is a complete tower of bable. And it is exactly why AutoCAD has become a nothing stupid program. AutoCAD was designed from initial concept to have the end users write the code. It failed miserably. (I had to support Mechanical Desktop at one point - what a joke that was.)
IFC is the right way forward (or maybe better said - only way). Define what a window is and put enough juice in the standards so we can all communicate in the same language. I mean the OTB window family still has nothing in it more than 14 basic parameters. And half of those were only introduced with the advent of the MEP. Why hasnât Adsk flushed out what a window is and put that information in the system as OST_Parameters? Why doesnât a door have hardware parameters? Are we all adding the same material parameters with totally different GUIDS. Of course we are. Why should anyone have to make up a bunch of parameters? And in the end we all make up different ones to do the exact same things. Just look at any manufacture built RFA you download - they are unusable disasters.
There was an Open Shared parameter effort. But it died. The government and NBS BIM Object Shared Parameters are joke. No spaces? Camel Case? Toss in a few underscores just for fun? Lack of categorization. LowerCurrent2? Really? _mtrl? Andone speak that language? And raise your hand if youâve even looked at this or are aware of its existence.
Sorry for the rant, but it is exactly the same path Dynamo is on. A bunch of nodes created here and there with hundreds of different versions that break code right and left every time there is a new version. And the very reason I never use custom nodes. Only plain python that I can have some trust in running down the road.
Adsk could set up a system where there is a central database of parameters and some enforcement of standards. Oh wait - that would be Autodesk supporting IFC. But that goes against a close system that locks in users to a subscription model.
Sorry for that rant, but we are on a downhill slope when it comes to BIM. Honestly, the only way forward is open standards and yes - probably open source software. Full disclosure - I own a lot of adsk stock.
1 Like
I definitely like this use-case. Have you ever seen what zillow is doing with ML in regards to counting openings and more in panoramas, images, etc?
4 Likes
Thatâs pretty neat!
1 Like
First up: I hear and appreciate your frustration, but please keep it respectful.
Any time the software has dictated content, itâs become a chorus of âthat doesnât work for me/us because ______â. One example of the top of my head is coordinate systems: different from country to country, state to state, and sometimes within the same project (this portion we are being funded by the DOT, for that part we are funded by the airport, and that one by the port authority).
Fire rating of elements is another good example. Some want that as an instance parameter, others as a type, and still others as both. Some want it called Rating, some Fire Resistance Rating, some Fire Rating, FRR, Fire Classification, and some want it called as âassembly valueâ and refer to another data source, etc⌠Still others (likely most of on the project) donât care at all.
If the global industry doesnât settle on a consistent name than hard coding of a standard can actually make things more difficult for others. Usually when that happens the result is something akin to the classic XKCD comic: xkcd: Standards.
As more people look to leverage BIM in their downstream processes this becomes more of an issue, but with the application of tools like Dynamo it becomes trivial for a seasoned user to get the data they are after and execute the task, even if that same graph doesnât scale to every job the office ever undertakes.
5 Likes
I strongly disagree with everything youâve said. But lets start with fire ratings. Autodesk can lead - or they can assist in making mess of things. They have chosen the latter. Tossed their hands up and said - whoops - not our issue - youâre problem. So you get the gibberish across the industry - and I fault other groups such as the AIA for this as well. As to the name - just make a decision. You want to get a focus group together and have a moment - then go ahead. But right now nothing is being done. And the longer that goes on, the worse it gets. Just look around the Dynamo forum. People are trying to solve problems that shouldnât exist in software that is 20+ years old. Why shouldnât there be an option to select a building code from a list and have that available right inside Revit? Why not have the different coordinate systems defined as standards? There arenât that many. Completely possible. How about something as simple as Net and Gross for rooms without drawing a whole separate plan or writing a bunch of code to figure it all out. But isnât going to happen under Autodesk.
Door Height - anyone NOT use that. Rough Width? Anyone go an make up their own Rough_Opening-2 parameter. No - users will take the path of least resistance. Set a path and people will follow. We have FAMILY_ROUGH_WIDTH_PARAM (why you need the bonus â_PARAMâ is beyond me) and DOOR_WIDTH and WIDTH, but no DOOR_ROUGH_WIDTH. One would think that FAMILY_ROUGH_WIDTH could be used for all families. But isnât in generic families, nor can I get it in there. But door for some reason doors have their own width and windows have a different width. Now I want to make a double door. (I wrote an AUGI class on this that is still being used widely.) Where is my Panel Width Parameter? Or do I do nested families and keep using DOOR_WIDTH even though that really isnât what it is. And how do I say PR 36" x 72"? EVERYONE right now is doing it differently. We even have people in the same office doing it differently and you can imagine how that messes things up. This is so, so very, very basic. I should be able to make a simple double door from Adsk provided standards. I canât. Everyone should have a double egress door at their fingertips. I donât. Thatâs a major fail. Why did I have to write my own Pline Fit command for Revit? Sigh.
As far as standards - EVERYONE right now is making up their own standards. EVERYONE. So it is a comic as it stands right now.
Adsk canât even get its own content right - and have given up trying. Why are all the default titleblocks off the lower left corner by 3/256" in both the X and Y? Maybe there was a technical reason at one point - but I doubt it. Just a whoops that goes from version to version. Why does that default brick pattern not course to 8"? Iâve done whole lunch and learns and sent out email after email - donât use Revit brick patterns - they are wrong. But still get users keep grabbing whatâs in a template and finding dimensions off and having PMâs mark up drawings. Over and over.
It isnât trivial to find a seasoned user. Let alone a seasoned user that can use Dynamo. Besides - professionals should be designing stuff - not writing software all the time. Heck - I spend a good deal of time just answering âWhy canât I see my stuff.â questions." And none of this is in my job description - Iâm Director of Design - not CAD Manager or IT Specialist. Iâm forced to know Dynamo, python, .Net, MaxScript, C#, SQL and VB because I want to make good looking buildings. Really wish I didnât. Do I get paid accordingly? No. Do I wish someone, anyone, in our office could also write some code. You bet. 1 out of 125 is what you have for âseasoned usersâ.
The number one thing Revit needs to do is allow shared parameters to be renamed inside a project. Yes - I know all the technical issues there. But somehow we have to be able to have a way to pull back from the alphabet soup that has been created and still maintain a way forward without reinventing the wheel all the time. Iâm on my 4th generation of building doors for a company. Otherwise, Revit will go the way of AutoCAD sooner than later.
The only good thing is that Iâve made more money of Adsk stock than Iâve paid Adsk over the years.
Gibberish.
1 Like
Yep Iâm roughly on the same page here, although Dynamo et al has been a blessing in some regards as it taught us that data is quite malleable when you have tools like it.
I stand more on the side that it is an issue that firstly lies with the AIA type bodies. It is their job to regulate and represent our industry, not Autodesks. Autodesk is morally obligated given they have our money, but Iâd say that for a while they did a lot more than other bodies in pushing things in a direction.
Weâre probably a bit off topic here so Iâll just say I hear you, and a lot of others too. Dynamo showed lots of Revit users a different way to look at software, and has shown people a pathway towards open source thinking that will grow the open thinking movement.
3 Likes