Pushpull for non planar geometry…
1 Like
People have mentioned this for a long time, but I want to bring this up again. From the architecture design point of view, the one limitation of Rhino vs AutoCAD and even Sketchup is the Block Management and controls.
-Non Uniform scaled Blocks can’t be edited without resetting them
-No Dynamic Blocks. See Autocad and Sketchup. We can easily set something up with GH and control them in Rhino. VisualARQ has something like this.
-DoubleClick to enter nested blocks instead of searching for them on a list
2 Likes
new block plugin on food4rhino
ies support would be much needed indeed!
2 Likes
Looks interesting i can find use for this in future videos
1 Like
Hi -
I’ve always wondered how that is supposed to work…
… so I installed the BlockEditNew plug-in.
I scaled-1D’d a block and double-clicked it to edit it. When I then saved it, it made bad objects of all instances of that block in the document. Is that something that users are fine with to be able to do that, or did I just do this completely wrong?
-wim
When I used Sketchup (way back when) I would use blocks almost like a parametric model. For example: doors and windows could be 1D scaled to fit my needs. Minor distortion doesn’t really matter for the end product, but having to change details on many objects does matter. (You can even 1D scale strategically such that nothing is out of scale in the end). Trees/ rocks all benefit from 1D scaling. In Sketchup when you click to edit 1D blocks they stay scaled inside the block.
Also I was never able to install NewBlockEdit when I tried a year ago so I gave up.
I’m afraid that sounds like a major tech support issue if there were the case in Rhino…
-wim
Feature Request: Introducing “Classes” in Rhino – An Additional Layer of Organization
I’d like to propose a new feature for Rhino 9: the addition of Classes as a second, parallel system to Layers. This would allow users to assign objects not only to Layers (as currently possible), but also to Classes, which could control attributes such as line thickness, color, and visibility. This structure would enhance flexibility and clarity in complex models by separating spatial organization from typological or functional grouping.
In many professional workflows, a single-layer hierarchy is not sufficient to manage large, multi-scale projects. A Classesfeature would offer a second method to organize and control objects independently from Layers. Each object could belong to both a Layer and a Class, with the Class determining attributes (line type, color, print style) and visibility. This separation would enable:
- Centralized control of object appearance: Change the line weight of all objects in a class (e.g. “Concrete hatches”) globally, regardless of their layer.
- Simplified visibility management: Hide or show entire categories across a model (e.g. “Furniture” or “Annotations”) with a single toggle, without relying on duplicated layer structures.
- Cleaner organization for large or multi-floor projects: Layers could reflect spatial divisions (e.g. floor levels), while Classes group elements by function or material.
- Improved 2D output: Especially useful for drawing sets, layout control, and export, where consistent styling matters.
This idea has been discussed and supported multiple times by the Rhino user community:
- “Classes for layers” – A September 2024 thread requesting exactly this two-level system and describing a manual workaround with user-text.
- “LayerClasses – Assign Rhino objects to a specific class” – Announcement of a plug-in (2016) that tries to fill the gap by letting objects belong to a user-defined class, underscoring the long-standing need.
- Forum post: “Architecture – Layer Management Workflow?” – A 2021 discussion where architects explain the pain of duplicating layers per floor and ask for a way to place objects in multiple organisational buckets.
These discussions show a consistent desire for more flexible organization tools and attribute management, particularly for those working on layered, detailed projects.
The introduction of Classes would give Rhino users a powerful new tool to manage complexity, enhance clarity, and improve drawing output. It addresses long-standing limitations in the current layer system and reflects a feature that many users have been requesting for years. I hope this can be considered as a meaningful improvement in Rhino 9.
Edit (thinking out loud): I might be off base here, but Rhino already keeps things like layers, linetypes, and materials in separate tables, so—at least in theory—adding a little “Class table” with a corresponding classIndex field might not be far-fetched. The interface could then pick up a modest Classes panel and a “By Class” option next to “By Layer,” and the display/printing pipeline would just need one extra check for class-level settings. Older Rhino versions would probably just ignore the new table, so files should still open fine. Of course, I’m sure there’s a lot of plumbing and edge-case testing involved, and I might be oversimplifying things—but it feels more like extending an existing pattern than reinventing the wheel. If it’s doable, though, it could really raise Rhino’s organizational game.
6 Likes
Feature Request : Flip option on matchsrf command when multiple option is set.
Hi. I would love to be able to flip the surface direction of a matched surface used with curve on surface.
I’m working a lot with history and the match surface is wonderful to get nice blend surfaces that can be editable. But with isocurves if one side is in continuity, the other must be flipped, and flip option is off in multiple match.
Best.
2 Likes
Hi,
My wish list for Santa Rhino 9.
- Local coordinate systems tied to layers or individual objects so that we can export them or importe FBX, etc correctly
- RH-97707 Bug Fixing
- All other bugs fixed (reported by me, for example)
- If there is time, Cycles FOG support.
you can do this with the User Data features that already exist
1 Like
wait what.. no.. how? how can you do classes that are viewed like a layer list? can you explain?
here’s a plug in that does something like what you’re saying, with what they call tags
you could make your scripts that do what ever you need with the tags. select all objects with the tag “handrail” and hide them, for example
https://www.food4rhino.com/en/app/smarttags-rhino
i do wish rhino had a more comprehensive object outliner but i think the functionality to classify objects is there. you just can’t see the full list of objects and their key/values all in one interface.
Amen to that. There are several separate posts around the missing Object Manager: Rhino 9 - Object Manager
Here is the official item from McNeel: https://mcneel.myjetbrains.com/youtrack/issue/RH-54814 won’t happen till at least Rhino 10 though..
1 Like
I came here searching for a place to make this exact request. I NEVER use scale factor and find click drag and type an awkward motion to use. This would be a feature that I would use a lot and significantly speed up my design process…
So the Object Manager is not the same feature—though it is definitely related. Thanks for starting that thread. I support it. What I am asking for with Classes/Tags is simpler: a native second categorization layer alongside Layers that drives attributes (line weight, color, linetype and print style) and visibility (“By Class”), without relying on plug-ins. (In some tools this maps to “classes” — Vectorworks — and “pen sets” — Archicad.) SmartTags is clever, but in real projects it complicates handoff (partners without the plug-in, version drift, scripts to maintain). A built-in option keeps files portable and predictable.
Why Classes/Tags as well as Layers? In renovation work we follow conventions for what elements are (load-bearing vs non-load-bearing, furniture, MEP, etc.), while Layers usually sort by where/when/why (existing, demolition, new; floors, zones, plan types). On a typical single-family renovation I end up with about 250 layers because I duplicate layer trees just to get different line weights/colors for the same element types across phases and drawings—creating significant redundancy and turning the drawing process into a sorting exercise. Classes/Tags would describe the technical type of an element, while Layers continue to handle purpose/time/organization—dramatically reducing layer bloat and making visibility and styling consistent across the whole model.
So: +1 to a stronger Object Manager for hierarchy and selection—and in parallel a simple, native Classes/Tags system for global attribute control and filtering. They address different pain points, and together they would make complex AEC/renovation workflows much cleaner.
4 Likes
I see, thanks for clarifying. That totally makes sense and having the functionality you describe natively sounds very sensible.
In the end the scenario you describe is solvable by having “another dimension” of organising your data, ie. the objects in the scene. Layers are one dimension, but like you said, because Layers are exclusive, meaning each object can only be on one layer, we might need another way to organise things.
The envisioned object manager for example offers another dimension through grouping, of which blocks are sort of special group that can be instanced.
But in the end it serves the same purpose - another way or organising our data. Tags/Classes would be another way.
In the end its about organising our scene, which can often become very complex. The more ways we have to do that, the better!
1 Like
- Clipping cuboid: Clipping box in 3D view - #9 by kazet
- Equivalent of xclip: Is there any xclip command for linked files? - #3 by kazet
Both of those applicable to individual worksessions and blocks