VSR end of Life-

You miss the point.
The third-party software developers are hugely valuable to not only us, but to the “Rhino Family”. We do not want to compete with a developer that is helping provide tools that are not already in Rhino.

No application is ever “complete”. There will always be a group of tools that we do not have, or do not function like any specific user wants and needs.

The arrogance of any developer, including us, thinking they can provide a tool with everything that is needed to any specific user is staggering.

Instead, we develop tool that are within our expertise, we have a well developed SDK to make it easy to add tools we do not have in Rhino.

When we release a new tool, like SubD for example, the initial release is our best attempt at a “minimum viable” tool set. Then with feedback from users, we develop additional tools to improve it in subsequent releases.

Nothing is ever “done”. Everything is always a work in progress.

We try to prioritize development based on a variety of factors that are constantly changing that include, how many potential users will be helped, how difficult or time consuming the development might be, and how critical it is based on plug-ins coming and going.

Does any of this make sense?


Some thoughts on all this -

As others have noticed, the price of Kajto is such that it’s really looking at a different userbase than your typical Rhino user. As best as I can tell, Kajto is aimed at the professional/corporate automotive surfacing crowd, and really no one else. I had thought that Kajto would be a sort of “Return of VSR” to Rhino. Having played around with it a bit, I can tell you it’s definitely not that! Kajto is a completely different animal from VSR, and they - in my opinion - were essentially going after different userbases. I believe that the aim of VSR was to provide better surfacing tools to the existing Rhino userbase. I believe the aim of Kajto is to bring people who are Alias or ICEM users to Kajto, and that Kajto exists incidentally on Rhino.

I also think that the toolset that Kajto offers is wayyyyyy beyond what’s useful for the general Rhino user. I firmly believe that if you want Alias or ICEM like functionality, well then simply use Alias or ICEM etc. Those programs exist for a purpose, and you can debate the cost/benefit all you want, but you are getting a fundamentally deeper toolset for the money you spend. If you need those tools, you are billing clients accordingly.

All of this comes to a few basic points:

  1. There is a massive gap between what VSR does/did, and what Kajto is aiming to do. So, I’d say that looping Kajto into this conversation is actually counter productive to this conversation.
  2. If McNeel wants to put effort into updating their tools, I think the north star for that work should be VSR, not Kajto.
  3. As many have made the point - and I agree with - many of the core tools for doing NURBS surfacing have seen little to no meaningful updates since ~V3 or so.
  4. I think McNeel should also take a good look at the UI/UX that VSR provided, and see if something similar could be developed by McNeel. I don’t think Rhino’s UI/UX should be completely changed - but I definitely think it needs to evolve.



Apologies, that was my fault… :flushed:

Let me make amends by suggesting what tools I’d like improved as @theoutside Kyle originally asked…

  1. Super-amazing surface matching tool with interactive control point editing.
  2. Real-time diagnostics - deviations, sections, highlights etc…
  3. Single-span fillets with working options for chordal edges and form factors.
  4. A matching algorithm which creates equally spaced control points for blend curves and blend surfaces
  5. A robust refit-trim command that doesn’t move points around beyond being useful.

I’m sure I’ll think of more soon, but the Dev’s can get started on these in the meantime… :wink:


Ha! Not mad about it, just trying to keep this discussion moving in what I hope is a productive direction.


Hi John.How do you know how many people you will potentially help in this VSR idea of tools? —-Mark

I think, to mcneels benefit, ultimately, their main market is architectural practices. Any UK event or training session, in my anecdotal experience, 90% of it is architect led and anything else is a minority. If I look at the rhino monthly mail outs, it’s mainly BIM and that kind of thing. That’s what seems to bring home the bacon. I empathise it must be hard to choose what modelling enhancement is most important to introduce, when there must be a lot of focus on this Revit stuff being kept up to date.

1 Like

But this is mainly because Rhino was adopted as a tool by that market, I think for at least 3 reasons:

  • grasshopper
  • many architects have affinity with programming
  • the tools needed are currently developed either by McNeel (Europe) and third party developers

Then on the other hand in industrial design:

  • much smaller part of designers have affinity with programming
  • McNeel did not put many resources into development of surfacing tools (thus further reducing the attraction/appeal to designers that need better surfacing tools)

I agree with @Gijs the Architecture market uses Rhino because of GH. I think that many of you may agree that GH was the most innovative thing related to Rhino in the last 10 years. It brings an innovative approach to exploring things that were impossible to imagine before, and it’s ideal for modern organic, sculptural architecture like Zaha Hadid style.

The other huge market I think is jewelry, SubD, Nurbs and GH are ideal for that, and so convenient at the license price.

