VSR end of Life-

Just watched this again. That tool is just beautiful!

@theoutside In case we get a Control Point modeling tool like this, SubD modeling should also work the same!


Excellent point. I endorse this point of view 10X.


No, many industries rely on Rhino plugins. For example, McNeel has a dominant market share for the ~20k jewelry designers worldwide, with V5 at 75%, V6 at 0.00000%, and V7 at 9%. Sadly, you nor McNeel will see them since most plugins have their own forum.

It also makes you a hostage. You don’t compete with plugins, but between Stuller and Autodesk, I have $15k worth of plugins with no upgrade path from V5…

And, it disconnects you from large swaths of your user base. Somehow you have to realize there are more jewelry plugin developers than jewelers on this forum. When all four of us tell you there’s a breaking bug…extrapolate that out.

Like, I will never understand RH-44623…a jeweler reports it during the WIP, and it’s ignored for two years. Then the other 3 of us report it at V6 launch. It gets multiple youtracks, Mikko knocks it out in 2 days, and…it’s punted to the V7 WIP?

The amount of goodwill you lost over this is staggering. “Is flow fixed in V6 yet?” - “Nope” - “I should have waited to buy a license.” - “Me too.”


We should start from this premise: what McNeel wants and what users want. They don’t always coincide.
It is possible that the developers do not care about class A surfaces and want to direct the development in other ways.

For many years, since Rhino 4 the same things have been asked: better fillet, match and blend surfaces, more solid editing …
I only see minor fixes, some useful additions to the commands and nothing more. A development (apart from the subDs) that has lost its way!

1 Like

It may also be the case that McNeel can’t develop these tools with ease. VSR was sold to Autodesk to integrate its tools into their own toolset, which again are developed by Icem developers. So also Autodesk was not able or willing to code this up.

I would also assume that most Rhino owners are not even doing any complex surface modelling, but using this app for various other tasks. So I would bet the decision to value Sub-D and Algorithmic Modelling higher over plain Surface modelling (since V4), was a very rational and “right” decision.

Corporations which model cars, airplanes or boats are usually buying any CAD they require. So again, making Rhino a class A modelling software might affect only a small subset of all users. Because the majority of user either also own another CAD system or do not really model this complex.

I think one key aspect to make Rhino as a potential class A modelling software more attractive, is to not only code these features, but also giving the ability to call them by code. This way, a lot of repetitive class A work could be automated. This is something which no class A package is really capable of nowadays.


The main issue is that the Rhino programmers are not full-time Rhino modelers, thus they don’t experience various modeling challenges and the need to improve current tools and add new functionality in the same way actual modelers do. Here is an example of a real use case where the “Match surface” is incapable to properly match two simple surfaces of the same degree and control point count with a tangency less than 1 degree"

The same topic also consists a few more examples of real use cases that show the major weaknesses of the current “Match surface” tool in comparison to the similar tool in Alias (they call it “Align” instead) and other programs. The requests for those and many other improvements were repeatedly posted in this forum by many full-time good Rhino modelers for years, yet the actual improvements are scarce since Rhino 3 or Rhino 4. If I recall correctly, the “Match surface” in Rhino 4 was even downgraded by removing the “Refine match” option.

The other problem comes from the fact that when Rhino modelers experience questionable results while using some of the existing tools, naturally they don’t find it practical to use them in the future, because they are aware about the inability of the said tools to do the job. Then, the Rhino developers collect data that certain tools are not used often and they start to think that Rhino users don’t need improvements in those tools. It’s a never ending loop. A great tool with all the features that does the job properly will be used more often, whereas a half-finished tool with lacking features will be less used. That’s the reality. :slight_smile:
The lack of proper modeling tools also forces the majority of Rhino users to use bad modeling techniques, because they get frustrated by the limitations and inability to achieve a certain result while trying to use proper techniques.

