Ramp Clearance Height graph

Hello all. I am new to Dynamo (2nd week) and a beginner at Python but I was tasked with creating a script that would check for head clearance on specifically ramps. I couldn’t find anything similar so I finally made a version to work but am looking for any feedback on a way to make it simpler or less processing intensive. I am sure my graph is riddled with mistakes or pet peeves to other programmers, but I would really appreciate any info. If this is inappropriate here or there are any issues, please let me know and I will take it down. Thank you.
heightCheckRamp_test.dyn (302.9 KB)

Currently it only works if there is more than 1 ramp in the drawing and haven’t done a full test on how it reacts to linked files. It is also in metric and uses Revit 2016 and Dynamo 1.3.2, with the LunchBox for Dynamo package.

Below I will try to list my reasoning for the methods I chose if you care to read:

The first idea was to create an extrusion and look for any solid intersections but with ramps that curve in x, y, and z, the extrusions between two ramps next to each other left gaps and couldn’t be used. Next idea was for a grid of points with ray tracing to look for interference points, which is what I ultimately did. I know that this will not scale well and doesn’t behave that great when ramp pieces can largely vary in size. To get the grid, I found the top surface of the ramp and used LunchBox’s DivideSurfaceUV to create a UV grid along the surface.
raytrace2

Unfortunately, the grid goes outside the surface when it is of an irregular shape, so the next chunk of nodes tries to eliminate points that do not fall on the surface. This is done by translating up, then shooting down and if it hits the correct floor, it keeps the point. Admittedly, there are a lot of issues with this step and would love to know of a better alternative.

After that, it is a simple raytrace up, if it hits something, it saves the point. If the hit point is within a distance less than a certain amount from the origin point, it creates a filled region on a floor plan, to let the user know there is a clearance issue there.

Hi @kennyb6

This might be of help.

Marcel

2 Likes

I’ve never been a fan of using raytrace for this type of application - it’s too slow and unreliable as you can miss a light fixture, pipe, sprinkler head, exit sign along the wall, etc. And considering that something like this will usually lead to a building inspector or GC pointing a finger at the architect, one theoretical miss is three misses too many.

So for peace of mind I’ve used extrusions instead. This has some trade offs - I’m building geometry which is time consuming, so efficiency in the rest of the graph will be a must. One efficiency gain I had was to ask for surfaces with a normal that is positive in the Z direction instead of running an extra geometry test. Another was to place a family that is the same shape as the ramp. Yes this means I have something physically in the model, but placing it on a reference workset (always off) with a good subcategory allows for easier clash detection when the consultant models update. This also means I was able to use the faster clash detection that’s built into Revit - it’s SIGNIFICANTLY faster than dynamo’s testing.

Anyway, to build the right shape you need to extrude along the Z axis. The thicken node and basic extrusion tools simply extrude along the normal of the plane, which doesn’t help much with this. Instead you should the method which allows for extrusion along a vector, with that vector defined by a Z value equal to your desired headroom.

2 Likes

Thank you for the information! I completely agree that raytraces is the least optimal solution and that it can lead to misses easily. I originally wanted to use extrusions but couldn’t figure out how to “thicken” in just the Z-axis. Do you use the one that requires a curve? Could you elaborate more on what node(s) that would be?

As for using the native clash detection, I thought it doesn’t work with MEP elements? My employer would prefer to not use Navisworks and have the solution be solely in Revit so I have been avoiding clash detection, instead opting for possibly a Geometry.Intersect node, despite its inefficiency. But I am very interested in using this method.

Going off of your direction, I completely remade it to work with interference check in Revit instead of trying to do my own in Dynamo, thank you very much!

Learned how to make extrusions in a certain direction thanks to @Dimitar_Venkov’s post in Thicken by direction

Hmmm… wanna post how you did it? I’m 90% ready to share on my end, but if you’ve already got it done it may be easier for us both if I just edit that.

The extrusion part? It is working on all of my ramps so far. Unfortunately, it doesn’t seem to be working when floors were edited by points as it returns two null surfaces, but seems to work otherwise. I am still trying to fix any kinks. I would be up for collaborating but it is lunch time here so I will post later today.

Also, is there a way to automate the interference checks or include multiple models so I wouldn’t need to do each linked model?

Ok. Here’s what I was working on for you to look over/incorporate.

For the interference check, I used to like having the linked as separate reports because it allows me to distribute the report to the relevant consultant - MEP gets the one with the stuff they need to change, Structure theirs, FP their file, and so on. However that was awhile back, and while some of my larger jobs likely benefited from the set sample sizes That said the BimorphNodes package by @Thomas_Mahon utilizes a similar method.

1 Like


Looks pretty much the same as mine using your help. The only real difference is that I had to use 0.5 as the value to check if greater than for normal vector because my ramps were giving me vectors with Z as 1.222e10 etc due to how they were curved by whoever made the model.

An issue that I have been having is that when I try to use the same method for floors, I sometimes get multiple top faces for a single floor element, and when I isolate it, it gets weird. I will post a picture soon. But when it gives me multiple top faces, the entire solid extrude falls apart so I have to fix that first.

Will need to see the exact geometry to understand what’s happening there. Clean everything other than the relevant families and post the .rvt here (or on another file share if you don’t have permissions here yet) and I’ll try and take a look at it tomorrow (it’s a long day so no promises).

1 Like

Okay, thank you so much for all your help. I can post pictures for now and will try to get a .rvt out before I leave.


Both surfaces visible
0_0
Surface at 0 index
0_1
Surface at 1 index
0_1zoom

They both have a positive Z normal vector and not every floor that has 2 surfaces have the ‘main’ one at index 0.

Edit: Now getting a better look at it, it is just this tiny tip that Dynamo counts as a second face I guess. Whoever made the floor geometry just put it as an unconnected but in the same element floor.

Sorry, turns out it is because of a shaft opening that splintered off this piece and Dynamo now counts it as another surface. I guess I will just reorganize the list so each surface is in it’s own list, regardless of what floor it came from, and it should work fine.

Edit: Another update, haha. So the multiple surface issue was fixed just by putting it in its own list and treated as a new solid. But one last error popped up.

So this floor had problems extruding because the Dynamo curve didn’t include a small corner some how so the faces don’t connect fully.


Try making the curves into a polycurve and then extruding that instead of creating faces. Should sidestep the error (I think).

1 Like

Good suggestion but didn’t work.

Interestingly, the polycurve join returned nulls for a few of them but did give me a polycurve for the failed solid.

After testing with more files, I found that some solids aren’t created properly despite no warnings or errors. They will create generic models that are missing a surface so instead of actual solids, they are just some walls. Because of this, if something, lets say a beam, were completely inside of one of these ‘solids’, interference check wouldn’t notice it.

got a file that reproduces this?

Won’t let me upload here but this is a google drive link: https://drive.google.com/file/d/1q68LOdrFPnf1YQ2Gmf9LjvXDLrlTlFtf/view?usp=sharing

It seems almost like it isn’t creating any solids but just a collection of surfaces, and most of the time a surface is missing.


Like this. The selected generic model has a missing side. The one above it has missing sides and a missing top. Can’t figure out why.

Can you put the latest dyn up as well? I want to be sure I can pinpoint the issue of it isn’t the Revit file.

I am using the same dyn file as before. I went through each step of building a single floor that seemed to be having issues originally. I think that the solids are actually fine (albeit display like it is missing sides) but the problem is in the interference check, where it cannot detect interference if an object is entirely inside the generic model. That means I would have to go back to using the Geometry intersect node.