Somewhat wrong, mostly correct. There’s an accuracy issue, especially around star-points as far as I know. But even if you could convert a nurbs patch into a sub-d and back without issue (you almost can), that still doesn’t solve the problem with complicated trims. A nurbs trimming curve may be very detailed while the control-net of the surface is very simple. Sub-ds do not have trims so you’d have to add a lot of control-net density around complex trims and creases. This makes the sub-d control net unmodifiable by hand.
Neither. We’re implementing a limit-surface approach. Each face in the control-net becomes a single analytically accurate surface patch. Some more details are explained in the document posted waaaaay up in this discussion.
We’re coming pretty late to this sub-d thing, so it’s unlikely we’ll start outperforming established packages any time soon. However our take on it is somewhat different from programs like Blender. We’re more concerned with accuracy and fabricability than with organic modelling. If you want to model a face or a tree-trunk, Rhino probably isn’t the best choice, with or without sub-ds.
The thing is, that in early design stages as far it comes to architecture or design - you don’t really care about precision. You care about doing things quick and effectively so you can present it to your customers and establish comunication.
Once things evolve and designs get more serious and are approved, then the NURBS-modeling process of Rhino is fine.
But in the beginning, when you think about different solutions and want to model and modify them quickly then the whole Mesh/sub-D thing is extremely important.
You want to quickly smooth, edit, add, distort without wasting too much time.
Modeling things precisely is important once a competition has been won, a client has approved and a company wants to produce an idea.
In my opinion Modo, Maya and Blender do this early process better and I don’t see why Rhino should not implement that capabilities asap. Espescially because it is a pain importing and exporting 3d-models between diffferent software packages.
My suggestion is that McNeel should take this topic extremely seriously.
You really should try the Mesh Utilities in the v7 WIP. It is a different process from Blender (trust me, I’ve modelled for quite some time in Blender), but it is shaping up quite nicely. These tools should work well with SubD eventually.
Can anyone please confirm these are WIP commandnames to be changed for sure before release?
But since it would not be the first time that poorly though about commandnames end up in the release:
Most if not all of the above commandsnames are generic terms that can apply to any type of geometry.
There is for example already enough confusion about ExtrudeCrv and ExtrudeSrf.
At least name it ExtrudeMeshFace or something. Do not hold it off until later because it has proven to not happen.
You are creating a very powerful versatile new toolset with just the first handful of command already starting out ambiguous. Is someone at RMA responsible for the naming of the tools, doing a proper estimate of future expansion and of possible conflicts and ambiguities?
Does anyone even consider finally cleaning up the complete mesh toolset including toolbar organization and button design. Purging or fixing not working tools like the mesh booleans and intersections.
If the GUI aspects of this SubD endevour is going to be build upon the current implementation of mesh related features and command, it’s starting of on a patched-up feeble foundation, unable to bear the load of the subD toolset that is -hopefully- going to be expanded into many more commands and features.
As for the commandnames:
A commandname as generic as Append can just as well be functioning like Join or BooleanUnion Bevel is for chamfering solids right? Bridge is to connect 2 curve ends right? DuplicateFaces is like Extract with the copy option right? InsertEdge, not sure what that does, something to split brep faces? InsertPoint, but we have InsertControlPoint right?
I could go on but I assume the message to be clear:
Do not assume thing to be fixed at the end, keep in mind that command naming and GUI design is the fist thing users encounter when engaging is the new SubD features. Even for those only checking out the WIP progress every now and than. If that look and feel get’s less love than the hard brain-crunching work the developers put in, you start off at a disadvantage for users will assume the features to be as ‘wippy’ they appear looking at GUI aspects like naming, the lack of a toolbar and confusion about what is new.
Why not create a SubD toolbar tab in the WIP. Fill it with just text buttons if need be, but at least it expos it to those trying the WIP. It will be extra effort to update the toolbar before (each) release but at least it’s development goes in sync with the expansion of the toolset and at the end it’s already there. No need to fix stuff that was not foreseen or never thought of in the first place
Note that this comes from a user -myself- who used to spend many hours exploring new features en enhancements. The last couple of years I’ve spend less and less time modeling and currently I’m almost exclusively programming with demanding goals set. This leaves me with almost no time to do that kind of exploration.
There must be many users like me with no extra time at hand to explore and discover. I think it wise to make this as accesible as possible. Most users do not even come here, those who do and actively search for new SubD commands are even fewer. If a regular user would open up the WIP on a late friday-afternoon, just to check it out, he or she should be welcomed with the latest new implemetations. They’s see a new toolbar tab named SubD. Click it and find buttons with unknown tools. There would be a first button that fires up their browser showing preliminary tutorials on Rhino’s new SubD toolset ( made by RMA this is just an examle). Or link to documentation
I think with some effort to make stuff discoverable right from the WIP toolbars and not on a forum or elsewhere, much more user will be encouraged to try and test new features.
a render engine that has not great defaults and a material library it doesn’t exist. It’s just a developer’s illusion.
a new toolset that has no toolbars and a simple help file/URL/Video linked to it showing (not typing) what each tool does it doesn’t exist. It’s just a developer’s illusion.
If you continue to make new tools so inaccessible you will continue to attract only the most motivated, least representative type of users of your potential user base. You are just creating a nerdom-vicious-cycle. It’s a comfortable and easy echo chamber, but it’s not effective to make you succeed IMO.
New new rule: forget ISO & Six sigma. Just ship a god damn toolbar and a YouTube video link. No matter how rough it is nothing is rougher than a command-line-only anything. That’s just brutal man, brutal.
Yes. A big +1 to Willems and Gustos comments from me.
To say that the new command names for the Mesh Utils are not discoverable is putting it politely. I’ve actually had to print them out and stick the list up next to my monitor.
Your existing toolbar is just fine Nathan “coder art” icons and all.
More and more little tooling shops/machine shops, model makers, semi professionals use Fusion 360. But maybe those numbers are wrong. If Fusion 360 has “demonstrably” no market share as you say, then please share your insight! Can you present any numbers to back that up?
You are right, CNC and hobbyists are two very different markets that happen to align together in finding Fusion useful. I was thinking only in term of industries that need complex modeling: product design, footwear, automotive, architecture and engineering. Those are the markets I see and where Fusion pretty much is non-existent.
I think they could make a lot of gains in these other markets too but only if their modeling tools and handling of large files massively improves. I don’t see that happening anytime soon. Probably they see faster/easier growth by continuing focusing on the two verticals they do today.