I have been having some problems with the BoundingBox.IsEmpty and BoundingBox.Contains nodes. I figured I could pass in a list of bounding boxes and a list of points and something like BoundingBox.IsEmpty would return a true/false result for any box that contained a point from the point list. This seems not to be the case as I get a list of entirely ‘False’ entries. I have even tried making a sphere at each point location thinking that a point wouldnt trigger the empty criteria of the node.
Is there anyway to cycle each entry in the sublist of points into the BoundingBox.Contains node, or make the BoundingBox.IsEmpty node look at entire list of bounding boxes?
hmm that seems to return some true values. I get a list of 180 true values, but for some reason that bounding box dosent tie back to the specific revit family it was created from? What I was trying to do is pass a string to a revit family based on the True/False Result. Right now the first 180 revit family entities get the modified parameter not the 180 actually associated with the bounding box that returned the true result.
Could you develop your Geometry.BoundingBox and BoundingBox.Contains nodes to show the resulting lists?
(use Springs.Watch+ to display the data’s in a pop-up if needed)
@Yna_Db I have my new BoundingBox.Contains list but due to checking 180 points in 550 cubes I have 99000 results. (180x550=99000), to @Kulkul’s point I’m not quite sure how to take something like a list of 550 entries from an Element.Id node and compare that with the 99K results of the BoundingBox.Contains list??
What does your list look like that is coming out of the contains node. You don’t want to flatten the list. you need to manage the data.
What is the end result as well. do you just need to know if the bounding box contains a single point or all the points? Or vise versa do you need to know if a point is in the box?
I have not gotten a chance to try @Steven_Hansen’s solution yet.
But as an higher level overview I am trying to track soil excavation by adding a parameter to 1 cubic yard cubes that are above a topo surface. This topo surface would be updated weekly and the script rerun. Each cube has a very specific set of parameters so I cant combine them.
The way it currently works is i group the ‘stack’ of cubes, and then draw a line between the top and the bottom cube and find the intersection of that line and the topo surface.
What I need to do is then isolate the cube, or cubes, in that stack that has a centroid z value above the z value of the new intersection point and pass a new parameter to it. This however has proved much much more difficult than I thought.
I have gotten a primitive version of the script to work, not uploaded, but due to the scale that I need to run it at (11 acres and 24 feet deep) it would take an estimated 25 days to complete. This was mostly because I checked every single cube against every single intersection point causing for tremendous amounts of unneeded calculation.
@lmanos
Although I find the topic particularly interessant, I can’t go further for today. I just want to share what it inspires me: I would indeed follow the track of joining the cubes (only in Dynamo for selection purpose, not the originals) but using this method:
This way you get the volume over your topography and it’s probably possible to select the cubes that intersect with that resulting volume (I didn’t try but I will if I find the time for it). You could need some nodes such as Solid.ByUnion and Polysurface.Surfaces.
This blog is a great source concerning your topic and @jostein_olsen is always willing to help…
Ok, @Yna_Db, I’ll bite… I may be misunderstanding your issue here, but I would not go through all that sorting and stacking and intersecting etc. Won’t the point.project node suffice? If I have understood you correctly you can also filter out all the boxes which already have a parameter for excavation date set, right? Then you can try to project all these points toward the toposurface in negative Z direction. If it fails it means that the centroid is below the surface and will return empty list. then a simple sorting and then you have all your boxes above your topography which do not already have an excavation date set.
@Steven_Hansen; This seems like it would work however in my sample data set there are 550 cubes, I’m using the FamilyType and the All Elements of Family Type node to compile my list of cubes. The Z intersection list is only 110 items long. This solution only checks cube 1 against intersection point 1, not all 110 items. I’m still looking for a way to compare every cube to every intersection point, or the intersection point specific to that specific stack of cubes.
Your method of selecting should work fine with the script. The intersection list would be less because it is based on the stacks. I am guessing your stacks are 5 cubes tall? Looking back over my script I think you need to change the lacing on >= (at the end) to longest. That should allow it to check ever cube in the stack rather than just the first one.
If you have not found it yet you will also need to get the PointZ from the Geometry.Intersect and feed that into the >=. I guess you cannot check to see if a number is greater than a point who knew.
who knew.