Hi there, I’m trying optimize part of my script.
The top version has the exact data out that I want, however I don’t understand how to achieve this without flattening the entire trees of normals and points. (my full script has substantially more points to search from which slows the script down a lot)
Is it possible for me to get my circles to search for points that are in the same ‘petal’?
Kind regards,
Nick
Data Tree Issue.gh (119.9 KB)
What an odd construct… Using points from DeBrep to create circles…? Even though some are so close together they overlap:
So far I don’t understand the objective? “correct data structure” doesn’t answer that question.
The circles are all in the XY plane, of course, rather than aligned to surface normals.
Hi Joseph,
I am essentially trying to get the average vector for each vertex.
Point In Curve was my initial method of getting each of the vectors that starts at the same location into the same branches to get their average.
Does that make more sense?
My goal is ultimately to offset the brep/mesh by moving each point along these averaged vectors.
Why didn’t you say so? This thread was all about that:
I’m not sure why yet but this code I adapted from the linked thread works on only one branch at a time.
Calling this thread a “data structure issue” is highly misleading 
hahah what should I rename it?
It looks like it’s just picking the normal of one of the adjacent faces? Rather than the avg of all adjacent normals (which is what Im trying to get)
I like Kim’s solution the most, it’s super simple, clean and effective
if you want to deal with breps and surfaces, this samples each surface closest point similarly to Joseph’s solution: flattening the vertex list and rebuilding the tree structure only at the end, 100% relies on Surface Closest Point Distance to be zero… so a a bit more geometrical and a bit less “smart”
but be aware that half of your surfaces are planar, but half are not 
(green/red colors for planar/non_planar)
This version works on multiple branches, even though it uses ‘Flatten’!
Mesh vertex normals (light color) don’t give the same result as average of adjacent surface normals.
I’m not sure I did this correctly? Or whether it matters much?
As suggested by @laurent_delrieu, the white group attempts to “ponderate” by area, meaning multiply surface normal vectors by surface area before getting the average for each vertex.
Thank you so much Joseph, Kim, and inno,
I’ve found a solution that I’m happy with. I was getting a bit obsessed with optimization, as the previous iterations would slow the script down quite a lot when adding more input data.
Despite still having to flatten the points/normals, using ‘closest points’ seems quite fast/light.
Data Tree Issue v2.gh (49.2 KB)
