Before you ask… We do not have a ship date scheduled. Rhino is always released when it’s ready, and not before. We really don’t know when we’ll be done.
There are several milestones in the Rhino development process as we work our way toward shipping a new version. The milestones look like this:
Work in Progress (WIP) - we put out weekly releases, adding, changing, and generally making a mess of things.
Feature Freeze (Apr 18 2023) - no new features are added (either big features or little ones)
User Interface Freeze (May 9 2023) - no changes can be made to the UI. This includes icons, command prompts, command options, menu entries, or dialog boxes.
Beta (Date unknown) - We’re down to little bugs and are wrapping up the documentation and localization process.
Release (Date really unknown) - Rhino is finally released, you can buy upgrades, and we start over with WIP for the next release.
We are making our way across the Feature Freeze milestone this week. There are actually a few little things we’re still working on - mostly related to clipping and sectioning, and also Cycles X. But generally, Rhino 8 is feature complete.
Our current work is focused on Milestone 2: UI Freeze. We know there’s a lot of work yet to do, especially in areas like dark mode, editing toolbar buttons (but it’s a lot better this week), and sharing Window Layouts.
We need to hear from you - especially if there are parts of Rhino that are embarrassing or not up-to-standards in the UI or user experience department. Especially regarding the new stuff in Rhino 8.
Based on my reading the forum, it seems that the highly experienced users who actually make heavy use of the UI customization ability don’t think the UI is anywhere near usable right now. What ever happened to “when its ready” with a “UI freeze” imminent within a time frame that decades of experience with WIPs suggests there’s no way everything that nobody likes can be fixed (unless it’s already fixed and you haven’t turned it on yet).
Any chance you can publish here a list of all the UI changes you expect to incorporate before the UI freeze?
Will McNeel go bankrupt without rushing V8 to a premature release before we users tell you it’s ready?
Ok, go grab a coffee, pull up a chair, and let’s have an honest discussion, or hugs are good, but not great, and maybe they can get a bit better…
Seeing you have a feature freeze this week is kind of disappointing, considering that V8 was been so fragile that I barely got to use it at all. Probably I have about 5-8 hours total in V8? I mentioned my concerns about this entire WIP process here just last week:
I have no idea how any of the new tools are. I started testing Shrinkwrap last week and saw a lot of potential but also lots of limitations.
I guess this version of Rhino will go out without much of our feedback, that’s ok, I guess. It’s not that there been a ton of action on the feedback already provided. seems you guys are busy on other stuff, and this V8 build seems to be a Grasshoper infrastructure + Mac porting release.
I look forward to start the V9 cycle with an actually acceptable, working toolbar/workspace system + allowing me to save files with compatibility with shipping version so we can help Rhino to continue to improve in directions that matters to some of us and our industries.
So let’s talk current problems (P numbers below) and possible short term solutions (S numbers below). P & S numbering are not related, since in my solutions list, focused on short-term stop-gap solutions, for some things I have no suggestions or are not applicable.
In terms of embarrassing at this point, IMO @brian, just one thing:
P1. Any regressions in toolbar padding and borders. V7 was already bad compared to any modern software, we can’t go to worse. We just can’t. You need to make it better. A lot better. Also adding any more work to customize a tool, or edit/replace a tool icon is a non-acceptable regression. I’m fine if you add nothing new on a release, I’m not ok when you take things away. This is a huge deal.
Semi-embarrassing but survivable for one more release:
P2. All SubD selection tools: speed, feel, limitations, lack of basic tool for propagation, selections painting, selecting outlines, borders, coplanar faces. Even selection filters being ‘bundled’ between Nurbs faces and SubD faces defeats the entire purpose of filtering.
When you model in SubDs elsewhere and come to Rhino to finish things up, add mechanical features, nurbs booleans, planar caps etc. if I have to make any small edit to the SubD model it feels like someone asked me to model with boxing gloves on. It’s pretty pathetic if you know. But I don’t think you guys do.
P3. SubD conversion. We need to use Tsplines (live on on an archival quality laptop just for this), or Fusion 360 (PIA in terms of cloud, login, performance). This also slows down the entire ‘finishing/converting’ things with Nurbs in Rhino. I do understand this stuff is very hard, and only a handful of people in the world know how to do it.
P4. SubD viewport and transform performance. I know you de in love with your limit surface, but you should give us a way to only see in smooth a specific object, not all or nothing. Have you ever tried to load just one quarter of a SubD car interior and try to work out a dashboard detail in SubD? It’s not viable.
P5. Meshing. We do a lot of STL and mesh based output. The Rhino meshes and it’s settings continue to fail/lie and not follow its own rules. Remember Mesh2? Whatever happened to that effort?
P6. Fillets. They are bad, a disaster actuall, but has a possible workaround in the solutions section below.
Enough complaining from me. What can McNeel do in the short term to help advanced users? Let’s talk solutions…
S1. Rhino-Blender live link:
This would go a long way to better work around all the SubD modeling and performance limitations do Rhino. Useful for folks like us doing industrial design + physical prototyping + virtual photography (niiiice renderings). @nathanletwory, this could be us but you playin’: https://youtu.be/CwlHwgtUG4k&t=5m3s
S2. Help us by helping Xnurbs.
Surfacing tools are barely advancing, Xnurbs is excellent, and please ignore the absolute nuts academics, niche automotive (irrelevant market by numbers) and the OCD types that do not run a business or do not create toolings-release quality parts constantly they talk crap about Xnurbs, they are noise. Please ignore them when we are talking business. Xnurbs is fantastic for many of us, it could be for 100X many more of us, but they do not know how to run a company, and you can’t blame them. You already know that being a plug-in developer is a losing proposition, maybe you can help change that. This is how you can help all of us by helping them,
S2.1: offer to port their super shitty licensing system to Cloud Zoo. You McNeel, do the work. They can’t. And we need it. Badly.
S2.2: build a grasshopper tool for Xnurbs. Like what @Gijs is playing with. I haven’t tested it yet because I’m having licensing nightmares to solve first, so I can’t even run Xnurbs! (See point S2.1)
S2.3: sell Xnurbs. They won’t survive if they don’t make money. @RhinoFabStudio@carlosperez, you can take on this. Invite the guy (expenses paid) to the next developers meetings and work out a win-win deal. You know how to do this. Do it for us. Make a nice contract that even is ASDK, DS or Siemens buys then we get to have living code for 5 years. That’s all the time needed to build a patch tool in maybe Rhino 10?
S3. Fillets. Do I need to say more? All I can tell you is that buying Plasticity for $99 solves 99% of my problems with fillets in Rhino. Export the parts I want to fillets as step.step, fillet (and or Boolean sometimes) export bask a step to Rhino. Can you PLEASE make a bridge/plugin to Plasticity to do this more elegantly matching all properties of filleted parts back a after import? It seems you are putting a ton of effort to play well with Revit, Acad and Sketchup, but zero effort for any MCAD pr SubD/Animation workflows. We need better that zero. Yes plasticity can go away in a year or two, so what? It pays itself in 1 day for a US company, 4 days for an European one, 2 weeks for the rest for he world?
Putting all my complaining in context. I think Rhino is doing great, compared to any MCAD software, what we can do with Rhino is absolutely amazing. I’m taking here about things like ‘feel’ and flow in SubD with packages like Fusion360, NX, Catia, and Solidwoks tinker cloud $$$ have potato shapers called SubD modelers, so I’m not missing that subtlety.
I’m also complaint about performance when loading “one quarter of a car interior”, I know, in Fusion 360 the fastest computer just melts loading just a detailed steering wheel alone, also try to load a typical 1GB Rhino file of an industrial design/product development project with a handful of concept options with shelled/ribbed housings, some hardware and internal components in Fusion or Solidworks; it’s pathetic, unless it’s a filleted box.
I complain because I care, and also because you matter, more than what you can even imagine. So thanks so much for all the work you do. And for listening, and maybe acting on this in the next… 10 years?
I hope this helps.
Gustavo
(PS: Sent from a phone, might come back later and edit autocorrect and dyslexia horrors)
Yep, that changed a lot this week, and continues to improve.
Thanks, this is exactly what I’m looking for. I presume you mean “in Windows” since the padding on Mac has shrunk dramatically in this release?
This is in active development and improving as we speak.
Yeah, it’s a much newer feature set for us, and there’s still a lot of work to do. i hope your boxing gloves are stylish while you use them.
I presume you’ve logged bugs with specific models about this? As far as I can tell, all our SubD > NURBS conversion is perfect. Words help us understand there is a problem. Examples help us fix the problem.
We design software, not cars - do you have an example workflow you can share?
That’s an interesting idea.
Parasolid has always been better at filleting than Rhino, I agree completely.
Aw, hugs all around. Thanks for taking the time to give all this detailed feedback.
I assume this UI freeze also applies to the macOS version?
not being able to change the font type or size in the command history is a problem. The font is small and not suitable for many workflows (and eyes!). It looks like you just went with the defaults and said ‘whatever’
UI color customisation in macOS is pretty much non-existent. And it should not depend on the system theme settings. (who even thinks of hard-coding that?)
the awkward command prompt placement inside the main icon panel is still the one worst idea you ever had.
as of now there is no way for a distraction free modelling view with only viewports, command prompt and command history. Everyone is forced to give up 20+% of screen space to a vertical panel that houses the command prompt…
Still, its a step up from V7 for macOS, but its unfortunately far from what it should be. The strange part is that it should really not be that hard to make these changes to consolidate this core functionality (the command prompt) between mac and Windows, yet the people here tell me its going to be in V9… Thats half a decade away… that would be too little too late…
PS. just have a look at blender and their UI - there you can see what a customisable and user friendly UI nowadays can be. I know they wrote all the UI-code themselves, but even the electron framework gives so much better (unified cross platform) UIs and customisation basically for free and even a one-person team can handle this (e.g. Plasticity)… (+ the possibility to change pretty much everything in the UI with css+javascript)
I like the idea mentioned above about the ‘live’ link to Blender. I use Rhino to create my models because I have been using it since v2 and am very familiar with it.
I need Blender, because Rhino just can’t do the animations for working with the Unity gaming engine (as far as I know).
Importing FBX files with animation (created in Blender) into Rhino, breaks the animation.
Making texture maps still seems a lot easier in Blender than in Rhino.
Finally I saw the mention above about a new upgraded Mesh system. I would like to see more of that, and a better way of reducing mesh TRIs or Quads.
Better texture mapping tools would be amazing. The custom mapping option makes it possible for me to map multiple textures onto a single object using a workflow involving Substance Painter, but it’s still incredibly cumbersome compared to having the entire workflow baked into one piece of software like Blender has. But this is an insanely complex feature to add at this point.
Not just at this point. It’s a crazy complex thing to tackle ever.
The idea of asking McNeel to make Rhino to be best-in-class at everything that every other package already does is a moot point, delusional and a guarantee advise for them to go out of business. But thankfully of course they know better and will always ignore this advice.
This is why I made this joke last month:
The best strategy IMO continues to be making Rhino work 10X better with other software packages.
This is why I want as part of V8 (these are not huge projects, quite the contrary):
Blender Live-link
Plasticity ‘quick fillet round trip’
The idea of a Bridge to Substance is a nice gesture, but I have no idea who is this tool built for, but for us it has absolutely no use, because we only send our work to Substance after it has gone to Blender + RizomUV. Because we would waste too much time modeling all our SubDs in Rhino instead of Blender, or also waste too much time UV unwrapping Blender instead of in RizomUV.
Specialization and interoperability is key for professional results and I really want McNeel to embrace that, beyond the Revit market.
Fonts are designed for different use cases - and when using single words, especially in a technical context where letter combinations can be arbitrary and not meant as readable words but rather identifiers, having the default Arial / Helvetica / Segoe etc. font is just bad design.
I mean, you can keep it, but at least let us customize it! (command history the same)
in resopnse to the RH-74360 - It is not about a user complaining the font is too small - it is about basic ui/ux considerations
The font size for command history is the same as all the rest of the Rhino UI - all the dialog boxes and sidebar panels. If those aren’t legible, either, I think you can fix this by making fonts bigger in macOS preferences.
I think that might be coming, it’ll be an advanced setting. I had hoped that color customization would be based on two or three colors, and the rest of the UI would update. We’re not quite there yet.
Sorry, it’s kinda stuck that way for the time being. We hope to have a unified command prompt (one that can be universally loved/hated by both Windows and Mac users) for Rhino 9. I think the only reasonable option is for there to be three or four options: Classic Windows style, Classic Mac style, and a new one (that incorporates buttons and checkboxes like Mac, but can be arranged either vertically or horizontally).
