The middle shape doesn’t work at all for me.
Rhino eats some GB of RAM and uses 100% CPU for a few minutes:
The preview doesn’t show a useable result:
2 Likes
without any guide curves or points that will not work. that only works with the initial patch so far. in this case you have to use PatchOld or whatever its called now in the wip.
1 Like
i still hope we get a symmetry option for new patch formerly FillSrf
2 Likes
@Charles vertical walls without any guide curves or points is a current known issue/limitation
1 Like
Just did some testing… this stuff is wicked! 
It’s so nice seeing some love given to Nurbs tools again! So thank you for that!
And the new zebra is kicking butt too, so these two combined is a minor power-house!
11 Likes
@menno before we pass off the old patch into oblivion and rant a little more about it before doing so, let me also say thank you for investing into such a great tool, the quality of those cases that already work are really amazing, no doubt it is becoming one hack of a new tool seriously thank you!
back to findings 
obviously the straight side walls do not work out of the box, but as you have pointed out yourself quite a while ago conical geometry works, but only when the patch is introduced on the narrow side.
when you have the wider side where the patch should go it flips the tangent direction, creating a concave surface instead. when you have history turned on and you subselect the bottom to scale it inwards or outwards the patch surface reacts accordingly warping from upwards to downwards.
i am just curious how the old patch did this, how did it decide to just bulge out and return to the edges? was that inherent of the old patch algorithm or did they introduce internal geometry that guided the patch?
moPatch.3dm (632.5 KB)
two last important things:
Please
• complete Patch with Enter or Space
• cancel with ESC
4 Likes
A “Flip” button solves all problems… Already proven to do a great job in numerous other Rhino tools.
4 Likes
Patch is a command that runs in parallel, so you can add points, draw curves, in fact do anything when that dialog is open. This makes it that Enter and Esc will not have an effect.
I am not saying I like that fact, but it’s probably the price that needs to be paid for having flexibility. We’re still not sure though if that stays.
2 Likes
yes i am also not a fan of it, honestly it is quite a flow breaker. i rather draw all my curves and prepare stuff before i engage with the command. having to use the mouse which is so overused already to complete or cancel a command additionally is really not helping the stress levels.
there are a few commands that were left untreated with the same bug, just there it was just a bug and here it is meant by design, but what i really love about the commands is that you do your thing finish up and gone is the stuff from the screen. having to swivel around with the mouse with some commands more than others gives me too many brain knots..
zebra for instance is also running in parallel but there if the panel is active you can close it with esc.
another exception is BoxEdit which has become a full blown panel that can always stay open, though it acts like a command and you have to apply the changes to take effect.
its all a bit too much there and back with no clear distinction in my opinion.
i personally would keep commands act all the same as commands. anything else that should/could stay open should just be a panel already. zebra definitely could also be a panel instead of this hybrid thing.
1 Like
Zebra is a panel
Ok, then it should fail quicker and give some useful info.
_FillSrf is so much better than _Patch.
It’s a completely different tool.
Therefore, it doesn’t replace _Patch.
_Patch should stay as it is and co-exist with _FillSrf.
A new name for _FillSrf could be N-Sided or xPatch 
i think it would be nice to have a “global” concept of how enhanced / new commands are named.
rebuild → elmo ??
patch → fillSrf ? → patch
my suggestion:
the old commands get a version suffix (“last active version”)
_patch (formerly _fillSrf)
_patchRh8 (patch until V8)
_rebuild (formerly _elmo)
_rebuildRh8 (_rebuild until V8)
this will direct new users to the latest version, downgrading macros is simple (add Vx), and if there is a 3rd or 4th generation
_patch
_patchRh12
_patchRh8
is much nicer then
_patch
_patchOld
_patchVeryOld
meta commands
and still there is my wish to have “meta” or mulity-utility-commands - that call the corresponding functionality under the hood:
_fill
could become one of those - addressing the oldFill if SubD edges are selected and address nurbs if the corresponding object type is selected
1 Like
sorry, I forgot that it isn’t dockable yet on the Mac.
yeah, I’m not sure what the reason is that analysis panels are treated differently. IIRC there are plans to change that.
It’s the saying: The hardest thing in programming is naming things.
I don’t think we need multiple versions of a command. If a command isn’t better than the previous command, it should not replace the old command in the first place. PatchOld might still have some use cases currently, but I think its better to make sure we cover those cases in Patch then to keep PatchOld discoverable, which will only be confusing for new users.
3 Likes
Absolutely.
But it’s true that if a new command can’t be completed with right click like the old version, that might disrupt someone workflow.
Is it possible to tell Patch/Fillsrf to bake and complete current query via command bar?
Maybe creating an additional and optional “fake-command” that upon completion (rx-click , enter , space) will send a “Complete current task” command to current active Patch/Fillsrf window?
maybe an itsy bitsy teeny weeny checkbox that says (keep open), but honestly i am ok with history updating the placed input geometry, and if really needed calling up the command to add more geometry once it i has been closed previously does not kill anyone.
It isn’t dockable on Windows, don’t know about Mac.
It is dockable on Windows, but not as a tab like you showed in your image.