The “RefitTrim” tool is a good example of such existing-but-not-optimized tool that people would love to use, but many try to avoid due to its shortcomings. While it helps in certain situations, in the majority of time it produces vastly different border shape that’s not related to the split edge that it tries to replace. I had multiple cases where splitting a surface with another FLAT surface and then applying “RefitTrim” to the split edge causes it to become CURVED and far from the natural flat border that a proper “RefitTrim” should do. Due to those inaccurate results, I rarely use “RefitTrim” and instead prefer to extract the border curves, rebuild them and then use the ! _EdgeSrf command, which usually gives me a far better approximation of the desired shape.

Another example is with the current “Blend surface” tool which is incapable of using the same U or V direction while matching to a single trimmed surface edge. Check the 2nd post here:

The issue in this particular case is that a single surface blend end uses TWO different directions (both, U and V) to match to a single trimmed edge, thus making the resulting blend surface unusable and forcing me to avoid the “Blend surface” tool for such cases. Then, Rhino developers may start to think: “Well, Bobi does not use the Blend surface as much, so probably it’s not important and we should not devote time into improving this particular tool since he uses alternative tools more often”. :space_invader: :innocent:

Also, “Blend surface” lacks an option to match the end handles in the same direction as the target surface’s side edges to achieve a natural G2 flow.


It sort of makes sense, but if users migrate from Rhino to other softwares because they miss some essential tools (eg. proper surface matching) you’ll just remain with costumers who won’t need them, so you’ll never develop in that diection. If you start to listen to the remaining minority who still believes in Rhino you’ll definitely get new (and old) users.
I hope you get my point :slight_smile:


Not picking on you Kyle, but what would be refreshing to hear from someone at the software company is, thanks guys and gals for all the great input over this new thread and threads in the past. We will all this into account along with all the information that is out there and then decide what we can do. Again we greatly appreciate all the input.
Thank you to the software company what you’ve done for your customers.—-Mark


More than a “thank you” (which of course is allways nice, I guess) I would like to get a hint about the conclusions McNeel is drawing from this thread.
I guess the fact that this discussion is getting a lot of attention and participation by Rhino users is an indication that between current Rhino surfacing and ICEM surf there may be a valuable place in the market to be occupied by future Rhino…


Thanks to everybody - i think a lot of important points are already mentioned and linked to older topics.
i already distributed a lot of likes :heart: :heart: :heart:
Dear @theoutside Kyle thanks for opening this vivid and important topic.

I totally agree with the wish for

  • improved _matchSrf command
  • integrated rebuild
  • better CV-tools / CV editing
  • better interaction to neighbour - surfaces bobis post
  • user statistics might lead to wrong development-focus bobis same post

better patch / multiblend

I just used VSR as a trail version once, a few years ago - i was always hope to get a better tool for complex transistions - the same expectations i would have for kajo or xnurbs:
the VSR introduction / tutorials are still available on youtube

I would love to see tools for this kind of star-point like transitions - also from an educational point of view - it would be nice to teach similar typologies for Sub-D and Nurbs.


I don t care about icon-Design, Fonts, darkmode or stuff like this - BUT i really care about workflows and intuition. Working with Rhino on a every day basis this is really important, and a lot of potential is not used. @Cadworx video / post shows a great mouse-over behaviour. interaction on control-frame that we now know from sub-d but not from nurbs (why ?). a lot of functions in the video are accessible by _moveUVN, _SelU, _preU, _selControlpointRegion, Gumball, CageEdit with preserve strucutre, softMove and so on… but with much less intuitive workflows. therefor i really think this video shows a great potential.


i think this forum is great. and i honour mcneel for interacting in this way with us, the users. a big rhino - benefit. But i agree with

and want to add: …and do not teach Rhino in a classroom with 20 students, all from different background.
I still think there should be some more formats to interact with the community or with some power-users. I already discussed this with @carlosperez - i think some of the fine-tuning and interface needs another way to test it - maybe a user-meating where we can sit together and give direct feedback - but also feel free to visit my classroom, bring a current WIP, we set up an exercise and see if the students can learn a new _matchSrf interface within 180 Minutes.

pay and vote feature

I still love the idea of being able to dedicate my upgrade-payment to a feature - even in advanced before the new version is availabe

