When I unroll this polysurface (and couple of others), which is built from planar surfaces and fillets, it still gives me a naked edge upon unrolling with a huge gap of 0.032mm. Why is that, and more importantly, how can I avoid it? This is an abstract from a gh definitions so manual fixes are not preferable.
Hi Gijs - I see that and I do not know the answer - the file tolerance is a little fat, but it seems not to be the thing that makes any difference, the 3d edges are where they should be as far as I can tell. I’ll add this to the pile, the developer may have a helpful comment.
RH-58669 UnrollSrf - Edge gap in result
thanks @pascal for taking a look. If you know any workaround to make this work, I’d appreciate it, because I am already deep down in the development of this and now arrived at the step to flatten things down. I’m now trying rebuild and refit to see if that solves things. In some cases I found shrinking seemed to help, but it’s not consistent. I really thought there was nothing that could possibly go wrong with a few flat surfaces and some simple fillets ;-(
Hi Gijs - how were the fillets added and how were thay joined into a brep ? Was it all via GH, or? If the fillet is untrimmed and the plane untrimmed and it’s all retrimmed and joined, Unrolling is correct…
yes everything is gh. Initially I had troubles with a tight tolerance. I’ve been fiddling with this file all night now and made some more robust code for things that were initially failing at tighter tolerance. So far it looks like the tighter tolerance has solved this fillet fail issue . Still I am puzzled why a rolling ball fillet between 2 flat surfaces can cause any inaccuracy. I wouldn’t expect any tolerance to be involved since no approximation is required. Is this a wrong assumption?
edit: @pascal it is still giving me trouble, even at 0.001 tolerance for some of the parts. I am not sure how I can best share this. I might have to dig into this with a fresh brain first.
Hi Giijs - I share your assumption and question … but I do not know much about what the underlying process is and whether it special cases ‘exact situations’ … I guess I’ll just have to experiment and see if I can reproduce the not-quite-linear trimmed edge that is the problem here. I have not looked yet, it might be all too easy- but if I can reproduce it, I’ll have something to bring to the developer, with raised eyebrow.
@pascal see the attached. I’ve narrowed down the issue and the edges seem to go out of wack after a split operation. If I explode the result and RebuildEdges edge tolerance is back to 0.000, join well, and then the unroll will go well, but I couldn’t find a RebuildEdges option in grasshopper, is there?
after-split-edges-go-out-of-wack.3dm (691.3 KB)
Hi Gijs - I see that, thanks for the example.
RH-58685 Split knocks edges out of tolerance
You can rebuild edges for a brep face via RhinoCommon, so perhaps a python or c# GH component can be used there.
@Gijs The fillets are not the problem. It is the planar surfaces. They have a really bad parameterization relative to their size. In the attached, split blue with black to get the same edge tolerance. The blue thing has V going from 0 to 1. If you call Reparameterize, and choose automatic, V will go from 0 to 921 and the result will be as expected. How are you making the planar surfaces? We should be able to fix that to use the correct parameterization.
Hi @chuck: I see no attachment…
as for the creation method, these were made in grasshopper using Surface from 4 points, then I used Project to make sure the resulting surface is planar.
If I exploded the polysurface from my first post and reparameterize the largest surface, then join back, unroll still gives me a naked edge though at the same location.
Sorry, I forgot the attachment. It was just the largest blue surface and one of the black ones. You’ve tried reparameterizing, though, and still had the same naked edge issue. This means the bad edge tolerance after splitting was not the cause of the problem. I’ll have to pass this on to the Unroll developer.