In my case as an industrial designer, I started and keep using Rhino because it’s great for rough direct models, like a digital pencil, and it also gives you the option to create precise models if you take care of some rules.

It’s also true that 90% of the car grilles of modern cars are made with GH ( or maybe :slight_smile: ) original base surfaces may be created in NX/Catia/Alias/Icem or any other. This is a nice door to enter the automotive world. So, better handling of surfaces can only bring good things, I think.

What was shown by VSR, and can only benefit any of the other kinds of users, Is that tools may be grouped with a workflow in mind. And that analysis tools may and need to be more integrated with the other tools.


I could hardly put it more concisely. Anyway, without wishing to derail the VSR-lean of the thread, hopefully it becomes clear what can be achieved soon for those that need those tools (and those who do not yet know they need it, but would still benefit from having access to them)


to keep this thread on the rails-

let focus back on the specifics of what you need now that VSR is gone-

we are closely watching this thread, so keep the input coming-

Lot of great feedback from above, but lets keep the topic on track.


In that light - here’s all the lower order asks that I’d want. Going back and looking at my original 3 asks, I feel like those are still very much the right answers, but this is all the stuff that I’d also want to see, ideally:

  1. BlendSrf needs a lot of love. It makes, by default, horribly over defined surfaces. If you blend a degree 5 surface to a degree 3 surface (both single span, uniform surfaces) the point count blows up. There’s no reason for this. The point spacing it creates by default tends to make surfaces with “flat” middles. This is because it seems to bias the control points towards the edges of the blend, instead of evenly distributing them across the blend. I personally find the UI/UX outdated and frustrating to work with. There’s been a tendency over the years that when functionality gets added, it’s done on the command line or via things like Alt and Shift clicks. I feel like this approach has been taken as far as is practical, and the UI/UX of commands like this really needs to evolve. For instance, if you use Alt to change the angle but you have Ortho enabled, it imposes your ortho restrictions on your blend edge, and you’ve gotta be crafty with the Shift key to outsmart it. Being able to swap out your input reference from inside the command should be possible. Swapping the direction of the blend should be possible. There should be input sliders for each row of control points, right now, there’s just one slider, no matter if you’re G1 or G4 - this is hugely limiting. Feedback on continuity should be displayed for each edge. This is definitely not a complete list for BlendSrf, but should give a general idea.

  2. Rebuild should offer options for different point spacings. The way it works in VSR, it’s either Original, Arc Length or Curvature. I use each of these in certain cases, and they’re all valuable and useful. This should be an option for both surfaces and curves. Related - I’ve long thought it might be super cool to have an option to do Rebuild via an iterative fit of the control points. Like, what if you could let the computer brute force iteration on a Rebuild, homing in on more and more accurate results? Why not let the computer try 10,000 or so different options while I check my email?

  3. Make the Global Matching Tool that @Gijs created the McNeel one.

  4. RefitTrim needs work - both bugs ironed out and more functionality. The ability to specify a tolerance, and have it bump up the degree to meet that tolerance. Max deviation to both the trim curve and the delta between input and output.

  5. Better analysis tools, as others have mentioned. The ability to have directional light lines, independent of the model rotation. CurvatureGraph should have user selectable combs - how many per direction. Right now, it’s based on isocurve density - so in that regard, the cleaner your surfacing, the less useful CurvatureGraph is.


Ok, I’ll try to be constructive…

Here’s my explanation for the trim function - shout if anything isn’t clear.


I completely agree with you
Big +1 for me!

We base that on a variety of things including, but not limited to, forum posts and conversations, tech support patterns, private discussions with customers and developers, and Bob’s magic crystal ball.


I reckon that needs polishing a bit… :rofl:


And some more. Realtime sections, deviation of various stuff, highlights…

Shout if anything is unclear.


Actually everything important has already been mentioned above by the guys, but here is my list:

  1. CP modeling or CP Gumball

  2. Matching with Blend/Falloff, also for Curves

  3. Real time deviation analysis

  4. Global Continuity Checker

  5. XYZ-Static Highlights


Fine Tuning/Clean Up Tools:

  1. Planarise CPs (With tracing Plane)
  2. View Scaling

But instead of building everything from the ground up, maybe have a look what is already available:

  1. Fix THIS as a first step vor CP modeling.

  2. Continuity Analysis and visible CPs during matching

  3. Fix Filleting

  4. XYZ-Static Highlights

  5. Real time deviation analysis (Script by @Pascal) —> Explanation here

Those 5 tools just require fixing, meaning little new development. With these fixed you are already 80% there, as a short term solution!

Some Pictures:



Every time I thought that myself, I was wrong. He’s tricky and wicked smart.


Blending of curves and surfaces with equally spaced control points…


Single span filleting…

With fillet end condition options…