(This thread is most probably not related to grasshopper at all…)
Hi all!
I am, here and then, bouncing in and out from Rhino 8 to do shrinkwrap.
Today I tried with grasshopper, I wanted to automatize the post-processing of the mesh… btw…
This gif speak for itself: Rhino 8 pointcloud shrinkwrap bug.gh (472.8 KB)
… changing the target edge length actually change the final result offset distance… ??
I think this is a bug.
Edge length should be the “quality” or “resolution” of the result. Large edge means low resolution, but quick calculation! But the offset should stay the same, as per setting.
(I can easily crash Rhino 8 by dragging quickly the “Edge Length” slider in attached .gh def…)
I can do the same in Rhino 8 with _ShrinkWrap command: same results.
If same settings but a smaller “Target edge length” is used, the mesh output have a smaller offset.
This bug seems to occur only to pointcloud, but I haven’t tested more than 30 seconds with other types…
The edge length is used to describe the edge length size of each spherical blob point (think sphere at the point location) this is why it affects the size thus the “inflate” language is used as you can’t “wrap” a point of 0 thickness. To better illustrate, use 2 or 3 points and increase the edge length. It should become more clear as to what is happening and why.
If the behavior of shrinkwrap with other kind of geometries is:
edge length = quality, resolution
offset value = actual real distance from input geometry to output mesh
… then I expect the same exact behavior with pointcloud and points too.
Please discuss this internally, this is objectively wrong. I’m sure.
The user should not care what is happening mathematically.
The user is simply asking for a mesh object, a “limit surface”, at X distance from the input. End.
If my numbers do not add up to something that make sense, it’s a bug.
Expecially when you are going to mix point/pointclouds with other kind of geometries.
point and pointcloud, actual offset distance = offset + edge length
other types, actual offset distance = offset
Seriously. This is wrong.
… ever worked with 3d scan data, pointclouds?
The points ARE the surface. AT the surface. Not a “blob”.
Hi, please note that ShrinkWraps support for points is not the same as a PointCloud to Mesh routine. ShrinkWrap always wraps input objects that have some form of volume, thus its name. Points have 0 thickness and therefore are “inflated” to create volume which can be wrapped. If your goal is to make a mesh from a point cloud with extreme accuracy then ShrinkWrap is not the ideal tool for this.
Cool tool but you can’t input anything else than point clouds.
I’m trying to enclose a volume made from different scan data and a virtual not-yet-manufactured structure.
Workarounds? I can find those.
This thread was to report a bug.
“you are using it wrong” … oook.
…please teach me how to use it.
I’m seeing the same “error” from points or pointclouds. Other types of inputs give results that are more… predictable.
If
EL = edge length
O = Offset value
AO = actual offset distance in resulting mesh output.
With meshes as input Shrinkwrap gives an AO = O, with small error. As expected.
EL make no difference.
With points and pointclouds? There is a way to predict AO? Or that value is arbitrary?
AO=O+L ?
This seems the best hypothesis, but it’s not as much accurate as when using meshes/breps…
There is a better formula?
You can use negative offsets* to compensate for the inflation. If the points together form a ‘closed’ volume this can work, but in case of your example file, it’s more like a shell. Shrinkwrap builds a volume so the only way to do that with this input is to inflate.
