Eric, I lied .
The fix was to ExtendSrf, to keep the domain constant, in this case the domain of the surface grows with a -1 move (I accidentally used +1 initially) so it is not ‘fixed’ cause it is a different thing… The blend ends on the same parameter but the domain has expanded slightly.
I stopped using BlendSrf after history support was added in V6. I find it to work 25% of the time. When it doesn’t work, 0% of those can be fixed with BlendSrf Edit, and 50% can’t be fixed at all.
Like there’s no way to recover this srf with MatchSrf or something once an edge collapses to a point. And if you use a lot of History like me, that can ruin the downstream history for 10 or 100 other parts in a model.
Creating a blend without using BlendSrf or even BlendCrv Edge takes a dozen extra steps. Waiting another 3 years for a fix is really hard to swallow.
Can I ask the history path that exists here? What commands and objects are involved in going from the 2d curve to the bottom blending object on the pipe? It looks like multiple history objects built on the next?
My guess is:
2d curve and Profilecrv > Rail Sweep
2d curve > Projects to clpane > Planer surface?
Copy the orange surfaces (Srf) to center of Base surface
Flow along surface of the copied orange to the pipe.
Blendsrf the objects on the pipe.
Is that about right?
I have a included a test model that seems to show the same behavior. Scaled either blue surface in anyway and it goes south? I can report this behavior on the YT issue: BlendSrfSD.3dm (184.8 KB)
@scottd, all stone settings need the top positioned rigidly (a 1.3 mm circle stays a 1.3 mm circle), while the bottom conforms to the finger size. Joining the two pieces without a history-enabled BlendSrf is painful.
I make these all kinds of ways, but in this instance, the rigid top srf is a Sweep1.
Without using BlendSrf, making any setting requires 10x the amount of history components.
Loft Loose can give a decent result using two rigid curves tangent to the top srf, two curves that deform with the bottom srf, and a pair of Tween crvs to define the middle. I mostly use this method, even though it’s fairly inflexible.
I also came up with this history hack. I use FlowSrf to deform the whole thing as one, but the target surface is designed to induce minimal deformation at the top and fully conform at the bottom.
This works perfectly with one or two components, but FlowSrf is 10-50x slower with these base and target surfaces. I have no clue why, but Rhino simply grinds to a halt on complicated models with lots of components.
And that’s the rub. I don’t mind redoing one BlendSrf, but I seriously do mind updating a hundred of them.
As to performance I can only imagine it grinds to a halt. When stringing a series of commands together performance can become a big problem unless there is some smarts in the way things refresh. And I know the history does not look globally for optimizing many linked history records.
I specifically notice it when FlowSrf uses target surfaces that run vertically through a part vs horizontally. This strategy lends itself to much smaller history trees.
And yes, it would be nice if history put all children that need updating into a queue that’s sorted by age desc. Grandchildren get updated umpteen times, once for each parent. If they were done by age, all of the parents would be updated before the children and nothing would get done twice.
@EricM if you are willing to use grasshopper, the new content cache component allows you to keep working in Rhino and make updates to geometry:
Here’s an example of your earlier reported BlendSrf bug where the BlendSrf is made in grasshopper: BlendSrfHistoryBug_gh.3dm (274.3 KB) blendsrf.gh (20.2 KB)
This is the frustrating thing. BlendSrf history replay has been broken in so many ways for 8 years, yet I can always recreate it with the exact same inputs or set it up in GH and it always works correctly.
I’m not sure what the content cache component is. The help file was less than clear and there aren’t any tutorial videos showing what it does. I’m sure I’ll try GH yet again once we move to v8, but I’ve always run into a show stopper in the past, like it not supporting blocks or baking 100s of parts (gems, gem seats, prongs, cutters, etc) into a single, incomprehensible pile.
