Room Separators Plane incorrect from RoomSeparator.FromCurve with Curves.FromCADLayers

clockwork
dynamo

#1

Hi all, I’m stuck with this one. I’m trying to create Room Separators from curves generated from bimorph node Curves.FromCADLayers. The script is set up to work with the Dynamo Player so it collects a CAD link from the Active View, filters the CAD.LayerNamesInUse to the layer that will be room separators, creates a sketch plane from the level and then creates room separators.

I thought it should work but I realize the room separators are all coming in at zero elevation regardless of
the SketchPlane. The plane I am creating via SketchPlane.FromPlane shows that the plane origin has a z value corresponding with the level that the CAD plan and active view are associated with; note the Plane.Origin node I stuck in the graph below shows a Z value of 10, and (not shown, sorry) all of the ModelCurve elements from the RoomSeparator.FromCurve node came in at zero.

I’m very confused/curious as to why they are coming in at zero elevation despite being given a SketchPlane at different elevations. Here are sample files if anyone will have a look. Again, run the script when in the Active View where the Room Separators should appear.

Room Separators from Curves from CAD.rvt (612 KB)
RoomSeparators From CurvesFromCADLayers.dyn (20.3 KB)
Level 0.dwg (523.7 KB)
Level 1.dwg (331.5 KB)

Thank you in advance for any insight :slight_smile:


#2

@awilliams try node Curve.PullOntoPlane


#3

Yes this works, thanks @til.shviger but I’m confused about the relationship with Sketch Plane with the RoomSeparator.FromCurve node or rather room separator creation. ModelCurves elevations adjust if you change their SketchPlane so I was assuming that supplying a SketchPlane would put the curves at that plane, I’m just not understanding the difference here :face_with_raised_eyebrow:


#4

it’s a mystery. lines room separation stubbornly cling to the zero level . even if you try to manually move up the dividers, they will disappear


#5

Hi @awilliams, the method to create new room boundaries is a bit odd given that it expects a sketch plane and logic would dictate that the new boundary should be created on that plane regardless of where the source curve is located. However, Revit is strict and expects the reference curve to reside within the sketch plane otherwise it’s deemed invalid, and that’s why the curves need to be projected onto the plane. Also, the API comments for ModelCurve (what room boundaries are) give some more insights:

One other thing I noticed with your graph which may be a ‘gotcha’ with the Dynamo Player is the Python node at the start of your script - it only collects CAD instances in the active view. This may be as-designed, but if not, its worth updating so it collects all CAD instances regardless of view. I’m looking into updating CurveFromCADLayers so curves from view-specific CAD links in plans appear at the correct elevation. If I don’t hit any snags (there are a few unfortunately), I’ll bundle it into v2.2.


#6

CurveFromCADLayers is updated for v2.2 which should prevent these issues from arising in the future. The node now translates curves to the sketch plane of a view if the CAD instance is view-specific and on a plan, area plan or structural plan. All other view types don’t have a sketch plane, so for the time being remain unchanged in behaviour (default to the sketch plane of the curve):


#7

Yes this is why I was confused! I sort of assumed it would behave like setting a workplane, so the z values for those curves would be relative to the plane. Also yes my script intentionally collects the CAD instance in view - the project I am working on has a lot of CAD drawings that I am turning into Revit drawings, so the run time for the script seemed to be proving just as long or longer than running the script per each view (there is more to the graph than what I uploaded here, I cut it down to just the room separator portion). I still have the version that I built to process all the CAD drawings in one swing, so I will try it again with the updated bimoprh package - I’m thinking it will run faster without having to do any post processing on the curves. This is a really useful update for me! Thank you :slight_smile: