Awesome tool!
Is there a chance to see this available in Rhino.Compute anytime soon?
Yup, as well as a GH component.
4 Likes
Could you communicate when would that be more or less?
A matter of weeks, not months. These are driven by developer priorities and complexity of issues they might run into so no firm dates are given.
4 Likes
The ShrinkWrap component available for testing in the latest WIP
2 Likes
You can now find some static ShrinkWrap functions on the RhinoCommon Mesh class or as methods on mesh and point cloud objects as well.
4 Likes
It’s cool this new shrink wrap option 
. It would be super cool with the possibility to enter different values of target edge lenght between convex and concave edges.
At least, a compromise would be the possibility to detect / isolate hard edges as requested by Mariusz Hermansdorfer hereunder.
Regards
Keep in mind this is a voxel process, so “hard edges” is a thing we need to clarify.
think of voxels like spherical grains of sand. (they are cubes really, but stay with me)
the “sharpest” edge you can get is determined by the smallest diameter of each sphere. Since the spheres cannot be 0 diameter and computing resources are finite, there is a limit as to how “sharp” and edge can be. They also cannot be variable sizes… they all have to be the same size.
Polygons on the other hand are in fact planes with 3 or more points. as such they can make “sharp” edges. So even though shrinkwrap delivers polygons to you, the behind the scenes actors are in fact voxels and as such you will get “softer” results than you would if it was a polygon process.
you can use booleans on the shrinkwrapped result to recover things like parting lines or sharp details with a little planning and strategy.
make sure you are using the right tools for the job-
I typically only shrinkwrap to unify a messy mesh or to shell a part, then switch to standard polygon/nurbs modeling and booleans to get sharpness and details.
as this toolbox develops, we hope to see improvements to the process and results, but for now I hope that explains a little of how this system works.
3 Likes
The programmers could do a little trick behind the scenes. 
The tool should secretly orient cube-like (or home-like) objects, so that they will be better optimized for the voxel calculations. Once the calculations are done, the input object appears again in the original orientation.
Perhaps, however the devs typically roll their eyes and give me a bit of a nauseated smile when I say "couldn’t you just do____ with the thing at the place to get magic? "
to which they respond with “no because, math, math math math”
to which I respond “blank stare”
to which they respond with “good talk bro” and they silently vow to never ride an elevator with me again…
So I’m absolutely the wrong person to comment on the nuts and bolts of how a tool is written, BUT… there are several here like @Trav who could speak with actual intelligence where as mine is artificial at best.
1 Like
Not actually trying to start a pandemic of nausea, but I thought octrees are the usual way to represent voxel structures in an efficient and accurate way.
It’s already doing slight of hand and orienting and putting the object back. Since Rhino doesn’t store object transformations there’s a small number of objects where this extra effort might pay off and for the other 99% there’s the gumball. 
We think there are areas where we might be able to retain hard edges in a better fashion that is less conditional and more consistent across different geometry shapes in a future version.
Yep, ShrinkWrap is no exception to using Octrees… Try out the polygon optimization parameters and you should see some of this in action.
Hi @Japhy , I could test ShrinkWrap in GH successfully, but still can’t see this functionality available in the Compute API, or am I missing something?
Yes, Its in Rhino 8 RhinoCommon. As far as Compute access you may need to do a custom endpoint. I’ll defer to @AndyPayne on that one.
As Japhy said, the ShrinkWrap methods are in the Rhino 8 API… however, compute isn’t quite working with the Rhino 8 code base (yet). We had to make some changes now that Rhino 8 is targeting .NET 7 (instead of .NET 4.8). I know this is currently in progress so hopefully compute will be running smoothly again with Rhino 8 soon. But, unfortunately until that happens, you probably wont be able to use the Shrinkwrap methods.
1 Like
Ok thank you for the precisions!
I guess I will still need to digest this thread before I’m on the same page.
While I do have a project I’ve been working on to try making use of this tool and staying motivated while doing it.
The main problem I had so far, was using a bad 3D scan that had a lot of holes, which seemed to be very problematic for this new ‘shrinkwrap’ tool.
It seems to work much different than I expected and doesn’t work well with meshes with holes.
It ended up creating an offset shell that added a bunch more work to delete the inner layer.
Eventually, I derived a solid over time that gave me the results I was expecting. But took weeks longer than expected.
The other problem I had was the current shape has deviated enormously beyond the original.
Next, I will try merging additional shapes into my current solid, but not sure this tool can even do that yet.
I’m hoping to use this feature in an automotive application in the future - essentially 3d printing body panels. I’ve been playing around with it - it seems like there is a ton of potential there but I’m running into a few issues:
-
All of these test cases seem to be closed (or with the intent to be closed) solids. However, I’m starting with body panels - the mold OML - and wanting to use Shrinkwrap to quickly prepare these surfaces for 3d printing. These panels need a minimum thickness for printing. When I put an offset into Shrinkwrap, it offsets on BOTH sides of the input surface, so I’m losing my OML. These panels fail in OffsetSrf (not that I’d expect them to work) and so I can’t simply OffsetSrf and then Shrinkwrap. Any suggestions? This seems like a very likely workflow that other people would want to do as well. Seems like starting from an open polysurface and wanting to offset in one (user defined) direction would be mighty useful.
-
It seems like it’s generating the final mesh off of the display mesh - just confirming this. I seem to get chunky output with lower quality display meshes. Shrinkwrap is using the display mesh for input, yes?
-
The minimum target edge length is kinda large for small objects. If someone is working on say a Hot Wheels model, they would likely need to scale it up, Shrinkwrap it then scale down the result. The ability to put in a smaller target edge length would be really nice.
-Sky
2 Likes