I have been researching this, but can’t for the life of me figure out what is going on. Has anyone experienced that the Point.Project node runs significantly slower when running Dynamo with Revit 2018 than 2017/2016? We have multiple workflows using Mesh.ToPolysurface(Springs) and projecting points to the resulting Polysurface and they have performed rather well in the past. After changing to Revit 2018, they perform significantly slower in the very same projects or hangs itself entirely. The results are the same on multiple workstations.
I’ve looked into this issue some more and found a workaround. Often the points I’m projecting are based on some form of curve. If you project the curve to the PolySurface first and then project the points to the curve afterwards it runs 5000% faster. Went from a 40 minute run to 36 seconds…Does anyone have insight on why this might happen?
Curves are 1-dimensional objects (can be parametrized as [0, 1] , where as surfaces are 2D objects (you need a U and a V parameter to describe them). Solids would add yet another dimension to that and on and on… As you can imagine, any computation would become progressively more difficult the more dimensions you add.
The Autodesk Shape Manager is a convoluted mysterious binary blob. I imagine that the only people who can tell us what’s happening under the hood are under an NDA.
I would guess that it’s to do with triangulation of the surface to calculate the point intersection.
Calculating the projection of a point on a curve is going to be far more lightweight as none of the overheads associated with triangulation, like vertices, edges and faces have to be computed. Triangulation is also going to suffer from mass data redundancy which will also impact on performance.
Fair point (no pun intended!) - maybe its due to the way its been implemented then. It might be worth raising this on the GitHub if you can reproduce the slow down consistently. I’ve hit some unexplained performance issues recently with processes that really shouldn’t execute slowly and one line of enquiry is a possible memory leak.
this sounds crazy and fun. Let’s get to the bottom of this, can you please post a sample file on GitHub.
Does this same behavior happen in revit 2017?
Are you using any revit nodes to reproduce this or can you reproduce this same behavior without touching any revit interaction?
My best guess is that whenever you do curve/surface operations, there’s some form of caching that happens after the (poly)surface’s topological correlations are referenced and reused for every parameter that describes the curve. Where as when you’re doing the same operation with individual points, that heavy computation is done from scratch for each individual point.
This however still doesn’t explain why point projection slowed down relative to 2016/17, unless something very fundamental changed in 2018’s ASM deployment.
@Dimitar_Venkov that seems likely that some kind of spatial hashing data structure is built and reused when a curve is projected, but it’s interesting that this structure can be moved around with the surface and used for later point projections…
My understanding is that @jostein_olsen 's current workflow consists of first projecting the curves and then dividing them into points, as opposed to first dividing them and then projecting all the points. If that’s the case, then you wouldn’t have to move any cache-able structure, the cache structure would just be limited to the scope of this particular curve being projected at the moment. You’d still need to recompute it for each curve, but you’d only have to do that for a few curves as opposed to a few hundred/thousand points.
Wow, thanks for the responses! I’ll try to get som files together, @Michael_Kirschner2. What you say feels about right, @Dimitar_Venkov, but just to clarify: First I discretize the bottom curve in points, then I project the curve, then I project the discretized points to the curve following the surface.
