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)

[Cumberland]

Sorry for the late response, overlooked this tread somehow.
Yes, this is what I do need, to separate the points that are colliding with the top surface projected in Z direction from the ones that are not colliding.

Unfortunately this algorithm it is not working properly as I do have some points mismatching the group in which they should be.

[inno]

how much is important that you are actualling using matching data trees to get your result?

because you could -wrong on many levels- just flatten everything, isovist along Z and GGs, which would work ok if all you need is a visual verification (btw, any intersection method will work)

ProjectPoint_StrangeResult_flatten_everything_and_GG.gh (119.7 KB)

in alternative, because the tree mismatch @magicteddy noticed is somehow generated upstream in your definition, in order to do things the best way, I would make some changes in the part of definition that comes before your “Points to project” and “Surfaces to project” and generates those data trees, because the problem is there

[Cumberland]

Thank you. It is working now.