Today I just wanted to make some quick edits to a SubD bracket model (modeled in Blender) and I’m shocked at how time-consuming and full of errors, oversights, and untested tools the workflow still is (running Version 7 SR14 (7.14.22010.17001, 2022-01-10)) here.
Quick stream on mind of all the things that this morning made me shake my head:
Bridge only accepts edges, not curves, not polylines (using nurbs curves as input to new SuD geometry is way faster that slapping around cubes into shape)
Bridge’s result can be all creased or all uncreased. Many times I want each side to have a different setting
(Re: item 1): I could do an annoying workaround of extruding a polyline, or extracting the control polygon of a nurbs curve to also acquire its faceted polyline, and then extrude those so I have edges to bridge… but No. Extrusing are a different object type, and convert extrusion converts them only to nurbs, not to polygons.
Face filter selection also grabs Nurbs faces on the model, making it kind of useless
Edge filter selection also grabs curves on the model, making it kind of useless
Running a command that is not compatible with the existing selection filter, should cancel out the existing filter because I obviously want to run that command now.
An Object with Reflect applied, should only let me select one side of the model, right?
Undoing a transform sometimes loses my selection, sometimes doesn’t; it’s badly implemented. Selections should not be dumped by Rhino
SelPrevies does not always help in the case above
a very time-consuming workaround of problem above is saving selection sets. But don’t you ever misspell the selection name, you cannot edit the name by placing the cursor on the name to change/add a letter. You can only retype the entire name. Inconsistent with any other naming dialog
Some tools work in SubD but not in meshes. That makes absolutely no sense.
Gumball scaling on a close loop of SubD edges shows no realtime preview of the change as I drag the scale handle. I have to scale, only after the scale is committed the geometry would update! (Update: this does not happen always, it’s erratic and inconsistent behavior)
This was all experienced in just 1 hour of work, with a handful of tool, for some edits that should have taken 10 minutes. So frustrating.
How much of this has been solved in V8? Because in the current updates in V7 this is all pretty terrible. I’m sure this is absolutely awesome for SubD newbies and for people that otherwise would model all things in Nurbs, but I think you should aim for a professional tool here. This isn’t it.
The result is the same, the difference is that I want to use Bridge because Bridge is more heavily used and I just have to right-click to re-invoke Bridge again. Also on one side, I might have an edge loop, on the other side a curve, or polyline. This mix in inputs to create geometry is extremely common in production work. Especially if I’m surfacing around an internal component, I want to use one of their duplicated edges as curves for input.
Rhino has no way to accommodate for this reality.
Two new more things about Bridge that make no sense IMO:
The tool lets me pick a combination of edges + faces…
in your example of mis matched edge inputs, that result is (as you well know) not a good result for subd.
The problem with your suggestion is creating a tool that allows folks to go way down a path to making a model that is no longer editable or very difficult to edit or fails when you try to get to Nurbs. Tsplines had the same condition limitations for bridge for the same reason.
remember our stuff always has to be able to convert to nurbs, where blender zb, etc does not and as such they allow more liberal inputs.
I’ll make some YT items to address some of your or other points.
I know that from a mathematical, academic, and dealing with inexperienced users POV, what you are saying makes perfect sense. Thanks for pointing out the reasoning behind it.
You are somehow familiar with my surfacing standards, and I can tell you that we have released geometry with star-points and other non-quad elements (what mismatched bridges would produce) from which many millions of dollars of tooling work has been created. And hundreds of millions of dollars in prudcts’ sales have been generated. So please, do not get in the way of progress. Remember your toy-industry days? Remember the tooling polishing G2 techniques?
‘Our’ as in McNeel? …because not ‘Our’ as in my company and all my clients. We move seamlessly between Rhino/Clo/Blender/3D Coat/Substance/Modo/etc. We do not want Rhino to be the tool that lags behind because all subD work is only meant to exist in the service of Nurbs translations with an academic flare.
This reminds me of all the arguments we had a decade ago before McNeel would finally accept that Ngons are a thing and should be supported.
I hope I can change your mind, because your current criteria are extremely counter-productive and disappointing, and it’s penalizing professionals trying to use your tool as a “free-form modeler”, let’s not forget what Rhino is all about. Please.
I am always open to changing my mind and joining the fight for making things better, It is super helpful to have examples we can look at and help us understand what need to change. Please send over models we can use to reproduce your issues.
Interesting UI, IMO Rhino needs to be this innovative OR adapt industry standards. Right now the workflow is neither. Adding faces should be superfast to do, intuitive and intelligent, not tedious and cumbersome.
So even though I know it is against McNeel standards I reccomend taking some master classes in other software to experience what the Rhino users are used to deal with when they are not using Rhino. I think it would be healthy, and it honestly doesn’t take more than a few days to follow a course.
Thanks for sharing. I agree with your point, everything I commented here is extremely basic and needed functionality in any SubD modeler. Right now Rhino’s tool in Mesh/SubD make it the worst modeler I’ve ever used and I’ve ever seen, even worse than Tsplines, which was already very clunky, slow and full of friction. And it’s been too many years of this extremely slow and extremely uninformed progress in Rhino. Also some of the decisions they made (“you can’t bridge unmatched edge count”) make absolutely no sense, they are decisions that only help reduce support calls and ‘risks’ by untrained users, penalizing all professionals like ourselves along the way. Terrible strategy IMO.
Your example of Cozybrsh is maybe too much on the other extreme: very innovative, forward thinking and also limited to pen use, which probably is useful for less than 1% of Rhino users? From an impact point of view is kind of irrelevant.
I want to make sure we do not confuse my ask for basic, tested, informed, complete and logical toolset with fancy stuff like this video. Let’s get the super-basics right before we ask them to get fancy.
I absolutely support that, and the point with the video wasn’t to show how one can model on an existing mesh, but to show how complexity can be simplified.
I hope your time spent on highlighting your needs results in more focus on user friendlyness (both for pros and newbies). The underlying tech is IMO robust and fast, but the UI is underdeveloped. Even the idea of having a separate tab for SubD is strange in my mind. And as you say, separating the tools from mesh tools is also strange. For us users both geometries would benefit from a joined and coherent development.
Fast? Compared to what? If you are making a spoon, mouse, or rubber ducky yeah it’s fast. If you are working on a car interior is not. Waaaay slower than Modo and Blender. Also without an option to have most of the model faceted and only have smooth the objects you want. So it’s either all faceted, or all slow.
Robust? Compared to what? Lots of snapping that doesn’t work, selections get lost, custom pivots get lost, display errors too frequently.
I know McNeel keeps asking me for files, while I keep asking them to hire a QA tester or two, People with SubD modeling experience. The world is full of them. We have our own business to run and all our time needs to go to do client work, not free testing and reporting for McNeel.
Robust as in core "subd nurbs " (in lack of a better word) technology and how it handles the cage once the cage is perfect. What you are talking about is a combination of UI and making a super simple cage. So IMO the core has the potential to live a long life just as it is. Meshing of the SubD is a different thing, I too would like to fine tune each objects display mesh subdivision level and also have the ability to extract a simpler nurbs version. But that too I consider a level or two above the core. (for the user it doesn’t matter though, as all is fused together in the experience.
Struggeling with snapping is a pain, having to replace face by face until the cage consider itself closed enough to actually snap.
@theoutside
I think that wasn’t his point.
He was pointing out that rhino’s approach to UI either needs to be innovative (in a similar way as in the example of cozy blanket) or it should try to keep as close to industry standards as possible.
