I need to intersect tow big lists. each element from the first list has to intersect with all elements from the other list. but with the dynamo node (Geometry.Doesintersect) i get a memory problem, the computer could not handle the amount of possibilities or the length of the output list.
i have tried to use for loop via python but it didn’t work as well.
does anyone have an idea?
it feels like i need to free the memory each time i intersect an element from list a with an element from list b.Intersecttion test python.dyn (42.8 KB)
Look into the Bimorph package and utilize Revit’s built in intersection checker. Then when you have the list of intersecting elements do the actual intersecting directly.
Thomas, thanks for contribution. if you open the Dynamo script i have attached you will see that I meant with two lists of elements a list of 360 lines and a list of 4680 generic models, then i need a Boolean list.
the result would be a list of 1684800 values. i think they would take more than two seconds
it would be great if you have an idea on how to solve it in python. as you can see i have already created a for loop that check if each line in the first list does intersect with each geometry in the second list, but i miss the part that keep the memory of my computer relax and happy…
also we are not allowed to use custom nodes made in visual studio.
Not attacking you here but providing some insight so you can hopefully turn around a ham fisted policy.
Your security team needs to take a minute to do some serious consideration of the ramifications of this statement. “We are not allowed to use DLL based custom nodes” is to Dynamo as “we are not allowed to use Families” is to Revit. That basically means we aren’t doing computaionally droven BIM at a high level. Add-ins and PyRevit will also have to be completely out (can’t trust those either as they pose the same or even a greater security risk). Overall that will cost you months of production time on every project. So your fees or deliverable timeframes will have to be bigger by a pretty wide margin. When you’re charging or setting timelines which are measured in months suddenly things look pretty dim for the survival of your firm. I suppose you could hire an army of coders to reproduce the work of others, but your competitors will be leveraging the community and avoiding that overhead… all bad signs.
Remember, the attack vectors are far greater in number and severity here than they are in Dynamo, and yet you have managed to connect to the web.
Back to the topic:
The Bimorph method will work, but if you can’t get to it for paranoia reasons, try writing some python that reproduces the function.
we just don’t want to use dll based nodes from sources we don’t know.
i don’t understand why your had to replying this way. i have a question and i want an answer in a way that fits the work i’m doing.
it is paranoia reasons when you get disappointed because i need a solution in other way.
I need an answer from some one who is good in python.
My suggestion would be that rather than a For loop, you can break down the task into While loops? Each of which is no bigger than 100,000 for example?
Please don’t misunderstand Jacob, he is only trying to help, and personally I agree with him.
@jacob.small do you know at what point the Python dumps it’s memory? Is it possible to daisy chain them?
If you do not find the Python solution, you could approach Thomas through his company BiMorph https://bimorph.com/ and perhaps you can purchase his software services in the same way you are happy to do with Autodesk?
@Mohamad_Kayali - this wasn’t an attack or intended to dissuade you, just wanted you (and by extension your employer) to realize how much this will hamper your efforts. To say ‘we don’t want to use random code someone found online’ is one thing, but to say we don’t want to use a major package from a well respected consultancy is a step further than most should go. If it’s right for you, then by all means.
Has to be managed inside the program. Best to pursue this from a purely python perspective first, then look into it from an Iron Python view, before finally testing it with Dynamo. PyRevit might be more efficient as an alternative to avoid that last hump.
Thanks for clarifying what you are looking to achieve. More information means better answers.
Moving this into Python isn’t going to help you since your source solids are ProtoGeometry (Dynamo) solids which means you’ve got two options:
You can use Dynamo’s geometry library to perform the intersections - using say DoesIntersect, but its clunky, inefficient and will hammer your memory even with a small number of elements which makes ideal for…a bungalow with four walls… so it simply isn’t viable for your requirements. My recommendations is always to avoid Dynamo’s ProtoGeometry library like the plague - if you are in Dynamo for Revit, transfer your application into Revit as quickly as possible, then only output to Dynamo at the end, if at all given how bad its geometry engine is.
You can repeat what Element.IntersectsSolid does, however you can see there’s a geometry conversion limitation - basically, you need to rebuild the Solid from Dynamo as a Revit API solid (which is also computationally expensive) using its ShapeBuilder, but there’s a catch, if the geometry is cylindrical it almost always fails due to the faces grouping at the perimeter of the circular caps and there’s little way around it.
Really, Revit’s geometry engine is dated and limited, and Dynamo is effectively an external application despite it being developed by the same software vendor so geometry conversion is a minefield and prone to failures.
Your best best is to create a family, like a circular column or something, whereby you can model those vertical extrusions as native Revit elements and bypass the geometry conversion process completely. You can then use Element.IntersectsElement, or if your company policy prohibits the use of unlicenced software, the link below from Jeremy Tammick covers the basics for using the ElementIntersectsElementFilter which BimorphNodes uses:
Im having a similar issue with too many dynamo geometry intersecting.and as said above the difference between dynamo and python isnt much.
ive looked into the BIMmorph nodes, the Speed is fantastic. but there are still limitations in the type of Dynamo geometry that can be used. lines and solids. no points or surfaces , or BSplines. also it does not seem to be working with Generative design. but i may not sure about it yet.
ive heard the new dynamocore 2.6 has some major improvements in the polycurve. i hope the same can be said for the intersections in side of Dynamo.
Anyone else care to bring more light on this topic, any other alternative i could try out.
Any node which calls the Revit API will not work with generative design as there is no Revir API access. Post some more info on your process so far and we will see if we can find a path forward.
so i am trying to RUN a generative design graph , from inside revit 2021 and dynamo Sandbox 2.5.
this issue im facing is with the does intersect node. when multiple solids are are intersected with each other, the processing time greatly increase, to the point where dynamo stops working. and when trying to run a similar version of the graph on refinery(generative design), sometimes the results are empty.
i need to intersect 20,000 + cuboids, with 25 other objects.
i Played around with a bit of python to see if there is a difference in the run time, maybe you could check the code and let me know if there is a way to optimize it.
# Load the Python Standard and DesignScript Libraries
import sys
import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *
clr.AddReference('DSCoreNodes')
import DSCore
from DSCore import *
# The inputs to this node will be stored as a list in the IN variables.
otherobjects = IN[1]
cuboid = IN[0]
false = False
cuboidcount = len(cuboid)
otherobjectscount = len(otherobjects)
i=0
j=0
newlist= []
newlist1= []
# Place your code below this line
#solid1 = Surface.Thicken(otherobjects1, 20)
for i in xrange(cuboidcount):
cuboid1 = cuboid[i]
for j in xrange(otherobjectscount):
solid1 = otherobjects[j]
bool1 = solid1.DoesIntersect(cuboid1)
bool2 = str(bool1)
if bool2 == "True" :
cuboid[i] = None
j=j+1
else:
j=j+1
i=i+1
newlist= cuboid
newlist1 = List.Clean(newlist,false)
# Assign your output to the OUT variable.
OUT = newlist1
does the node work faster if different geometry is input , say instead of cuboids , i use surfaces, or points, or BSpline Curves ?
let me know of any other way i could do this task.
A solid will be faster than multiple surfaces, but moving to 2D will likely expedite your results.
For what it is worth using a nurbs curve as one object and 1,000,000 surfaces as the second objects without fail in Refinery. You could try combining all your obstructions into a single solid to reduce the number of tests quite efficiently (Instead of n*y tests you would only have n tests), as you’re not testing individual solids but all of them.
im sorry could you rephrase the refinery comment, I did not understand. it will or will not fail in Refinery ?
so converting the cuboids first as a rectangle or single BSpline and intersecting it with 1000 of surface would work in Refinery ?
Assuming equal number of objects: abstract geometry will be faster than points will be faster than lines will be faster than surfaces will be faster than solids will be faster than meshes. Stay left in the chart here: Geometry Overview | The Dynamo Primer
