HI guys.
I'm needing to know the cut area's of windows and doors in a wall. I thought this would be a simple matter of grabbing the BIP "HOST_Area_Computed" as with my testing that was returning the correct area. It turns out that this is not the case from further testing.
PLease refer to the attached RVT file with two doors inserted into a wall. They look similar but one is reporting through Revit Lookup 4m2 and the other 2m2.
Why is this? What actually is "HOST_Area_Computed" reporting? and what is the most reliable way of getting the cut area of windows and doors?
Regards
Phillip Miller
Solved! Go to Solution.
Solved by PhillipM. Go to Solution.
Solved by jeremytammik. Go to Solution.
Dear Phillip,
Thank you for your query.
I cannot really say anything about the values reported by the HOST_Area_Computed parameter. That belongs to the user interface, as far as I am concerned, and you would have to ask a product usage expert or application engineer to explain the meaning of that.
For a pure API perspective, I assume you are aware of the Revit SDK MaterialQuantities sample?
http://thebuildingcoder.typepad.com/blog/2010/02/material-quantity-extraction.html
Does that not give you pretty much exactly what you need?
I hope this helps.
Best regards,
Jeremy
Hi Jeremy.
Thank you for your reply and also the link to the SDK example. I will look into that in the morning.
To clarify what I'm doing, is, I want to find the surface areas of walls that are associated with Rooms. To do this I'm making use of the the "SpatialElementGeometryCalculator" class which is perfect as it does give areas of walls, floor and ceilings even if they are angled. The only problem is it doesn't subtract things like doors and windows.
Your link to your blog has jogged my memory though with a workaround that I could implement. I know what doors and windows are associated with the room and also the wall associated with the rooms face, so I could get the area of the wall (which does calculate the gross - openings), then remove the associated doors and windows grab the new area and minus it from the gross and then turn back the transaction. I'm pretty sure that will then give me the true area of the rooms walls 🙂
I will let you know how I get on.
Cheers
Phillip Miller
Kiwi Codes Solutions Ltd
Dear Phillip,
Yes, that is exacly the sort of approach I was thinking of.
Wow, your use of the SpatialElementGeometryCalculator sounds very exciting.
The Building Coder does not provide any samples of using that except the rather complex
It would be great if you would like to share something sweet and simple making use of that class in the way you describe.
Thank you!
Cheers,
Jeremy
Hi Jermey.
Thank you so much for your suggestions. The good news is that the temp delete of cutting objects in the wall works very well. I'm not to sure why the BIP Area parm is reporting odd values but I suppose that does not matter any more.
I took a look at your suggested SDK examples and they didn't really apply to my situation as I was requiring the surface areas of walls associated to rooms. AS a wall can span multiple rooms I had two choices. First up I used the room bounding object to extract the wall information. The downside to this approach is that you had to take the boundary segment length and then multiply that by the wall height, hoping that the wall had a consistent wall height. (Not always the case). I also was requiring the floor and ceiling areas and information and this was achieved by shooting rays from the room location point directly up and down to gather that information. We found the results in the approach to be a bit unreliable and not very accurate at times depending on how the walls etc were modeled.
That lead us to investigate the "SpatialElementGeometryCalculator" class, which after some trial and error does exactly what we were after. I'm happy to provide you with some small sample code of this working for your users.
Once again thanks for your help.
Regards
Phillip Miller
Kiwi Codes Solutions Ltd
Dear Phillip,
Thank you very much for your appreciation and the good news!
It seems to me the one of the door areas seems to be counting something double.
Yes, of course the spatial element geometry calculator is much more suited to the need you describe.
Looking forward to the sample code.
Thank you!
Cheers,
Jeremy
Dear Phillip,
I published your VB.NET sample code and the resulting C# implementation now:
http://thebuildingcoder.typepad.com/blog/2015/03/calculating-gross-and-net-wall-areas.html
Thank you very much for the very fruitful discussion!
Cheers,
Jeremy
Dear Phillip,
I mentioned some possible filtered element collector optimisations in my post.
They would make a huge difference and be very important in a large project.
Now Vilo commented on the post and pointed out an even better solution, much better!
The method HostObject.FindInserts returns all the wall openings right away.
People have been asking for this for ages, and I was not aware that it had been added to the API.
Please take a look at the updated code in the GitHub repository and let us know whether this works for you as well.
Thank you!
Cheers,
Jeremy
HI Jeremy.
You will not believe the timing on your’s and Vilo's post 🙂
I had already made the filtered element collector more optimised as you suggested in your blog post, but like you I didn't know about the "FindInserts" method. It rocks.
Just this morning I was contacted by my client saying the custom API works great on walls with hosted families but not with walls that had structure separated with lining walls. IE 3 Walls making up one wall with the linings walls joined the structural wall.
As you can see in my code I was comparing FamiliyInstance.HostID with the wall.id. In a compound wall situation like above the cut opening in the linings wall has a different ID that the FamilyInstance HostID, so it didn't find any openings.
The "FindInserts" method solved all this in a much nicer way.
Thank you Jeremy and Vilo
Hi Phillip
Even though you solved the problem (congratulations on that by the way) I might be able to provide some additional info on the subject.
During the last couple of months I've been working with something related. In my case the specific surface area of each window/door is the main interest and I have thus been digging in to this topic quite a bit.
My findings suggest that the value of host_area_computed in regards to family instances is, what I can best explain as a sum of the geometric objects 'overlapping' the wall geometry in all 3 axes.
Terrible as that explanaition might be, consider the follwing:
I simple 1000x1000 mm window family containing only a sheet of glass with a thickness of 100 mm will report an area 1.2 square meters, equivalent to what could be measured in 2D plan, section and elevation views. If the geometry is copied in the family so that it contains two sweets of glass, host_area_computed will report the area of both, adding up to 2.4 square meters. This assumption can be supported by snooping a window hosted by a curtain wall. As the curtain wall has no actual depth/thickness only one overlapping area exist e.g. as defined by points the X and Z axes.
Whether I'm right or not doesn't really affect anything, but I thought it was worth sharing anyway 🙂
An easy approach to access the actual surface/opening area, that I've found extremely useful, resides in the Autodesk.Revit.DB.IFC namespace. More specifically in ExporterIFCUtils which has provided other interesting features in the past. The methods GetInstanceCutoutFromWall and ComputeAreaOfCurveLoops has been able to handle every oddly shaped window I have ever fed them. And especially the latter is handy in a very wide context 🙂
Dear Phillip,
Thank you very much for your confirmation and providing samples in which the FindInserts method really makes a significant difference, besides the performance improvement!
I published the new findings and updated C# solution on The Building Coder:
Would you like to update the VB.NET code in the GitHub repository as well?
Thank you!
Cheers,
Jeremy
Dear Pjohan13,
Wow, those are some pretty interesting and exciting findings you report.
I think it would be well worth fleshing out in an own separate blog post, pssibly as a follow-up to the existing two, or maybe as a new topic.
Two topics, in fact:
Do you happen to have any suitable sample code illustrating your statements above?
Thank you!
Cheers,
Jeremy
Hi Jeremy
I would agree. Unfortunately I have no sample code related to host_area_computed analysis. My findings on the parameter value is based on manual analysis including family editing, measuring, snooping and comparing through a series of small steps. When I eventually stumbled upon the IFCExportUtils methods, I settled my quest for clarity in regards to the bip.
The way I have used them, generally, is pretty straight forward. I've attached a very simple samle implementing both methods to display the surface areas of selected windows/doors/curtain panels. I've also attached a sample project containing the earlier mentioned 1000x1000 mm single sheet window and a 'zig-zag'-shaped window intented to challenge the method a bit - which it doesn't 🙂
One beauty of the GetInstanceCutoutFromWall method is that it returns the opening boundary as a curve loop and thus provides additional posibilities related to windows/door. For instance, the perimeter is available through curve lengths or sealant area can be calculated by adding a CurveLoop.CreateViaOffset to the list thats feeds the ComputeAreaOfCurveLoops, etc.
I've tested the methods on windows intersecting the vertical join between two different wall types and windows interesecting the horizontical join in stacked walls, in each case with consistant outcome.
Ideally the GetAreaCutoutFromWall would instead be *FromHost to cover skylights as well. But with solid performance like this I can't really ask for more, except maybe the values exposed directly by the FamilyInstance class or curtain wall's orientation vector updating accordingly when flipped (a different discussion maybe :))
I hope that the sample can be of use and look forward to hopefully seeing more on this matter on The Building Coder.
Best regards,
Peter
Dear Peter,
Mille grazie och tack så mycket for your research and wonderful little sample add-in.
I edited, tested, cleaned up and published it on The Building Coder and GitHub:
Cheers,
Jeremy
Returning to the original issue of door and window areas, Håkon Clausen submitted a significant improvement to the SpatialElementGeometryCalculator sample:
Thanks, Håkon!
Cheers,
Jeremy
Hi,
I know its been a year since the last post for this topics, but i am very interessed in the code you guys have done!!
Thanks for the sharing!!
I was looking for a solution quite similar and since i am a begginer in the world of programmation and Revit API, i would like some advise to adapt this code to my need if it doesn´t bother you of course.
I would like to know if it is possible to create a parameter Revit of area type that will be visible in the RoomSchedule and that will take for value the net total area of wall of the room. And do so for each room where as to put the result of the fonction in the taskdiaog?
Thanks u !
guys, i understand that :
curveLoop = I.ExporterIFCUtils.GetInstanceCutoutFromWall(doc, wall, familyInstance, out basisY)
returns the curve loop of an cutout.
unfortunately i am trying to achieve the result from the python side.
my efforts end in errors for the "out basisY"
as my coding skills are still limited, can anyone help me out on this ?
tx
Dear Kop,
Thank you for the information.
Can you please add a sample code snippet showing how you solved it, in case anyone else runs into the same issue?
Thank you!
Cheers,
Jeremy
Can't find what you're looking for? Ask the community or share your knowledge.