Grouping Vectors by their AngleAboutAxis and I’m getting multiple uniqueKeys that are the same but listed as different groups. That’s… not right… right?
If I Round to 0 digits it collapses into the smaller list but the values from the Vector.AngleAboutAxis don’t appear to have decimal components.
Rounding to 15 digits shows the same as the first post.
Try rounding and converting the angles to a string. Dynamo only shows so precise measurements on the surface, that behind the scenes might not be equal.
The values shown in a data preview or in a watch node apply some degree of rounding - I think 12 digits but I may be getting confused between platforms/languages - I know Revit caps at 12.
Typically I recommend rounding to 0, 3 or 6 digits of precision for any comparison effort, if only to avoid floating point issues. The number of digits depends on the accuracy needed - for angles I typically recommend 6, but for length in mm I recommend 0 and length in other units I recommend 3.
1 Like
And after 12 decimal places it just says “close enough but not so close that they’re the same?”
-bleh-
I’m assuming this other issue is related – I created a series of vectors from spherical/cylindircal coordinates and then moved points along those vectors with various lengths – if I check the vector of a line through the original and new point most are the same as the vector I used but some are off by 0.00000001 degree or something. I assume that’s rounding relative to the location of the points. Should I just assume they’re the same and keep going?
This is a rounding issue as well by the sounds of it. Since you created the lines from the vectors you shouldn’t need to sort or group though - just adjust the lacing and list level instead.
Next step in this process is to find all lines that are colinear (exist in the same vertical plane). I’ve already grouped them by parallel (or at least by angle and reciprocal angle), and proximity (Geometry.GroupByDistance). Ultimately trying to get Walls created from DWG layers.
Ewwwww. Ewwwwwww. Ick. Ewwwwwwwww.
Ok, my venting about the disaster which is using DWGs to generate Revit content is over…
Do you care about the length of overlapping curves? I.e. if a curve runs from 0,0 to 10,0 on level 1 but from 3,0 to 7,0 on level 2 are they the same?
100% Ewwwww. Ewwwwwww. Ick. Ewwwwwwwww.
Do you care about the length of overlapping curves? I.e. if a curve runs from 0,0 to 10,0 on level 1 but from 3,0 to 7,0 on level 2 are they the same?
No, I’m doing this level-by-level. Don’t judge this too harshly. 
DWG Layers to Revit Walls.dyn (515.5 KB)
So you are after co-linear lines at the same elevation? If they touch or not?
As the next step, yes. Then another Geometry.GroupByDistance to get lines on either side of assumed openings. The extents of those groups define new curves for the Wall.
I have a working version but it’s slow (obviously with so many Geometry tests) and somewhere in the graph I’ve allowed lines to move off the vectors I’d set so I’m going back through rethinking the logic to see if there’s a better solution.
Honestly, I would take a step back and take stock of things.
How much ‘after the fact QA’ are you willing to tolerate here?
If the tool combines walls across a hallway will you be ok with that? Someone is going to have to manually review every line if not.
How much of this are you really doing? Is this tool being used 100x a year, or 5x a year?
How standardized is the underlaying data if it is 100x? What if it is 5x?
A semi-decent intern can trace a CAD plan in an hour and they cost peanuts. I am guessing that you have already bought six plans which is less than I think I see.
So, rather than boiling the ocean, would a targeted option be better suited? Perhaps a ‘select the exterior wall faces’ be a better option?
Or maybe ‘select the rooms to build walls for’ as an alternative? Gathering all rooms (voids in plan), offsetting outwards by 1/2 the distance to the next room, patching to surfaces and unioning to polysurfaces is a pretty efficient workflow. And deriving wall types and placing walls on the identified boundaries is rather simple by comparison and processes easier…
Always best to aim at having the computer assisting the human, not replacing them as the computer can’t make decisions.
1 Like
All great points.
We are in healthcare and almost all of the existing facilities we work on have shit for existing conditions documentation. The design team has, for years, taken a hybrid DWG/RVT approach and the models have, IMO, suffered long term as a result. They all but refuse to consider other approaches going so far as to convert PDF to DWG when the owner didn’t have a DWG.
The way I -understand- the issue with DWG in Revit comes down to how each program does math and how they define numbers and that tracing DWG in particular is very bad as a consequence. I’m sure that’s not 100% right but it -feels- close enough.
My thinking then is if I can get Dynamo to recreate the floor plan using lines derived from the DWG we might be able to find a middle ground.
In a nutshell then, that DYN gets vectors and angles of lines about an axis, rounds those angles to remove the BS, and recreates them based on these new angles. Then it groups parallels and further groups lines within some assumed average wall thickness. Find the middle of those groups and create yet more lines representing the -center-. Finally find the collinear lines and group by some assumed max door width to create MORE lines and use those for Wall centers!
Yeah, it’s going to take a lot of QA and I know I could trace it almost as fast (or faster) but most here couldn’t. And more importantly, won’t (not to mention embedding the traced DWG issue into the model).
I also don’t trust those DWG files at all. 5” walls all over the place… and how exactly do we figure they built a 5” wall? Oh, right, they didn’t. Until it’s verified in field it’s all best guess (based on experience) and that’s not a job for an intern.
That was a bit of a rant, wasn’t it?
Had the same challenge with the same sector in Australia. We went a fair way down this path and got eaten alive by fringe cases. Just when you think you catch them all you get another, whether its a door block on the wall layer that got exploded, or non plumb walls, lines on lines etc.
Sadly, the most viable solution I’ve experienced is currently to ship this overseas on the cheap. Hopefully all those AI evangelists will find a solution down the line.
2 Likes
The computer can only do a worse job in the area of guessing though. And you still haven’t reached the ugly DWGs generated from a PDF… the existing conditions have to be documented either way as a result.
I think it would be worth looking into a few things before you go further.
-
Do some of the processing in the DWG as a prep step by way of Dynamo for Civil 3D. Extract the groups to new layers, or write the center lines, or otherwise reduce the main step. You could use Revit here as well and write to an intermediate DWG file (the new native DWG write out nodes can help) or JSON or something, but the root of the problem is the DWGs and the staff is comfortable there so meet them in the middle rather than dragging them across. Statements like ‘I generated the centerlines, can you validate and join adjacent curves for me?’ will go a long way towards building allies instead of ‘we use Revit now, so you need to figure out how the intent of the garbage data and clean up the result’. The transition to BIM is a people problem not a tech one.
-
Look into the polylines built in Autocad, or rooms built in Revit and see if you clan make the room offset method work. Again, aim for smaller processing chunks (select rooms in view) or steps into temp files for cleanup. Documenting existing in a way which works is their job as much as yours and if you provide tools to facilitate that you’ll have a team at your back instead of advisories.
-
Look into hiring a company to do the existing conditions documentation for you. They are usually less expensive and will give better results than DWG processing will, and things like the wall thickness will be resolved saving you a ton of issues in advance.
-
Accept some non-standard BIM but QA the hell out of it. It is dumb, but it works for these guys so far. Building some QA scripts which identify where issues are might have more value as you can tell people ‘you have to clean this up so we don’t get sued’ and if you target the DWG caused issues areas that may bring people over to the BIM side as everyone HATES cleaning up CAD work. No one is writing about how faking BIM work and taking shortcuts makes a better product because it is actually more work - use the risks this poses to force the work to be done and you might get some progress.
-
Point out the healthcare jobs that are not an option with this clown show style of work. The most profitable and highest profile projects in health care aren’t doing this. Those projects have BIM requirements which state things like ‘project to be kept in the two most recent releases of Revit’ and ‘no DWG links shall be permitted upon completion of schematic design’ and other things which prevent this type of work. Then point out that your competition does get those jobs by doing things right, and the staff doing this now needs to learn how to qualify for those. That will usually be enough to get an executive sponsor from a principal, and those are the ones who can drive changes by the ‘do it right or face consequences’ path.
1 Like
All good options and even if I get it working I seriously doubt my team will use it. Like you said, it’s a people problem.
Regardless, how might you determine which lines are collinear? Call it professional curiosity. 
Build a vector from point at parameter 0 on both lines, and then get the direction of the first line and ask if the first vector is almost parallel to the second - if so, you’re parallel. If not, discard for the next non-grouped line.
This is not something I would do with nodes.
This is not something I would do with nodes.
But that means I’d need to learn to write and debug code! sad-face emoji
I mean… you could do it with nodes for sure. However it would not be as easy to author and it would be a bit slower.
However I thought of another way while chatting with my niece who is five and has a tendency to throw the phone around while face timing. Anyway, if this makes things easier you owe her an ice cream now.
Starting with your curves grouped by direction.
- Take the coordinate system at parameter 0 from the first curve in the group.
- Transform all the curves in the group from that coordinate system to the identity coordinate system.
- Extract the start point of each curve, and extract the X value of that point and round it to your tolerance.
- Group the original curves by this X value, and sort the groups by the unique keys.
- Extract the Y value of the start point of each curve in the group. Sort each nested group of curves by those values.
- You should now have the groups of curves ordered in rows from minimum to maximum, and sorted from minimum to maximum in the column. Testing the distance from a curve at index n to the curve at index n+1 will give you a clue if they should be combined.
2 Likes