Attach family instance to topographic surface

Hello Dynamo Users,

I am fairly new to Dynamo and would love some assistance with a project I am working on. We have this sitework project and I have to model all of the planters/root balls for MEP coordination, and there will be a few thousand trees installed for this site. I was given the CAD drawing for the tree layout along with the grading file from the designers. With those files I was able to create a Topo from the grading file and in AutoCAD I extracted the (x,y) coordinates of the trees into Microsoft Excel.

What I have done in Dynamo is used the Excel file to get my (x,y) coordinates for my root balls, but the problem I am facing now is attaching it to the Topo. My idea was to get the (x,y) in Dynamo, and then back in Revit I would Select All, Pick New Host, and host it to the Topo. Didn’t realize that Dynamo wouldn’t allow me to do this, so now I am having difficulty in finding the right language to set these root balls to their right Z coordinate. Any help with be greatly appreciated.

Thanks,

Brandon Medina

2015-04-28 11_22_39-Dynamo

May I kindly suggest you do a search for “topo” on this forum? This question has already been answered before. :wink:

Also, have a look at Jostein’s blog: http://jbdynamo.blogspot.no

Thanks for the reference Andreas. I would have tried something like the following, Brandon. Could probably make it more concise, but you get the idea.

slett meg

Thank you for Jostein’s blog page, Andreas. There is a lot of useful information in there. Kudos, Jostein, and thank you for your workflow.

New question: what would you say that maximum amount of points in a given topo should be?

As of now I have the Simply Surface tool set to 1’-0" accuracy, and is giving me almost 40,000 points. I tried running dynamo with this amount. It ran for about 45+ minutes and then I received this error.

2015-05-05 11_14_13-Image Preview

The answer is 42.

Just kidding, obviously… Haven’t got a clue.

You might have to portion it off and link the models into a master Revit file if your running into performance issues. That’s an extreme amount of data :slight_smile:

Hi guys,

This got me very curious and I decided to dissect the work flow and managed to pinpoint a few bottlenecks along the way.

I generated a topo with > 40k points. At that moment Revit itself became quite the bottleneck and started to lag severely on any further attempt to modify the topo element. If I have to put an upper bound to a topo by points, I’d say you generally don’t want to go above 10k points.

First of all you don’t need to split your topo in separate files, you can simply use Massing & Site > Midify Site > Subregion and split the topo into more manageable parts.

DISCLAIMER: don’t try any of the below on your work project. I bear no responsibility for any loss of information or damage incurred in the process of doing so.

The first part of the work flow involved extracting the topo geometry, vertex positions, face indices and index groups. All of that works in just a few seconds.

2015-05-06_22-25-22

The next step involves extracting the vertices belonging to each index group (A, B, C). This is where I found our first culprit - “List.GetItemAtIndex”. That node seems to have a serious memory leak/bottle neck and usually leads to a system crash. Luckily we can avoid using it with some DS syntax.

2015-05-06_22-39-30

Extracting all three groups takes about 10-15 seconds in total. The next challenge is to join and transpose the three lists. The standard List.Transpose function manages that in about 25 ~30 seconds. At this point we’re looking at about 240k points. With some very simple DS syntax, we can cut that time down in half.

2015-05-06_22-46-33

At this point I had do save my process and restart Dynamo and Revit, because memory was not being released after execution of the graph. After reloading. I proceeded to generate the individual surfaces. That took about 100-110 seconds for the 80k faces or roughly 800 faces per second.

2015-05-06_22-53-30

The final challenge was to merge all the faces together. “PolySurface.ByJoinedSurfaces” was the next huge slow-down. It seems to be experiencing a memory leak as well. It usually starts becoming unbearably slow after 100 faces. Going higher than that usually leads to crashes. At this point I decided to get sneaky. I wrapped everything up in a single function and started chopping up the faces to more manageable chunks.

2015-05-06_23-14-06

Ten faces/ polysurfaces at a time seemed to be a decent chunk for the “PolySurface.ByJoinedSurfaces”. About 2 minutes later I ended up with a single PS consisting of ~80k faces. The process peaked at about 6.8GB of memory usage( Revit and Dynamo ate up about 5GB of that), so you’ll want a system with at least 8GB of ram before trying anything like this.

2015-05-06_23-13-37

My conclusion from the above exercise is as follows:

  • Dynamo has an incredibly robust geometry processing engine and can handle tens of thousands of lists, points and surfaces at the same time.

  • Some list management functions need to be reviewed and optimized.

  • Surface / Polysurface creation might need to be further optimized at some point.

  • Memory management should probably be reviewed. What portion of the memory, if any should be released upon completion of the graph?

  • Design script syntax seems to be measurably more powerful, efficient and stable than graphical nodes. Is there a way to transfer some of that back to the graphical nodes?

3 Likes

That’s a Beyond Awesome test Dimitar. Thank you so much for sharing your workflow and thoughts also - it’s exceedingly useful!

Hey guys,

My apologies for taking so long to reply, but I was finally able to try your workflow, Dimitar, and failed completely. I was actually able to reduce the size of control points from the topo to 12k instead of 40k. I tried copying the workflow verbatim and also changed some things around to see if it would work, but nope. I kept getting a transpose1 not valid or something like that and “Error: “{” expected.” I also tried “42” but that didn’t work either.

2015-05-17 12_47_52-Dynamo

 

 

 

 

 

 

 

I ended up using the graphical nodes which most is not as sufficient, and took an incredibly long time to complete, but I was finally able to create a surface from the topo (appoximately 30 minutes to finish.) I thought my problems were over but I still haven’t been able to extract the Z value of the root balls that need to be installed for the site. I’ve tried using the “Point.Project” and “Geometry.Intersect” nodes to get the Z value, but for some reason I don’t think it is reading the surface when intersecting. Getting an “Empty List.”

2015-05-18 16_44_44-Dynamo

 

 

 

 

 

I was hoping to create a new excel file with all XYZ coordinates to send to the design team, but I just can’t get that Z value!!!

2015-05-18 16_45_21-Dynamo

 

 

 

 

 

The only thing that has worked for me so far is using the “Topography.Surface” node from package manager. The problem with that node is that it will not run with the whole 10k topo. I have to split it into multiple surfaces that have to be under 1k, because even when I run it with 1k points it takes about 20 minutes to finish. Oh and I have been maxing out my memory peaking at 15.8GB (Revit and Dynamo were using up about 12GB)

Anymore ideas?

I I may interject into this conversation I would only add that ANYTIME YOU CONVERT A MESH INTO A SURFACE its a very expensive geometrical operation. There is a reason meshes are not made out of surfaces but instead hold a topological information about their surfaces. I understand that Dynamo doesn’t have a good mesh intersection tools, but Rhino does. I would suggest using the right tool for this job and either use Rhynamo or Mantis Shrimp to get your mesh/points to Rhino/Grasshopper and go from there. There is no reason to subject revit to this enormously heavy operation.

2 Likes

Thanks for your input, Konrad. I will give Rhino a try.

I think it could be interesting to find a workflow in the dynamo environment for those that doesn’t have Rhino. Maybe we could skip the surface part and stay with meshes? Couldn’t the Moller - Trumbore intersection algorithm for instance, be used to get the intersection between a ray and a plane? My knowledge in math and programming is inferior, but someone in here are surely capable. Got nothing to give in return but honor and glory though…

1 Like