Trying to create Rhino Brep from DSpolysurface causes dynamo/Revit to crash. I am currently attempting to convert 342 fairly simple geometries. When I operate on 50-60 geometries, it seems to work fine.
Can you share the dyn and anything else which would be needed (rvt file?) to run this?
May be a lack of resources or a memory leak as one thought.
1 Like
The script currently has a DirectShapes node which creates revit geometry. This really slows down the processing. I was hoping that the export to Rhino would go much quicker.
1 Like
Soon as I read the name of the script I said āwell this is going to be a geometry creation taking all the resources so the rhino creation node runs out of gas, crashes and burns issue.ā
Are you clash detecting inside Dynamo (that is using geometry.intersect or geometry.intersects)?
1 Like
No, Im only using dynamo to create the geometry. Im using Navisworks for clash detection. I just need to get the geometry out of Dynamo and into Navisworks with properties.
Oh good. Iāll try and find time to help work through this (and/or your other thread) tomorrow evening. No promises, as I have a lot going on at the moment.
Ok, if you get a chance there is another issue. The relevance of the issue hinges on whether or not we can get the Rhynamo export to work.
Without Rhynamo, I have a python script that exports the DirectShapes to Navisworks. The python script runs without errors, but it does not write the Navisworks file every time. Sometimes it writes the file, other times it does nothing. I cant seem to figure out whats going on with it.
The second issue is probably for another thread.
Thanks!
Update 9/8/17 8am:
I tried running the script this morning and it did not crash the first 4-5 times it ran. Eventually, however, it started crashing again.
Update 9/8/17 11:40am:
I found a way to prevent the crashing, it seems. This is a temporary fix, and there probably should be some level repair to the node that is causing the issue: CreateRhinoGeometry.DS_BrepToRhino
When use List.Chop to break the list of polysurfaces down, it somehow allows the script to fully run. I was able to convert 4,076 polysurfaces in one run (before I experienced crashing at anything over 50-60 polysurfaces)
2 Likes
Sorry to say, but the solution that I listed above only worked for a few hours. Now its back to crashing consistently. How might I get someone to look at the node for bugs?
I have attached the updated filesCollision Detection3.dyn (82.8 KB)
BareFile.rvt (1.3 MB)
Github is the place for that. But it seems that your geometry is more complex than Iād thought, now that I can see it in the preview.
@jacob.small The geometry is not complex, its super simple: take a rectangle, scale it down and copy it to a new location, loft the two rectangles, cap the ends. No complex shapes result from that logic - no curved surfaces, etc. Everything is flat faced, solid geometry.
What you are seeing in the screenshot is 4000 of the solids in a single view, which give the illusion of complexity.
I guess that was my point - each of these surfaces has a unique rotation to form the curves I think Iām seeing. Lots to think about as they arenāt orthogonal, so faces have to be defined by more points or transformed.
This is something that you should report back to Dynamo team. Itās no secret that Dynamo struggles at managing resources and eats a ton of memory/cpu for simple operations. Compound that by the fact that Revit also sucks at managing resources and doesnāt release them until after you close the session, and you got a recipe for disaster. Take a few thousands of elements and copy them around, enable some preview bubbles in dynamo and soon enough you will crash. Can you do this stuff all over again, and watch your memory usage. I have a feeling this is whatās causing the issue here.
@jacob.small I guess, my version of complex is much different from Rhynamo complex, lol. Thanks!
@Konrad_K_Sobon. Thanks for the insight. I have looked at CPU usage while running, and its hard to tell whatās happening with regard to resources because Revit instantly stops responding and then crashes fairly quickly. I will try to take a screen grab of it.
Maybe there is a way to do what I am trying to do through python? I found that running some operations through python significantly reduces run time. Unfortunately, I donāt know how to access Rhynamo classes and whatever namespace to write it out. Any ideas?
I will send to issue over to the dynamo team as well.
Iāve used screencast to watch the system resources before with decent success (although it also uses resourcesā¦).
1 Like
Hi Pierre,
Are you running your script per seat section? Iāve run it and it works ok for 350 Solids (and Polysurfaces). How do you end up with 4076 PolySurfaces?
I removed the list chop as I donāt know why you need it:
Collision Detection3.dyn (82.2 KB)
These are the specs of my computer:
1 Like
@Giovanni_Brogiolo, Thanks and Iām glad to see that the script is workingā¦thatās a good sign for me.
It was working temporarily for me, it ran fine for several hours, then started crashing. It is still crashing today, and I have a co-worker testing on their computer right now.
My responses to your questions :
-
the script is meant to be run per section, however, I would like to allow functionality for the script to be run on several or all sections if the user desires.
-
I temporarily modified the script to operate on all seats in order to check the āworst case scenarioā. I corrected this modification prior to uploading the file.
specs:
Hi Pierre,
This morning I tried to re run the script and I was getting the same errors/crashing that you have experienced. The same happens if I use my laptop.
So I deleted the CreteRhinoGeometry.DS_BrepToRhino node and run the script up to the PolySurface.BySolid node (with all seats selected).
Then I placed the CreteRhinoGeometry.DS_BrepToRhino node and run the script without writing the Rhino file. It took 3 minutes but it did not crash.
Finally I run the script to save the Rhino file and it took 10 seconds:
I think the problem is in the Rhynamo node more than in Dynamo but, as Konrad says, it would be good to report it to the Dynamo team to get a clear answer.
Also the sounds of it (usually runs ok the first time, not so much the second time, etc) makes me think itās a system resources thing. Looking over the shapes and how they were built in the environment, this wasnāt that odd to hear. Due to some overzealous geometry recreation there was something significant redundant builds in the geometry creation, used over what was required - once to make a polyline, to move it to a new location, once to duplicate it for every new location, then making these curves, then making the polylines again, then lofting, then turning the surfaces into a solid, then the solid into BPREP, then BPREP into rhinoā¦ Generally speaking if we can make a shape in one move thing will run better than if we make a shape than get a secondary shape, then get parts from the sub shape, than make a secondary shape to get new partsā¦ And all of this geometry creation is happening in a script that basically makes an entire rhino files worth of geometry in the amount of time it took me to walk to the kitchen to wash my coffee cup. All without saving even once.
Sorry if that comes off as harsh - the script is actually really well thought out and works nicely, but it needed some love in terms of how it delt with the complexity of the graph.
When the data sets are small (ie: a section of seats), you can let it run as is and work with this method. But when they get large (ie: the entire stadium) you need to be as efficient as possible. Some tips to do that:
-
Use code blocks, python, or zero touch nodes to nest functions. This reduces the amount of system resources (remember the results of each run arenāt saved anywhere).
-
Filter your dataset as quickly and efficiently as possible. If one bool mask removes 50% of the items, and another only removes 10% of the total items, then remove the 50% first.
-
Keep geometry simple. As @Konrad_K_Sobon pointed out, Revit and Dynamo arenāt really efficient with resources for geometric stuff. This makes sense as Revit is really a database - you can do BM with Formit or Autocad, but Revit exists to put the I in BIM. DesignScript feels faster for geometry than Revit, but itās still fairly taxing, so best to keep geometry as simple as possible for as long as possible. Points are better than lines, are better than curves, are better than surfaces, are better than solids, are better than meshesā¦ If you have to think hard to perfectly draw several angles of the form, then itās likely a difficult shape to program as well.
In any case, because I wanted to better my understanding of this type of workflow, push the limit of the tools, and the see the total scope and process, I did some reverse engineering on your graph. I removed the UI++ as Iāve had some issues with them interfering with other software outside Dynamo but in the same ecosystem. So I figured it best to leave them alone incase the Rhino authoring suffered similar troubles, but I saw no improvement after removing them.
When I was done modifying things, I ran it on every seat, closed the dyn (just the file not dynamo) and reopened it, and attempted to run it again. The first run took around 3 minutes and used up a lot of resources which never really freed up afterwards (despite closing the file). The second run took longer as my RAM was used up, but time stamps and file creation have it running in under 8 minutes. This doubled time is likely why things were crashing for you before -
there just isnāt enough power to be inefficient with this stuff, and Revit/Dynamo donāt give back the resources when they are done.
However, since the entire stadium worked quickly on the first run, Iām not sure that there is much need for consecutive runs - just do them all at once as it saves steps which saves time. One time to run the dynamo, one time to export Rhino to navisworks, one time to run the clash detection in navisworks, one time to pass data back into revitā¦ you get the idea. If you really wanted you could port the design script into Python and use some list processing to free things up afterwards, but Iām too green with Python to do that right.
Anyway, the final graph consists of about 8 standard nodes and one code block. I did have one crash during the re-build, which felt as if it was related to the 3dm file being overwritten concurrently. Looked like the memory hadnāt cleared and the nodes feeding the write file node passed the old data and then the new data right away, causing dynamo to tell the file to re-write itself with both data sets simultaneously, which is a no-no in computer speak. To help fix this I added a timestamp to the file name so each run will have a new name.
Screenshot:
The DYN:
Collision Detection_JacobSmall_EditForAllSeats.dyn (11.7 KB)
The Design Script Code:
DraftedTarget =
// get the geometry for all filled regions of the given type
List.Clean(
a.GetParameterValueByName(āTypeā).Name==selectedregiontype.Name?
a:
null,
false
).Geometry();
TargetSurfaces =
//generate the target surfaces from the input region
Flatten(
List.Clean(
DSCore.Object.Type(DraftedTarget) ==
"Autodesk.DesignScript.Geometry.Surface"?
DraftedTarget:
null,
false
)
);
ScalingFactor =
/*Create a scaling factor from the length of
the target surface and a 8.4/12 ratio*/
(8.4/12) /
List.MaximumItem(
TargetSurfaces.PerimeterCurves().Length
);
OriginPoint =
/*sets the origin point based on the middle of the target surface*/
TargetSurfaces.PointAtParameter(0.5,0.5);
TargetShape =
/* create the target curves*/
PolyCurve.ByJoinedCurves(
TargetSurfaces.Scale(ScalingFactor).PerimeterCurves()
);
Eyepoints =
b.GetLocation().Translate(Vector.ZAxis(), 44 / 12);
SightVectors =
//Generate a sight vector from the target to each seat
Flatten(Vector.ByTwoPoints(OriginPoint,Eyepoints@-1<1>));
RawSightExtrusions =
//generate an extruced form for clash detection
Flatten(TargetShape.ExtrudeAsSolid(SightVectors@-1<1>));
SightExtrusions =
PolySurface.BySolid(
RawSightExtrusions.Translate(
Vector.ByTwoPoints(
Coordinates.SurveyPoint(),
Coordinates.BasePoint()
)
)
);
ExtrusionsFormatedForRhinoGeometry =
List.Chop(
SightExtrusions,
1
);
SeatNumbers =
//Generate seat number values
"SEC:" +
b.GetParameterValueByName("Seat Section") +
"__Row: " +
b.GetParameterValueByName("Seat Row") +
"__Seat: " +
b.GetParameterValueByName("Seat Number");
MinuteOfDay =
DSCore.TimeSpan.TotalMinutes(
DSCore.DateTime.TimeOfDay(
DSCore.DateTime.Now
)
)+"";
Timestamp =
String.Remove(
MinuteOfDay,
String.IndexOf(MinuteOfDay,"."),
String.Length(MinuteOfDay) -
String.IndexOf(MinuteOfDay,".")
);
RawRhinoGeom =
Flatten(
CreateRhinoGeometry.DS_BrepToRhino(
ExtrusionsFormatedForRhinoGeometry
)
);
BoolList =
DSCore.Object.IsNull(RawRhinoGeom);
RhinoGeom =
List.LastItem(
List.FilterByBoolMask(RawRhinoGeom,BoolList)
);
RhinoNames =
List.LastItem(
List.FilterByBoolMask(SeatNumbers, BoolList)
);
RhinoColor =
CreateRhinoObjects.Create_RhinoColor(0, 0, 0);
RhinoLayer =
CreateRhinoObjects.Create_RhinoLayer("cones", RhinoColor);
RhinoDocLocation =
String.Substring(
Document.Current.FilePath,
0,
String.LastIndexOf(
Document.Current.FilePath,".",false
)
)+"AllSeats - "+Timestamp+".3dm";
RhinoObjects =
CreateRhinoObjects.Create_RhinoObject(
RhinoGeom,
RhinoNames,
RhinoColor,
RhinoLayer
);
2 Likes