i have the 2 scripts figured out. the forst one takes the space planning blocks and draws walls around them. the second one deletes any overlapping walls. i need a way to combine this two so i dont have to run two different scripts. the Warnings.getwarnings node doesnt have an input
So if I understand correctly, the first script creates the walls - some of which may overlap - and then the second script identifies the overlaps and removes them.
I understand that you’re using the duplicate elements warning to identify overlapping walls, but are you only identifying identical instances or do you also have partial overlaps that need to be cleaned up as well? It seems like you could identify duplicate wall locations before you even create them to avoid duplicating instances in the first place.
it also removes the partially overlapped walls as well. originally i tried the way youre suggesting. i got the points of all the lines and separated them by start points and end points. then removed the duplicates. so for example, if i have to squares overlapping, thats 8 lines, so 16 points, and of those 16, 4 points are overlapping. I couldnt figure out how to pick only 2 of those points THEN convert them back to read as curves, so the script would run. I also didnt know what to do if the lines were partially overlapping. Did some googling and using warning seems to work easier.
It can be confusing if your data is messy, but we can do a lot to make that better. How are you creating the lines in the first place? If you always draw them in the same order (clockwise for instance) it’ll be easier to compare overlapping curves and points. You also don’t have to work with both start points and end points, since, like you said, that gives you more points do deal with and half of them are redundant - you can represent a rectangle with just four edges or with just four points. Focusing on just the start points of a set of curves always moving in the same relative direction will make your data a lot easier to work with.
EDIT: Also, just to answer your original question, there’s now an out of the box node for warnings that includes a document input. You can use that node with a wait/passthrough and a transaction to make sure you’re warnings get pulled from the model after the walls have been created.
the model lines are in a generic family. the family is what we use to space plan our buildings. the family has a 2.5 in offset around the family where the line sits so when you put two families side by side that equals a 5” gap where dynamo draws a generic 5” wall
So the lines have already been created manually (via the family), the first script just places the walls at those locations. You could still check for overlapping curves before creating the walls. Once you have the overlapping curves, it’s easy enough to simplify them into a single curve. It just takes a little consideration to ensure you’re only using the points you need. You can do this by identifying where on the line (either one of the overlapping curves will work) each point falls via its parameter value (Curve.ParameterAtPoint). The minimum and maximum values are the extents of those curves, whether they fully or partially overlap.
I’d revise this workflow entirely.
The easiest way to identify overlapping curve segments is to simply not, and let the geometry engine do this for you.
You might have to revise how you manage the space planning process, or how you build the blocks, or something else, but the core geometry engine can purge overlapping lines in a heartbeat if you leverage the assembly well.
So in an effort to help simplify things, how are you placing the space planning “blocks”, and how are you identifying the various components to place?
Actually, it turns out this isn’t true (in practice anyway).
@solamour @achintya_bhat - Not sure if this is intentional but it feels like PointAtParameter and ParameterAtPoint should work the same way when it comes to handling interactions beyond the physical bounds of the geometry (i.e. <0 or >1).
PointAtParameter allows you to specify a parameter less than 0 or greater than 1 and the node still returns a point extending beyond the line’s “physical” representation.
ParameterAtPoint will handle points outside of these bounds but only returns a minimum parameter of 0 and a maximum parameter of 1. I understand this only works for lines but if it works for one node I think it should work for both. Is this something that can be fixed?
Maybe… but I think it would be detrimental to existing workflows, and this is a bit of an outlier of a workflow. A class for curve network, and a method for removing overlapping segments would be preferable to a change inn behavior for existing nodes, though a new method with the additional override works fine too. I. The meantime, you can filter out points with a parameter greater or less than the minimum works well enough. Or intersect the curve with all other curves, extract the start and endpoint of the intersecting curves while keeping the original curve, and then split the original curve by the points. Join all the curves into one lists and return only one curve for each midpoint. Big lift, sure. But this is a rare need, and the most common reason for this (removing overlapping curves for space planning efforts) has a vastly faster method already available in the topology class.
- Get a surface by patching the bounding centerlines of each space.
- Build a PolySurface from all the surfaces.
- Extract the edges.
- For each edge, count the number of adjacent surfaces - this will be either 1 or 2. If it’s a 2 the edge has a surface on the right and side. If it’s a 1 the edge only has a surface on one side.
- Group the edges by the number of adjacent surfaces.
- For the edges with two adjacent faces extract the curve geometry and draw an interior partition.
- For the edges with one adjacent face extract the curve geometry and draw an exterior wall.
1 Like
Thanks @Nick_Boyts for flagging this. Will need to check with the team, but I’m fairly confident that this was not intentional as we want both nodes to be uniform. Currently one is normalizing while the other is extrapolating if the inputs out of bound. We will investigate this and log accordingly. As @jacob.small flagged, we want to be careful here when we update as it can impact existing workflows. One thing we can do is explore keeping the default behavior as current and add new input as a Boolean value to toggle normalization.
3 Likes