Hello,
It appears that the LB Filter by Normal component does not work when a mesh is input into it. The same is also happening with the old legacy version of the component. Is it a bug?
Hi @Matteo I think you found a bug, the tooltip for _geometry:
_geometry: Rhino Breps and/or Rhino Meshes which will be broken down into individual
planar faces and filtered based on the direction they face.
Specifies that the component will accept meshes, but in the code there doesnât seem to be anything for handling meshes, if Iâm not mistaken.
@chris is this a bug?
Hi @TrevorFedyna and thank you,
Yes exactly, the description talks about meshes, but an error pops up when mesh geometry is connected. Hopefully @chris can confirm the presence of a bug.
Best
Matteo
Hello @TrevorFedyna,
any updates regarding this bug? Is there a plan to fix it in the next update? Iâm currently converting mesh to Brep to get use of it right now, but it is not optimal 
Hi @Matteo if you change the type hint to no type hint or âgeometry baseâ the issue seems to go away.
Thank you for fixing the issue!
1 Like
Hello again @TrevorFedyna,
I really think the LB Filter by Normal component is still very problematic when working with meshes. I noticed that inputting a mesh with a certain number of faces to operate a filter by normal operation does not return a mesh as output, but trimmed surfaces instead. Ideally, I would expect the component to return a mesh with only the original mesh faces that meet the criteria set in the filter. This would be useful when working with a mesh of, for example, solar irradiation results and want to select only the areas with a certain orientation. The fact that input and output have not the same number of faces introduced problems in the post process of the results.
Could it be a good idea when inputting a mesh to have as output the mesh faces with the required orientation of the original mesh?
Thanks in advance!
Matteo
P.S. I leave here an example but the issue is easily visible when inputting any mesh by seeing the output (surfaces - instead of mesh faces)
Mesh_to_surface_output_issue.gh (151.8 KB)
Yes, that is because meshes usually donât have a single normal direction. They are composed of multiple faces that can be facing all different directions. So, to filter them by normal, they need to be converted into individual planar faces so that a normal direction can be evaluated.
You can always mesh the geometries again after they are output from the component and then join them. But you canât evaluate the normal of a geometry that faces all different directions so youâll have to be more specific about what you want to happen in these cases if the current output does not meet your expectations.
FYI, are you just looking to cull mesh faces that point in a certain direction, this is very straightforward to do with native Grasshopper components:
cull_mesh_by_normal.gh (30.2 KB)
You donât need anything fancy like âFilter By Normalâ for this case.
Hello @chris and thank you for taking time to look into it.
I am aware of the fact that a mesh is made of multiple faces, each of them with a different direction, and that the evaluation requires to planarize faces and calculate their normal direction. And this is exactly what I want to do, since I have a starting colored-mesh of letâs say radiation results, and I want to divide it into sub-meshes based on their orientation (N, S, E, W facades, and roof).
What I am trying to point out is that there is a mismatch between the number of mesh faces getting into the component, and the Brep output that is generated. This makes impossible to accurately re-match each radiation result to the face it originally belongs to, since the number is not anymore the same.
I leave here an example that clearly show this problem to better visualize the issue.
Some geometrical overlapping/problem is also visible in the resulting geometry. I donât know why this is happening, but Iâm suspecting that something goes wrong in the conversion of the geometry from Mesh to Brep inside of the component and thatâs why I was suggesting to have as output the original mesh with all the faces not meeting the criteria culled out to avoid the problem.
Example_problem.gh (140.8 KB)
Hope this help to better frame the problem,
Matteo
Here is another example of the issue happening at face level. It looks like sometimes something goes wrong in the conversion of quad mesh faces that get split in two, thus generating more faces in the output. Moreover the split happens with some problems and the two new faces partially overlap.
FYI
I managed to implement what I wanted to achieve with native grasshopper components by doing operations with normal vectors of the mesh faces. However, I would still like to understand what is going on there
Hey @Matteo ,
With the sample file you provided and a model tolerance of 0.01, I was not able to recreate the situation that you are talking about in Rhino 8:
⌠nor can I recreate it in Rhino 7:
What version of Rhino are you using and what is the tolerance of your Rhino document?
Also, do you have the exact mesh from your last screenshot?
Hey @Matteo ,
Even though I didnât recreate your issue with your sample files, I think I figured out what is going on. You must have set the model tolerance to something very small like a micron and so you have a lot of quad faces in your mesh, which are evaluating as non-planar. Rhino permits the creation of non-planar quad mesh faces and hopefully itâs obvious that youâre stretching the definition of the orientation of the mesh face when it is not planar because it no longer has one orientation but several.
The to_face3d method that we wrote to translate Rhino Breps and Meshes into planar geometries for Ladybug Tools typically converts the non-planar quads to two triangles in order to keep things planar. This is why you have more faces in the output than you have in the input Mesh. So everything is working as it was designed in order to give you geometries that are filtered by their orientation.
Still, I understand what you want to get for this case and non-planar quads in a Mesh arenât going to be so non-planar that they completely violate the idea of orientation (like the way that a sphere or cylinder would). So I made some adjustments to the component such that it will keep the non-planar quads as quads when translating them to Ladybug Tools geometry formats:
I also verified that this all works using a simple sample of a non-planar quad mesh face:
creating_non_planar_mesh_face.gh (11.1 KB)
So just run the LB Versioner component and you should be able to get what you were expecting for this case.
3 Likes
Hi @chris,
yes, you were right about the tolerance. In the Rhino 7 file where I am experiencing the problem the tolerance was, for some reason, set to 1e-06.
Thank you for the explanation and the fix you implemented to the component to account for this specific case!