Why aren’t you calculating how many of these you need from the document tolerance? Why leave it up to the user?
Also, any plans to allow G0 on some sides?
Why not make this kind of commands for the generation of surfaces more interactive (including guides and handles where the operator can manually intervene on the model, on the surfaces, as it was implemented in the defunct VSR plug-in, for example).
For these tools, in my opinion, we should look at other much more mature and consolidated Cad, and do in a similar way; it is useless to propose incomplete and lacking “original” solutions.
We’re still in early phases of the development of this tool. I agree that in general we need to move UI more into the viewport. Ui work is quite labor intensive. It makes sense to start work on that once the tool is a bit further consolidated.
I have no doubt about it. Mine was meant to be a humble suggestion.
Good work and let’s hope that when Rhino 9 comes out we will have a convincing tool, on a par with the one implemented in the famous Cads.
If you use an ordinary curve, not a surface edge, you will get G0. For now, that means if you want G0 on a surface edge, you need to use DupEdge first. This will get improved as we develop this further, with G0-G2 choices in the commandline and/or the UI for each edge.
I just uploaded a file called xnurbs-test via the uploader with some orange Xnurbs surfaces in them. I tried DupEdge but the multi sided tool still failed.
I have duplicated all edge curves that border on the orange surfaces, and in the top triangular shape, MultiSidedPatch creates a surface patch, while in the bottom shape I had to join the two tangent edges into one curve, then run MultiSidedPatch with the three curves.
If you want, I can send you the file with the results?
Oh, I see. So all edges need the same continuity as of now, got it.
Well, like I posted above, having to guess U and V complexity and only seeing if the tolerances passed or not after the tool completes makes it incredibly painful to use.
Are the wavy iso curves MultiSidedPatch produces something which will stay, you think? In one direction I guess it’s fine, but when they wobble in both it doesn’t look very appealing (although I must admit in the more difficult example, the zebra result on MultiSidedPatch seems better than the bubbly Xnurbs one, even though none of them are really usable).
I would love it if UX would be thought about from day one, so engineers can’t accumulate technical debt which then makes fast workflows difficult/impossible to implement and unusable features get pushed out the door, so people will have to go out and buy expensive plug-ins anyway in order to be able to work effectively…
The multiblend command in VSR/Autodesk Shapemodeling (which would be somewhat comparable to Rhino’s patch) didn’t have that many interactive guides or handles to manipulate the surface.
It did have quite a few options but the resulting patch surfaces (more than 4 sided patches result in multiple patches) are of poor quality in most cases and barely usable in rare occasions.
It is by far the less useful commandof this otherwise wonderful plug-in imho.
This tool, along with several existing NURBS surfacing tools in Rhino, will benefit a lot by adding two buttons or Command line options called “Add edge” and “Remove edge” (both, edges and curves should be selectable).
The lack of these two options makes the use of some of the existing tools extremely cumbersome, forcing the user to cancel the command and start picking the input edges from the beginning.
Contest. Maybe it wasn’t very interactive, you’re right, I remember badly…
Then we should look at other Cad, like UGS Nx, Catia and, maybe, I would add also Plasticity.
No they do not, you can mix G0 and G1 curves as long as the G0 are normal curves and G1 are surface edges. But in your case, which I won’t show here, the G0 continuity was required on all edges.
This is a matter of improving how the surface domain is chosen. This is now done in a very simple way: use a regular polygon in UV. When I get around to improving this by either projecting or unrolling space curves to parameter curves, the wavyness of the iso curves will be reduced.
Hello Menno!
This looks great!
As much I Iove seeing new tools being developed for Rhino, in this case I think its not a good idea at this point.
Please let me explain:
With the new static Zebra and the new GlobalContinuity-analysis coming to V9, Rhino will be opening a can of worms.
Those tools will show all the flaws in complex topologies, without providing the surfacing tools to fix them.
I work in automotive Class-A surfacing and I think that a multisided surface patch is the equivalent of duct-tape in the real world.
People will expect your tool to create a G2 wonderland of curvature continuity and nice highlights, but will be very disappointed to see your tool fail to go above G1 in many cases.
Rhinos existing surfacing tool sets are not strong enough create and analyse high quality topologies, as a foundation for your tool to work as desired.
This is not meant as critism of your tool, but as critisim of the Rhino modeling workflow.
If you have the skills to develop such advanced tools, please use your skills and time to fix the exsisting tools of “MatchSRF” and “MoveUVN” along with more analysis tools.
Just my 2cts, I hope I’m not stepping on anybodys toes. 
Thanks for your extended explanation of where you think Rhino is lacking functionality. The development of the multi-sided patch should be seen not only as a new standalone tool, but also a way to improve e.g. fillets and blends, in cases where corners are not made at all, or where corners are bad, or for the conversion of SubD to Nurbs around extraordinary vertices.
I agree that patches are analogous to duct tape, but at the same time not every user has the same requirements that you may have working in Class-A automotive surfacing. In addition to the Rhino tools available, you may want to check out the Cyberstrak plug-in if you have not done so already, for more tools that enable Class-A surfacing (a contentious term that means something different to everyone I ask).
To me, it’s about having a well-stocked toolbox that can be adapted to various projects with different goals—whether it’s sketching out ideas or minimizing risks when cutting out large objects with a 5-axis CNC.
If I were clearing my backyard forest, I’d much rather use my Stihl chainsaw than a handsaw, even if the handsaw might give me a cleaner cut. Similarly, if a “fill” tool saves me time and gets the job done, I’ll use it when I can.
I register that “patch/ fill” is not gospel to the “Church of Class-A True Believers,” but if we look at the other heavy hitters, they provide similar tools to complement their workflows. Alias has Patch and Square, NX has Fill Surface, and the same goes for the two major class A plugins for Rhino that have been. It wouldn’t surprise me if CyberStark eventually integrates something similar as well.
For my part, I welcome this improvement. At the same time, I also support the calls for other surface improvements that have been brought up here numerous times earlier. That said, I don’t see one improvement as excluding another.
I hope my perspective doesn’t ruffle any feathers. 
If Rhino’s own NURBS surfacing tools were good, 3rd party plug-ins like VSR, Cyberstrak and Xnurbs would not exist at all. Literally every of the main surfacing tools in Rhino has HUGE known weaknesses that were not fixed for decades despite the user input and suggestions.
For example, here is an old topic since the Rhino 6 times. ZERO of the suggestions there are implemented in the latest Rhino 9 versions.
And here is another topic with more suggestions in a more organized way:
Thank you for your reply!
Yes of course its true that not every user has the same requirements. But at the same time, 80% of all problems mentioned in the forum ie. why wont Rhino fillet those surfaces, Why cant I make those surfaces watertight, why doesnt trimming a surface work, etc are due to the very bad modeling workflow in rhino.
Rhino gives NO feedback about the quality of generated topologies. Instead everything is blasted with spans and more CVs to meet some preset tolerance.
First you create some curves, then you create surfaces from those curves. Often times those surfaces already will have way more CVs than the initial curves. Then you add secondary surfaces to your topology, maybe by offsetting or trimming, which will add even more CVs to meet the tolerance with the first surfaces. If you then try to fillet your object, which requires even mores CVs to meet the tolerance, everything falls apart.
You also cannot fix your surfaces, because they have too many CVs and the modeling tools and analysis tools are not strong enough to improve surface quality.
Rebuilding your surfaces is also a nightmare, with less CVs but they are flying all over the place. Again the modeling tools are too cumbersome to properly rearange CVs (I hope Elmo will fix this, but then again development of “Elmo rebuild surface” has not even started?)
That is why the user ends up beeing happy about “duct-tape”, just so they can be “done” with the whole mess.
With lightweight surfaces, with control of span and CV count and a good “MoveUVN”-workflow, no “duct-tape” would be needed!
Im really sorry to go off topic this much. I’m happy that rhino gets new tools and sees active devlopment. Thank you very much for your great work!
I agree with much of the examples given here, and I also think this was the wrong tool to start a project on, especially when it’s a last resort tool because the result can never be edited in any meaningful way (and one that already has a servicable 3rd party alternative in Xnurbs whereas Cyberstrak is years away from even coming close to VSR), and also while there’s so many huge gaps to be filled in Rhino functionality before you need to use a last resort tool like this (like handling surfaces with too many CVs as you say just to mention one), but seems the train has already left the station on this one, and we’re just along for the ride.
In the lastest WIP, the MultiSidedPatch command has been removed. Any users who were using this command are invited to use the new and superior FillSrf command instead. More information about that command can be found here.
This topic is now closed.