You can solve these block problems with SetUserText, SelValue, and SelKeyValue commands. For example, each part, including blocks, may have several keys: fabrication, material, part_number, etc. The fabrication key may have one of several values, for example: made_in_china, made_by_our_machinist, etc. If you use one key only, you find the objects with the SelValue command. If you use many keys, you find the objects with the SelKeyValue command. (You cannot use spaces in the key names and their values.)
You can also use free Rhino plugin called SmartTags. The SmartTags plugin creates four new commands: Tag, TagFilter, TagManager, and TagsFromLayers. Its main advantage is that it can use Boolean operations to select the objects. (Rhino cannot do it.) You can download SmartTags plugin from here: http://www.food4rhino.com/app/smarttags-rhino
Maybe that solves one problem although with some extra work, but I hope you realize that both threads I linked contain literally dozens of major issues going back several years?
According to @Pascal people are 15-20 year late complaining about it, but that also means that there has been no development in that area in Rhino for 20 years… which kinda explains the price tag on Rhino…
But hey, I’ve said it twice before, why not a third time:
I’d literally pay double the price of Rhino for robust filleting with history and deletion, and if I could choose only a single feature for Rhino 8, it would actually still be that, despite the atrocious block situation.
(In Industrial Design, Rhino is currently only good for the first 25% of the project. You have to switch to a competent modern CAD package when you approach tooling, unless you’re a glutton for punishment… and yes, that also includes drafting, which has been mentioned in this thread already and also here.)
What’s this new percentage nonsense way to calculate value of a piece of software?
In a typical product development project (a complex one) the total industrial design time is about 5% of the time/effort. Make that 0.1-1% if it’s a very te by thing. So should we just stop using good software me side of that.
Should we all just use SolidBarelyWorks for a 100% of the time of that 0.1 to 5% of the effort? Or should we use tools that allow you to create the design intent and differentiation that will help your brand/client/employer make products that are differentiated from all the me too crap out there?
All I’m saying is that I’d like to be able to use Rhino more in the development process. Right now, I can’t. I have to switch quite early to something else, and Rhino 7 did nothing to change that.
Unless I misunderstood you, it sounds as if you’re happy to use Rhino for just a small part of the job. And if that’s the goal of Rhino, then fine, I guess. But I thought Rhino was supposed to be a complete solution for some… and right now, attempting such a thing is a pain.
I think you bring excellent points, and I agree with your desire to make it more useful.
I’m just realistic that such massive improvement would take a development team probably 3-5X of what McNeel has now, and will only be useful for people doing Industrial design type of work. Even though I would welcome that (that’s what we do), I think Rhino could go out of business pleasing us. It’s a lousy/demanding(no pun intended by me saying this)/small market to be in.
It makes more sense to play extremely well with MCAD packages first. For example, I cannot open a Step/Parasolid Assembly change a hard to model thing in Rhino and export it back out maintaining its structure/assemblies/naming/colors intact. I want that waaaaay before I want them to build a draft-angles/fillets/shelling/Boolean Division for Chuck to have an army of typists.
Blocks are overdue and they would help everyone. Including McNeel because we could all work with much smaller files if those things were half useful.
Also working really well with world class rendering plugins like Octane and Vray should be a much higher priority than any pet projects in rendering. Same goes for a seamless integration/livelink with Blender/Zbrush/Unreal/etc.
My thinking: Let’s pick battles where we can all win.
I’m happy to pass on shelled parts of money-making designs to Fusion, Solidworks, our clients’ engineering teams or some offshore supplier.
-more robust booleans and overall reliability of operations
at the moment i am always tensed when i run the command if it is gonna fail again or not, get rid of all possible far from origin problems (6 still had some, probably 7 too) -blocks
complete new way of handling them, have nesting in mind, instancing, uniqueness, hierarchies, assemblies, implement natively in gh, just inspire from other programs, there is a chance to do it all over again and in unparalled way -constraints
constraints would open many many doors to new possibilities (parametric blocks…) -drafting and annotations
ordinate dimensions styles, multileaders …many many more… just look at autocad and implement the features even better. rhino 7 just brought literally nothing new in this department -dynamic, live views, section views, sections
no make 2d, select objects or depth of view, driving curve (would cover sectionviews along curve as well as basic sections and views) and direction of projection, rules (according to attributes) for which objets have what type of fills, hatches, special rules if section part is in contact with nothing make line thicker… -enhanced BIM functionality
employ attributes heavily in any job, there are plenty ways how to enhance the functionality and use attributes for whatever organization of the model i have complete picture how it should be but thats not for this overall suggestions thread, advanced reports from the model -clipping of external references
been mentioned in more than one thread. it should have been in 6 already -clipping objects
not just planes, advanced functionality in this department -snaps to intersections and objects
curve curve srf srf crv srf -blending with euler spiral
there is no way right now to create really smooth transition between curves, euler spiral connects two curves with matching curvature gradually -silly stuff
you cant batch plot layouts to pdf in version 7. there are probably more silly things like this which makes look rhino like baby weak rhino.
+UI improvements (dark mode within native new modes maybe)
i think it would be nice if new version would come with cleaned tracked issues from previous version. if that is even possible
Whilst it’s not an official GoZ Solution - I have made a grasshopper plugin to optimize the workflow between Rhino & Zbrush: https://www.food4rhino.com/app/chameleon
I would LOVE to see a native Rhino incremental array (on crv, between crvs, on srf, on crv on srf, etc) that doesn’t require Grasshopper or another plugin.
If clipping can be done by objects, can we then have, as a side effect, some boolean subtraction history? I mean, if we can have objects (clipping objects) that are invisible but that can cut volumes from other objects, can we also have those objects work as part of boolean operations? That way, we don’t have to ‘cut’ out areas of objects but instead can maybe define an object as a ‘negative’ object, and anything it intersects could be cut away.
I’m not explaining this well, but basically I’m talking about Rhino having ‘negative’ objects, like IronCAD has (see this video) - that way, the subtractive object is always around and I can modify it with history to change the shape of the ‘hole’ that I’ve created without untrimming or any of that hoopla.
My list: Matching Subds to nurbs surfaces Subd Crease fade / variable crease Subd radial symmetry Solids as negative shapes (like this) Better tools for solving complex patches/intersections
Some little things:
FitCrv: an option to preserve tangency at ends
MatchCrv: an option to flip crv to match (like in blendcrv)
ExtrendCrv: an option to just leave extension without the original curve
Dimensions - an option in the dimensions properties dialog to use those settings as default
Oh, and I’d like this script to become an official tool: Pascal’s Project Objects script. Only changes I’d make would be to get rid of point limits (but make sure escape works) and to implement history.
Real world scenario: We are doing a perforated sheet facade, with non-uniform perforation patterning.
To boolean and maintain surfaces + render meshes of hundreds of sheets, with each hundreds of perforations - is unthinkable. Low resource clipping or ‘void’ objects that would just visually occlude a small part of the geometry would be really useful.
And as a side note: VisualARQ objects have these ‘booleans with history’ already, and they work great. Computationally heavy, but with a small set of booleans, they work nicely.
