Hi everyone,

I recently occured a really awkward situation while converting curtain wall components into Dynamo geometry with Element.Geometry node. Basically, when using this node on mullions, Dynamo explodes some of them into surfaces and lines instead of solids - see attached image:

It’s pretty disturbing since I really need the volumetric data for further processing and I cannot figure out how to manage this issue.

Have anyone ever met a similar struggle or can suggest any fix to this?

Thank you in advance!

@karolina.ostrowska can you post the contents of your python node so others can try and reproduce?

Hi @jacob.small, sure thing. Find attached the code:

Mullions.dyn (6.7 KB)

The python node, however, doesn’t change much since it is just sorting and grouping elements into categories - the same issue appears when the node is skipped.

Ok. I wasn’t sure if there was some sort of magic happening there which we weren’t privy to that could be causing the issue. I recall an issue with certain types of millions from back in the day but the take away is illuding me at the moment.

Can you also let me know what Revit version you’re in? Or have you confirmed this is version agnostic?

I’m on Revit 2018 - didn’t check any other versions but will do so later on other computer.

The continuous mullions are the ones that return surfaces/lines rather than a solid - I’m not sure why but I’d guess it is because the individual segment geometry is exploded and regenerated to show as a single, continuous piece of geometry.

You can filter your Element.Geometry output by connecting an Object.Type node, and then List.ContainsItem @L2 with “Autodesk.DesignScript.Geometry.Solid”. To convert them to solids, you could filter out the lines which are the mullion profile (maybe filter by length and plane), and do Solid.BySweep using Mullion.LocationCurve as the path.

Another option that would work if they are all rectangular mullions, would be to use Mullion.AsFamilyInstance then Element.ElementType to get the Family Type, get the dimensions parameter values, and construct a rectangle by cs,width and length, using the Mullion.LocationCurve Start Point to create a coordinate system for each. Then this rectangle can be used as the profile for Solid.BySweep

I came to many of the same conclusions as @awilliams, the continuous ones are the issue here. After some additional thought though, I wonder if getting the geometry is more than you need.

Calculating volume on these should be SweepLength * ProfileArea, right?. Have you considered getting the length of the grid segment and multiplying it by the area of the profile? This would remove the need to recreate and manipulate the geometry, which is slow no matter how you do it.

1 Like

@awilliams, @jacob.small thank you for your input - it makes some wicked sense. I was thinking of a similar workaround as you suggested, but it becomes a true pain considering the bigger picture.

Let me add a little context: I’m working on a script for caltulating stability of a floating house (sic!). For reasonable outputs I need a precise model out of which I can derive all the necessary data. So it is not just volume I need: I need to compute masses, centers of masses, moments of inertia, etc. And I do so for every single model element: walls, floors, furniture, stairs, balusters, pipes and all. So what I basicaly do is select a scope of a model, sort things info categories (the python script you asked about), retieve their geometry and then proceed with further computations.

Apparently it is only mullions that require a separate approach, which is pretty frustrating. I’m actually considering modeling the mullions separately with component in place or generating them on curtain grids with Dynamo prior to running my script - didn’t try it just yet, but it seems like it could work.

In that case you can do the following:

You can filter the mullions which give you only surface geometry join all the surfaces in one polysurface and then use Polysurface.Extract solids to reconstruct the solid geometry.

2 Likes

Why bother filtering. Your approach can be applied to all mullions, continuous or not

6 Likes

@Vikram_Subbaiah good catch! I’ll give it a try. It definitely simplifies the whole procedure

@Vikram_Subbaiah

I don’t really know which method would prove faster. My idea of the filtering is to do these operations only when needed. Certainly, without filtering them, it’s way simpler

Ok, so I’ve been experimenting with the actual wall I need to analyse and wasn’t able to reach any major success. I decided to go for extracting mullions and panels for each of my curtain walls separately, which will allow me to organize mullions and panels by host.

With joined faces I keep getting the same result for vertical mullions:

I guess that for some reasons these mullions are missing one of the surfaces so they are not fully enclosed and that is the basic reason.

I’m attaching the files so you can see:

CurtainWall.rvt (1.3 MB)

CurtainWall.dyn (4.8 KB)

Аt first I thought it’s caused by the missing flatten node, but when I added it I got this result:

No sloped mullions. Probably some of the mullions intersect the others, I’m not sure.

However when I tried filtering the “surface-made” mullions it looks good:

Thanks a lot! It works, indeed. The only problem is that flattening part ruins my patently built data structure I need my mullions to be associated with its hosting curtain wall (I have more than one). But I think I can overcome it with a python script, so yeah. This will probably do.

Nonetheless, it’s a pity that we even have to deal with this kind of issue at all.

Thank you all for your contributions!

Try making it a custom node so the list of millions can be processed individually.

1 Like

See if this helps, mullions and solids remain in sync (flattening avoided)

Polysurfaces are capped to make them all closed containers

mullionGeometry.dyn (7.7 KB)

4 Likes

Yup! That is exactly what I did in my approach. Thank you very much!

Question solved

1 Like

Hi @karolina.ostrowska ! how did you get moment of inertia by the script!?? Thanks in advance!

Hi @ftotaro!

I eventually didn’t get it by the script. However, I retrieved all the data needed, that is, volumes and material density that I used to calculate masses, and coordinates with regards to the origin point. Then I calculated the moment of inertia in Excel. Nonetheless, you can calculate it in Dynamo with simple mathematical calculations which involve the aforementioned data.