Hi,
I would like to add regarding to matchsurf command, the ability to project the matching in a specific vector(x,y,z) or view, because sometimes it may get messy projecting by its normal.
Also when you want a good distribution of control points in a specific direction, a tipical case would be(as you posted above) the wheel arch of a car which is usually convenient to project in Y.
A lot of direct modeling softwares have this option available. And If I am not mistaken, the vsr developers wanted to implement this feature in the following version, but you all know what happened next.
I posted an image of how it could have been implemented this option in VSR.(it is just a rough idea) :
As I said many times, working with VSR changed my way of thinking about surface modeling.
I agree that independently of any third-party plugin project, the core of Rhino needs to grow and especially group tools having the userâs workflow in mind.
control points modeling The most important thing I think we need is a panel for direct modeling tools like the this. We have almost all of these tools scattered and hidden for not experienced users.
UVN, Drag mode, soft mode, gumball, points selection panel, organic toolbar, extend edge (plugin).
The T-Splines Viewport hud, had also some interesting ideas to get inspired. Many of these UX/UI ideas were the result of beta testing and suggestions from users.
Global edges Continuity We need to integrate another incredible plugin by @Gijs that itâs similar if not better than then one in VSR.
Persistent zebra/lights analysis with the chance to move the direction of the light and not just the model.
Symmetry tools integrated, [Pascal Script] (NEXT surface tools - #36 by pascal) to create a symmetrical surface (average around a cplane, or giving priority to a master side).
I just donât understand why we should look for external plugins or for other software when Rhino has all the potential to do anything without relying to others like Autodesk.
You pretty much explained it very well, and I will only add something that I felt was lacking in VSR. I have been using VSR for a brief period of time several years ago and the biggest thing missing in its âControl point modelingâ tool was the inability to manipulate two or more control points. It only had âSingleâ, âRowâ and âAllâ options, which is quite limiting. In many cases being able to modify 2 or 3 control points together is essential.
The HUUUUUGE advantage of Alias is that each of its major modeling tools have an âExplicit controlâ mode which lets you change the degree, spans and control point count at any time while some tool is still active! This is ultra mega extremely important feature for clean NURBS modeling. Itâs basically something like Rhinoâs own âRebuild surfaceâ put inside other commands.
Also, its âMatch surfaceâ sometimes performed much worse than Rhinoâs own âMatch surfaceâ.
The static light lines were a huge deal for VSR and to this date Rhino still lacks them. Rhino only have dynamic zebra stripes that change their orientation based on the camera angle, which is not optimal. It should add a âstaticâ option so that the user could lock them out and change their orientation through sliders and numerical boxes, as already seen in VSR.
I thought this too for a long time! But once I discovered you have to right click the spheres at the surface edges and select âPositionâ (this is how you unlock the maintain isocurve direction option) VSR 99.9% of the time does far better than standard MatchSrf. Thereâs so many more options to the VSR one, but if you donât get them all right, itâll make a funky result.
Also right on to highlight what @Gijs did with his global continuity tool! @theoutside have you played around with it? Itâs frankly what should have been done for V7 by McNeel.
I was going to type up a post of all of my âsecond order wishesâ but you pretty much hit them all in your post. Especially the ability to select different point distributions for Rebuild (surface and curve). VSRâs ability to select Original, Arc Length and Curvature are exactly what should be in Rhinoâs Rebuild.
That feature was requested so many times, yet itâs still not implemented in Rhino after years of asking. Hopefully it will be done for Rhino 7 later this year (hint hint), because the inability to preserve the control point flow while matching with G2 is the biggest missing feature in âMatch surfaceâ at the moment (along with an integrated âRebuild surfaceâ in a similar fashion like the âExcplicit controlâ in Alias).
To fight against this lacking feature in Rhino, Iâm forced to spend a huge time with manual adjusting individual control points with the âMoveUVNâ tool, which is not optimal for more complex shapes with a higher control point count. Of course, doing this manually relying solely on the Zebra analysis results in something like an approximate G1,95 (not a full true G2).
Another feature requested a lot over the years was to include UVN indicators for the various commands. You will notice that the VSR tools have those indicators showing automatically upon clicking on a surface, which is a great way to get a better idea about the UV directions of the surface. The N indicator lets you know the normal direction, and I wish that the Rhino team will consider to make it possible to click on it to flip the direction of the surface, without the need to cancel the active command just to start the âFlip directionâ tool.
To me Kajto in its current form already seems more complete than VSRs last version.
It has countless options for every tool and can also be a tad intimidating, but I guess that is the nature of class A surfacing tools.
Granted, I only scratched the surface on the trial version so so far and those specialised surfacing applications are a different beast from ânormalâ surfacers like Rhino so getting the hang on those applications can be challenging.
I remember being quite clueless when I started using VSR 9 or 10 years ago.
I think @sgreenawalt is referring to the âpoint/g0â option for edge conditions.
This resolves many challenging matching problems that Rhino wouldnât even dream of attempting to solve.
The lack of edge conditions and control point blending are the main factors limiting Rhinos match surface in my opinion.
P.S.: add to this the lack of explicit surface control of the matched surface.
As I said, from my limited first impressions Kajto seems rather feature packed.
Blending and matching have multiple options and some more are hidden via right mouse clicking the matching labels and arrows (similar to VSR).
Also all blending and matching are supposed to be parametric and even transforming multiple surfaces associated by parametric matches is supposed to be possible (at least that is how I understood it, documentation is quite cryptic and sparse)
I may contact the developers for some tutorials or an in depth introduction.
We never want to write our own tools that will directly compete with any of our third-party developer partners. That would be a âvery Autodesk likeâ thing to do.
The danger is Autodesk or some other company buys up that third-party developer and holds itâs userâs hostage. This has happened a few times and either another developer has stepped up with a different approach, or we decided to develop our own tool.
Every software has the potential to do lots of things.
The truth is, there are some very specific surface manipulation tools that software like Alias, ICEM provide, that in Rhino simply donât exist.
VSR was a giant step in making Rhino capable of some of these functions for a fraction of the price of those programs.
Thatâs why the VSR users (myself included) are still making such a fuss about it, even though Autodesk killed it 8 years ago.
I know what you mean, but trust me, I have been testing the VSR at the time extensively, especially its match surface capabilities. In certain cases VSR had quite a lot of limitations compared to Rhinoâs âMatch surfaceâ tool. The biggest drawback is the inability to control the number of spans with VSR. It only lets you modify the degree. I had cases where VSR produced a surface with 20-30 control points despite being just degree 5 or 6 or 7 while trying to match a single surface to a trimmed edge of another surface. One of those cases produced almost 60 spans with degree 3. That was an overkill.
Okay, now I get what you mean.
That is happening when you apply âadapt order/degreeâ and âadapt parametrizationâ to trimmed edges. This sometimes leads to super high density surfaces.
In these cases reapproximating the trimmed surface edge or rebuilding the surface to match and then matching without âadapt parametrizationâ can solve the problem (usually the goal in VSR was to not use those to chechboxes to often).
But you are completely right, explicit control of spans/degree during matching was missing from VSR too.
(Kajto has this function IIRC)
These VSR tools are extremely similar to what is offered in Alias. I especially like the way the hulls are displayed (with the option to differentiate U and V directions, which helps in cases where thereâs U or V input). For some reason, their tools feel more fluent. more responsive with visual feedback as to how the CVâs are transformed (as @sgreenawalt indicated in #1 Control Point Modeling tool). I think Rhino should also improve upon its display modes and provide more options for hull display in terms of linetype, weight and colour.
And perhaps an Auto Points On checkbox/ preferences, to show the Points during specific commands, such as MatchSrf and Rebuild and disable when done. Basically, if commands give sufficient feedback when they are active, this reduces the need to go back and check, thus saving lots of time on something trivial and rather dull to do manually.
But other than following some Alias tutorials to improve my surfacing knowledge in Rhino, Iâm far from an expert on the matter.