meta Surface Command

I also already posted this idea - a command where you can add curves and edges and continuities (g0,g1,g2) without decide at the beginning whether it is sweep2, a patch or a network surface or a (new) multiblend.
x-nurbs does this and some other software have kind of boundary-Surface-Command.
i would love to have a “save state/version” in this command, and maybe some feedback - “your final surface was a _railrevolve / _patch / …)” - And maybe a Finish option with keeping all States/Versions to separate Sub-Layers.


talking about innovations - and a lot in this topic is only about keeping up with the competitors. ok i will write a private message to Kyle.

looking forward to see the outcomes of this topic - kind regards -tom


I use VSR/Autodesk shape modeling daily.
I love this plug-in and it is a funamental part of my workflow, but tbh the multi-blend command (when used for a more than 4 sided patch) is amongst its least useful commands.


I would prefer an Align over multi curves to make surface.—-Mark

This was the tool I was so excited about at first - but as I learned to model properly I realized its limitations and really stopped using it. At this point, I regard it the same as “Patch” - it’s what you reach for when you run out of time, talent or ideas.


Yeah, MultiBlend was a great time saver for five-sided holes. It was usually good enough for quick prototypes.


I’m an ICEM modeller in the automotive industry and what you say is 100% true.

Multiblend and 4-sided matching are totally irrelevant in Class-A surfacing. You just do not need them.

Matching and modelling is so precise usually (in my case 0.000mm to 0.002mm for G0 is required), that you never run into a situation in which you have to hold down 4 sides of a surface at one. If you find geometry that jumps back and forth while matching, it is always the foundation underneath that causes that error.

Same with Multibend, if you understand Patchlayout you can fill anything, no matter how many sides. You will have some patches running across some other geometry, but the analysis and matching tools are so powerful, that you understand right away what is necessary in any given situation.

If you can’t meet that 0.000mm criteria, your patchlayout does not work properly and you need to adapt and adjust it. That is the whole secret. It might sound tough, but it actually is super helpful.

That is all that is used in high end Class-A Surfacing, just classic matching and strong analysis tools, nothing more.


hopefully i am not a very bad cad modeller if i sometimes end up with a 4-side match or even 5 side hole. :grimacing: :face_with_symbols_over_mouth:

A bit harsh, clearly McNeel care about the loss of VSR to their customer base. See the very first comment in this post.

Maybe Kyle should have pleaded for no McNeel bashing too.

Autodesk’s Alias developers have meetings with their customers throughout the year to improve their toolset. It is a vital part of their working routine to get in touch with those doing the actual modelling. In that regard, maybe that’s something McNeel could pull of with regards to the surface modelling toolset as well.


I think that the forum here does a similar job in regards to feedback, asking for new features and wishes for improving existing tools. I can see lots of Rhino users’ feedback and great ideas already being added to the pile, but the main issue is that those stay in the waiting list for years. For every new iteration of Rhino we wait for those improvements of the few main NURBS modeling tools (mostly “Blend surface”, “Match surface”, “Explicit control” /an integrated “Rebuild surface” into those tools/ and proper control point editing with handles along the control polygon similar to what Alias and VSR for Rhino 5 use), but in reality they never happen. The improvements in “Blend surface” were mostly in Rhino 4 that allowed to rotate the individual handles. On the other hand, as I mentioned in an earlier post, the “Match surface” tool got downgraded in the same Rhino 4 release.

Many Rhino users stick with Rhino 5 even in 2022 due to incompatibility of Rhino 6 and later with their expensive plug-ins for Rhino 5 (VSR included).

At the moment I see no reason to upgrade to Rhino 8 since its “Blend surface”, “Match surface” and point editing tools remain relatively the same as in Rhino 7. I would gladly upgrade if those 3 tools include the improvements that I and other asked for since the Rhino 5 era. :slight_smile:


Just browsing around the net, I found this: What happened with VSR/Autodesk Shape Modeling? - #11 by velopl
2017… I’m afraid we’ll never get some real help from McNeel and we’re just wasting time :frowning: