I´m experiencing some kind of inaccuracy between Surface mesh (Mesh-UV) and Divide Curve components. What am I doing wrong?
First, I created a cylindrical surface using Sweep component with a vertical line and a circular path BeamsTower.gh (35.3 KB) . Second, the surface is meshed using Mesh-UV component with 10 U and 8 V divisions, for example. However, when I split the circular path into 10 equally spaced points (using Divide Curve component) the points only match with the mesh at X-axis (red). A small drift between the points divided and the mesh is observed as the points get closer to Y-axis (green):
Despite this seems a very small drift, it is very important since the support and force application points do not match with the finite elements mesh (in later Karamba analysis). Would you help me? Thanks!
I think the problem might lie in the way that grasshopper is dividing the curves differently as compared to the surface. Would you think about changing your definition a bit? Seems quite complicated for a relatively simple task.
What I would do is simply create lines between the points that you obtained using divide curve. It’s possible that the curve and surface have different starting points as the deconstruct brep component is known to be a bit wonky
Curve and surface start points are the same. Nothe that the points at X-axis are indistinguishable, whereas the other off-axis points are clearly apart.
I made a simple test using Polar Array (ArrPolar) component to generate a perfectly circular array of points starting from (R,0,0) point (where R is the radius of the tower base) and using the origin as center of rotation BeamsTower2.gh (26.1 KB) . Divide Curve and Polar Array match exactly.
Thus, unless GH* does not know how to accurately rotate (which would be catastrophic), it seems that Mesh-UV component is not working very well… Should this be reported as a bug?
*GH version November 18th (2019) running in Rhinoceros version 6 SR20.
I’m not sure what is causing the problem, but my guess is that it probably has something to do with the mesh U-V component. Maybe @DavidRutten can tell us better? We are probably missing out on something
I think this may be related to the way GH deals with geodesic paths. I don´t exactly know if GH´s Mesh-UV component relies on geodesics, but I figure it out that mesh points are calculated using some kind of iterative and approximate procedure.
I´m also working in some workaround (without Mesh-UV) by calculating the intersection points between geodesic curves and something similar happens… I hope GH´s crew sheds some light on this soon. Thanks!
When you use sweep to create a cylinder, it is nurbs surface which has two degree. But all mesh are only one degree polygons. Once a more-than-one degree nurbs surface is converted to a mesh, them are different on their bases.
Thanks for your contribution, but I think I did not understood you well. You mean that if I use a cylinder instead, the Mesh-UV mapping should agree with the simple Divide Curve points?
PS: I used a sweep to create more complex revolution shapes, the simplest case I figured out was a straight vertical line to generate a cylinder test case.
Ok, you´re right, thanks! But the question here is why if you generate a perfect cylindrical surface (whatever method) a wrong (not-perfect) mesh is obtained with GH´s Mesh-UV component (whatever the nurbs degree is). Sorry, but I don´t understand how nurbs degree explains this.
Because mesh, as a method computing geometry, can never create a real cylinder. Mesh-UV makes a polygon look like your original cylinder, but not a cylinder.
Simply to say, if you want to a real and accurate cylinder, don’t use mesh.
Hi Zhuangjia777, thanks for your comments. I don´t know if I understood you well or if I didn´t explain my problem properly, sorry.
I know that a real cylindrical surface is not a polygonal mesh. I´m using a UV mesh to get the faces and the vertices to generate some desired lines pattern (I didn´t tell to simplify my problem). Such lines will later be used as input for FEA in Karamba. To this end I just expected that the vertices of the mesh were homogeneously distributed, at least in such a simple shape (a cylinder). Unfortunately, they are not since they do not match the points that exactly divide the circle at the base (performed by Divide Curve or ArrPolar) (you can see the snapshot on first post).
I´m sure that an exact solution for this problem, at least in the cylinder surface case, is totally feasible. It is evident that, if I want e.g. 10 circumferential by 8 axial divisions (80 faces) I just have to divide the circumference in 10 equal length arcs and the height in 8 equal segments to obtain 80 faces that approximate the cylinder. Their vertices will lay on the cylinder surface but, of course, the faces will not.
Mesh UV turn surface to mesh. vertices of mesh are on the mesh, while nurbs have control points which are normally out of surface.Mesh vertices and nurbs control points are not matched.
I´ve just made a simple example from scratch MeshUV_inaccuracy.gh (22.3 KB) but now I can´t observe the inaccuracy or drift shown in my first post anymore WTF! There must be something weird in my first GH script that I can´t see. Perhaps your unbiased eyes would shed some light to this. Thanks!
Regarding to the mesh/nurbs issue (that is not the main issue here), as you said, playing with the example it can be seen that the nurbs surfaces (either directly created from Cylinder component or by sweeping a vertical line around a circular path with Sweep1 component) only touch the “expected” surfaces at some points. If one zooms in it can be easily seen. Thanks for the explanation, I thought that nurbs were some kind of perfect surfaces, but now I realise that they are some kind of approximation to the real geometry, e.g. a cylindrical or conical surface.
Hi all! I´ve found what is wrong. Mesh-UV and Divide Curve components are both OK, the problem seems to be RailRev. You can check it in RailRev_Inaccuracy.gh (28.3 KB), where the same surface is generated using three different components: Cylinder, Sweep1, and RailRev. Can you explain why Sweep1 and RailRev perform different in this simple case or is it a bug that should be reported? Thanks!
PS: I used Sweep1 component in the previous script (the one without any problem) because I thought it was used in the first GH script (where I used RailRev instead). Sorry!
