My point number 1 in the request to the Rhino6 development team is exactly what Mitch has alluded to… I did do the initial testing of the VSR plugin at the time it was still VSR, and liked what I saw… unfortunately Autodesk bought them and I retracted my decision to go for it. I still have to use the TSplines since there is some historical material already in TSplines and we’re current with the releases with the most recent update. Besides TSplines, is capable of doing things that I’ve yet to see in most of the software we use. VSR was great but still did not give enough control over the surfaces that could mesh with my workflow.
I wonder if anyone in the Rhino 6 development team has used NX’s Studio Surface or ICEM surfaces? For us the ideal solution would be to have VSR like capabilities along with a localized history tree of the areas that depend_on or those that affect the model based on some critical surfaces. The “history” is a truly lame tool for that purpose. Now, I didn’t for once want to give some solution based request here, since the Rhino Development team knows the limitations and advantages of their own environment better and therefore, could come up with an integrated solution that could be a huge positive surprise to us.
The second point I had was: lets say you’ve got an intersection between two surfaces, the control point count on that can be excessive. We usually have to had edit those points, if we want a 2 curve sweep so that the sweep can be reasonable in its weight. There should be some way to lighten such stepped flanges, tongues and grooves that could be joined to the surfaces within Rhino itself.
Its not to say that Rhino cannot do this or that, its to request the team to have tools that allow better control over what Rhino can model. In that respect, try to give us a better class A control tool set, such as the VSR tools, that is well integrated part of Rhino6.