I’m sure you already are but you need to be hammering us with the failing examples so we can fix them. Feel free to ping me directly and I’ll at least make the issue and get it on the right persons list.
Can you start a thread about this and go over the gaps in your workflow and what’s too slow?
What do you want to do with blocks that you can’t?
I have no idea what Rhino is doing. But I know I can take the exact same model with the exact same PBRs an it spins smoothly in Blender. In Rhino after reporting the issue to the they got to to work at 30-45 PFS. Not useful for design work.
When a computer stops to keep up with you in realtime, it creates a lot of frustration, anxiety, and distracts you from what you should be doing: not thinking about the computer, and be focused on design, modeling, creating scenes, etc,
Nothing is good enough for cycles in Rhino, it’s still very slow. We don’t do any rendering work inside Rhino anymore, only OpenGL viewport screenshots, and for most of our work those are great to document daily progress.
For rendering we use Cycles and Octane in Blender, and both run great there. In rhino, the whole flow of work is extremely slow, not just rendering, but creating materials, applying them, changing viewports. Again, it all feels like I went back to a prior decade of computer performance. So we decided we are done with it until that changes, if ever. This is why what I want the most of the McNeel development team right now is a live-link between Rhino and Blender.
-better editing in place sketchup like
-editing of non uniformly scaled blocks
-defining block axes not only insertion point, when redefining prompt to ask if instances position should adjust to new axes or recalculate to remain in same position (very important when you decide to change block definition deep in the design process resulting inn instances to change position)
-i think blocks should have both definition user key values as well as instances should have separate key values thus two level hierarchy
-acapulco plugin and blocktools have few very useful simple functions just implement it in rhino (some already are in wip8)
-improve macros so they can handle blocks better (quit block editation)
Elementary stuff, mostly drafting
-rich text editation like in autocad
-scalability of texts
-richer annotation settings like in autocad (dimension line invisible, if there is no space for dimension have leader to value, more units available (such as gradians for angles)
-support .shx special linetypes like in autocad
-detail view to be any shape not only rectangle like in autocad
-improve Fx in texts so that there is some kind of placeholder instead of long code to extract attributes
-have ability to clip/crop regions of linked files/blocks with any shape like in autocad
-new dimension type to be able to easily annotate in 3d space like in sketchup
-new dimension type to dimension curves like in autocad
-new dimension type for elevation ordinates like in allplan
-true reliable technical vector display mode which is actually usable
-expand clipping planes to include clipping objects of any shape, jagged strings of clipping planes, possibility to create unrolled views and advanced views such as jagged views
-save display modes in file
-audit commands to respect current cplane not only world cplane (cap, …)
-cap all holes like in gh (suboption of cap)
-improve reliability of some most important commands (fillets, booleans, …)
-grasshopper to support referencing subobjects
-general audit of consistency (like you can selby whatever but you cant selbylineweight or printcolor…)
-audit and refinement of some commands to support two sets of selection
-booleans to support any type of geometry
-intersect two sets should support any type of geometry (meshes are not supported)
-support project origin which is arbitrary point far from world origin and operations are calculated in respect to project origin to avoid far from origin problems. global coordinates would just be addition of project origin - world origin
-pushpull like in sketchup, support collapsible breps (when you make hole in a wall and move some face of the hole to the end of brep resulting in zerothickness region should automatically perform boolean difference and delete zero thickness *optionally or have a prompt what should happen)
when this is done i would then move to new territories such as dynamic blocks, flair, constraints, …
what i have mentioned is something very expected from universal versatile CAD package, nothing too specific for any industry. honestly i expected at least “Elementary stuff, mostly drafting” to be a priority for v8.
Thanks for your interest on this. Let me please get you up to speed with feedback already provided.
I used to send a lot of examples, and I’ve seen with a simple search here on those that lack of examples provided by uses here doesn’t seem to be your bottleneck. But please let me know any very specific areas you are thirsty for examples and then, only then, I’ll stop doing billable work and gather those examples for you.
I’m going to ask you the same thing that you guys ask us, your users: Please be specific, provide me descriptions of the types of cases you are interested in, what kind of geometry problem you are trying to solve. Examples of intersections, number of edges, snippets of code, screenshots, etch will be helpful so I can focus only on relevant examples and I do not overcrowd your system with repetitive examples of failures that we have all been sharing here ad nauseam.
Are you sure you need more threads on this? Why don’t we start reviewing the top search results from my posts alone on SubD friction and limitations? I think most of this is still unaddressed AFAIK.
From August 1019:
Also April 2020:
From February 2021:
From February 2022:
from December 2022:
In summary… lack of feedback probably ain’t the problem. Don’t you agree?
I didn’t say it was. I just saw your top 15 were kind of broad so I was hoping to hone in on your problems.
Well I was trying not to get too off topic here but it’s fine. Thank you for linking the posts. It seems like a lot (most [all]) of the problem for you is selection. I get it. The CTRL+Shift approach for subobjects is time consuming and awkward. I don’t have any good answers about marquee/paint select outside the commands which you’ve already been pointed to quite a few times. The one reason I can think is making those default for selection breaks muscle memory users have built with dragging objects but I know that doesn’t help you.
As for this one:
Hopefully I’m not spilling the beans on anything but there are two advanced options being tested right now that might help.
With both those options set to True the object you’re about to select will highlight and if CTRL+Shift is held down the subobject you’re about to select will highlight. One quirk I noticed is it quickly becomes painfully obvious how bad selection can be (even in a simple example a SubD edge behind a face will highlight even though it’s not visible). It also looks like the SubDs aren’t highlighting correctly. I’ll log that.
It’s in the WIP so you can check it out and let us know what you think.
Also, I know it’s time consuming to type this up so thank you for doing so.
This thread got a little contaminated already, so allow me to upvote some just here:
Oh yes!!! +1
Partially possible already with a SplitFace and ExtrudeFace worklfow. Use this option:
What I would like to see here is SplitFace supporting drawing zigzag lines on a face, not just a straight line from one edge to the other.
Edit: Such a tool should maybe called differently, “Knife” maybe, seems to be unoccupied. Numerous polymodelling 3d apps have it. One for nurbs would be great!
Edit2: Just read Joshua’s post. Well, could work. I’m just not happy yet with the way autocplane works.
How about a persistent lasso/ paint selection? In other software, like Blender or Illustrator, you switch to a different selection tool if the rectangular selection region is not appropriate for the task at hand. In Rhino, you need to fire-up the lasso command for each and every selection action.
I am into the same situation. I do furniture design and all advertisement jobs into the furniture design industry are asking for SolidWorks skilled designers because in SolidWorks you can quickly adjust the thickness or sizes of different materials that are used in the furniture fabrication. Well, in Rhino I wish you luck if you will try to do the same. Possible, yes, easy to do so, NO way.
That was a great thread Brenda. There are a few other excellent ones too.
Citing lack of feedback and asking for more examples on how to make Rhino better has become a very common distraction by some McNeel folks here. Especially when they asks us to provide examples of stuff that they are only a search away.
This tactic is starting to feel like placebo, and frustratingly disingenuous IMO. Maybe unintentionally, but it’s worth pointing it out.
We did write a block manager replacement and are looking for feedback now. The block manager features implemented were driven heavily by the above thread. Now we need to know if it actually works for people and if there are any gotchas that need to be addressed. I get it that the typical response is “I already told you”. There is just so much information these days from so many directions it is difficult to know if we have improved the workflows for individuals.
My experiences with the block manager, were from when I worked on a groundskeeping-type machine for a friend. It have over 1,000 parts, including nuts, bolts, washers, screws, bearing faces, clamps, and well it had parts too. A provisional Patent was written for it.
That stated, the Block manager is by design a useful function, that reduces both effort, and resources. It also helps with collaborative designs. McNeel has made a few improvements to the Block manager. I feel that working on something like a Block manager is not sexy, attention-getting work, but I feel that Blocks are one of tools that allow the creation of things with multiple parts.
That’s great to hear Steve! I also hope this could be also the building blocks (nice pun!) for a better exchange of files with MCAD packages like Solidworks, Creo, Etc.
The Spaceclaim stop-over to convert layer <> components works, but sometimes it’s glitchy in its own way. This weird we had a weird issue that over right same file it was caching old stuff, not fun. This is why I prefer to leave more of this stuff to Rhino if possible.
The youtrack item should contain a link to a discourse post or, when the user sent an eMail, to a SupportBee ticket. This is used to notify the user when the issue is solved.
Apart from that, the youtrack item should contain enough information to describe the issue at hand. When that is not the case, it would be helpful if that is pointed out.
I could probably spend an hour or two trying to find your previous feedback on this specifically but perhaps you could quickly remind us what the issue is with STEP files from Rhino to Solidworks?
This of course has no further logic of repeated or instanced parts, etc. inside is components (what used to be a layer) is a part in Solidworks (what used to be a Rhino object).
Here’s a couple of threads about the problem more into detail…
In this one @brian captured the work to be done, but he’s only talking about importing, not importing AND exporting:
That topic above was a split topic from this other one:
I also had conversations about this with @chuck a few years ago, where I described the problem to solved in this way: the collaboration roundtripping problem:
I should be able to receive a STEP/Parasolid assembly from a colleague/client/supplier using Solidworks. Open it in Rhino, edit some parts, and export it again, and send it back. The person who gets it back should see the exact same assembly structure as what they sent originally, bit now with my new geometric changes). Thats’ how we operate today, but it requires owning and managing all this extra $$$ software.
The process about should be able to repeat back and forth between Rhino <>Solidworks multiple times and the assembly structure must stay the same.