Project Points component gives strange result

[Cumberland]

Hi all. I do created a definition to check if some surfaces can project his centroids into the top surface of the parts but unfortunately I do get strange result. At first glance, looks like the number of branches of the output of the Project Point component it is different than the number of branches from the input ones. How I can solve this issue? I do need to check if the points can be projected into the corresponding surfaces and create booleans True/False values as output.

ProjectPoint_StrangeResult.gh (117.1 KB)

[michaelvollrath]

Hi @Cumberland ,

This is operating as expected.

Take a look at your referenced points vs. geometry in a top down view:

All of your points are in negative space and therefore, as they project/travel in the Z domain there is no surface present for them to project onto.

Hope that helps you!

[Cumberland]

Exactly this it is the idea. To sort the points that are projecting into the top surfaces from the one that are not projecting in any surface and create boolean values accordingly to dispatch the corresponding surfaces associated with that points in two separate branches.

[Cumberland]

Please can somebody help-me to solve this problem? I do tried a lot of options but I can’t find any viable way to solve if a point it is visible from the top surface or not. I do tried a lot of intersection methods but all I do get it’s just nulls everywhere.

[michaelvollrath]

Hi @Cumberland ,

Is this what you are after?

Graph Space:

Model Space:

This separates colliding and non-colliding points into two separate lists while retaining your original data tree structure.

20230919_ProjectPoint_StrangeResult_Response_01a.gh (123.1 KB)

[magicteddy]

cough cough

Add branches {13} and {16} in the points and your data trees will be fine.

[michaelvollrath]

Nice! I did not see the tree difference How do you add missing branches?

EDIT:

Two ideas I came up with quick but both seem convoluted:

[magicteddy]

The best way would probably to not remove them in the first place, but you can play with Merge and Flatten like this.

[michaelvollrath]

@magicteddy

not remove them in the first place

I agree, that would be what I would do if it were my data.

The use of Flatten Tree in that way is interesting! I’ve messed around with entwining “empty” branches in the past to manually structure data in certain cases but I like the flatten tree method with specification of an index/branch value.

Thanks for sharing @magicteddy !

EDIT:

To magicteddy’s point, all you need is proper data matching for the Project Point component to perform as expected.

Here’s an updated script illustrating this and playing around with creating a consistent data structure across your pts and surfaces:

Graph Space:

20230919_ProjectPoint_StrangeResult_Response_01b.gh (125.7 KB)