The dynamic blocks (“symbols” , “scrapbook” in sketchup’s layout) used on drawings — are 2D blocks that have additional parameters you can set and change - for example I want to draw a “section symbol” on my drawing, So i grab the symbol draw it over the “VIEW” and the software will then automatically populate the section view FOR ME. Now, I can then go back to that symbol and change the direction of the section, if I wanted to, for example. this works the same way with other symbols like a “detail” symbol where I can click and drag out a circle/rectangle (your choice) over the area I basically want to ZOOM to and create a separate detail VIEW for this. ETC. In autocad you have the advanced ability to create your own symbols and apply your own parameters, which is better than something like inventor, but inventor is way better overall to autocad. Anyway just my two cents, I’ve requested this before…
At first, I thought this required that rhino would need to automatically generate the ortho views like these other softwares do (inventor, solidworks, $$ etc) even though they struggle to update, cause all sorts of random artifacts, etc… but then when I looked at sketchup’s layout scrapbook tool - I thought, OH rhino could totally have something like that but even better because that’s obvious.
Dynamic blocks can easily be replicated with Grasshopper.
If you need a parametric object with parameters that can be changed, that is basically what Grasshopper stands for.
So you can have one grasshopper definition for each dynamic object you create.
Of course the only thing missing would be to have this object/s be one same block at different states, which is no possible inside Rhino as you can’t have two different representations of the same block. But you can still apply general transformations to the whole as rotations, scale and mirror.
But again I don’t see the advantage of that, why would you want Block 01A be the same as Block 01B if they are different? Easier to assign material? Easier to assign line weight? Well you can do that with layers and easily define to which layers the objects get baked to from Grasshopper.
Honestly as an architect who also drafts I never needed this functionality and it would not make my drafting anymore efficient.
I have a block and if I need a slight variation from it I just explode it and do custom changes to it.
If I need 3 different doors I just create 3 different blocks and use those across the drawing. No advantage to having them all be the same block.
So every time you change a number in a section flag block you explode the block and make a new block with a different number? You have separate blocks for every size door and window? Dynamic blocks are critical to architectural drafting workflow, not sure how you get by without them.
If I need to change numbers I just have them separately, no blocks involved what so ever.
I could also just create a Grasshopper definition and just change the number input and bake.
No, I don’t. What would be the advantage of having that object be a block…?
That’s a very good argument. Same as me saying unicorns exist and not sure how you don’t believe in them. Bravo.
Yea, technically I do not need the blocks when I do my drawings. I can just manually put everything in, do a ton of extra work (that, if automated - would create an extremely efficient workflow.). Grasshopper is cool and all but I don’t know grasshopper and why should I if we are talking about drafting standards? I know there is some automated functionality with the text fx where I can do a ton of work to link things and set up my paper but it becomes very tedious and clicky. It can be difficult to keep up with all the (fx) when you start to create over 10 sheets and then all the sudden change the order or format of pages, delete/add and carry into other projects. I basically gave up on trying and now I just create from scratch everytime and I’m always starting over, need to find certain files with certain “custom” symbols I created so I can copy paste into a new file — When you have multiple clients, who have different styles and and needs - - your own stuff doesn’t always come into play… It’s not the end of the world, but it would be really nice to have a dynamic block which is essentially a fancy looking leader type that could populate and link and keep me on my toes — when you do things manually - especially texts over several pages, you’re wide open to mistakes. That’s what it comes down for me, personally…
I just want to share my experience and state that dynamic blocks are incredibly useful. There are other ways to achieve similar results, but for how easy they are to created and ease of use… it’s pretty much the best system out there. Any 2D work I do is far quicker in AutoCAD with my blocks, my AutoLISP and a good set of standards than it is with any other program. 3D… well… I’m here aren’t I?
The thing is though… We can almost do all of that in Rhino, and it’s far cheaper. AutoCAD is a rip-off at thousands of dollars per year. And zero development (the latest version may have even gone backwards :-S).
FYI: I know of two CAD Clones have dynamic block functionality. One being GstarCAD which I used for about a year (it had some problems but has improved in it’s latest release) and Draftsight, which I haven’t ever used due to it’s relatively high cost (for a clone). A third one is Corel CAD, which I’ve never used and seems to hover under the radar and doesn’t have much of a presence in the market.
This fills me with hope! I can’t stress enough how important this is for our workflow. It’s *the* feature keeping our office from ditching AutoCAD entirely in favor of Rhino for 2d work.
I agree with pretty much everything @Eugen has said here. I’ll give Constraints a try, but Grasshopper-powered blocks should be a part of the standard Rhino package. It’s already been done!!
What you mean is working with blocks inside grasshopper.
The point was the opposite: having grasshopper inside blocks, in the 3d scene. No hovering GH window. Just black box blocks with their input parameters exposed in the properties panel.
Exactly what VisualArq provides. Should be a standard fearure.
I think visualarq use grasshopper cluster in the backround and expose the in and outputs to a parameter input field for the user…or do they use blocks?.
‘Blocks on steroids’ as they like to say.
Their building parts can hold as many ‘styles’ as needed, and even be redefined with a GH script. Called ‘Grasshopper style’.
Manners, dude!
Nobody is taking away anything. If you like working with GH the usual way, just do so.
This is about GH driven parametric blocks, which for a certain clientele make perfect sense. If you are not among them, why care?
And stop knowing better than McNeel how to invest their dev resources.
So I was trying to help by mentioning an alternative workflow that enables one to manipulate blocks parametrically by mentioning a plug-in which not many are familiar with. Nothing to do with what I like or not.
You, on the other hand, completely disregard my intention to help as having completely missed the point… (which was incredibly rude).
While at the same time demanding as a standard feature something that already has possible workarounds.
And still somehow lecture me about manners?
Rude. And same can be applied to you? In any case one does not need to work at McNeel to know that implementing something because some users don’t like hovering windows is hardly a good use of resources.
As a sidenote: Wasn’t my call. But confessedly, ArchiCAD is soo far ahead regarding documentation features to the Rhino/VA combo.
For the rest - this straightforward, tight and logical general workflow - I prefer Rhino/VA.
Regarding modelling, ArC does not have Nurbs, btw., Only polymesh… Yeah.
A tandem with Rhino it will be.
And ArC does not have blocks(!). One needs to use library parts or hotlinks (kind of like worksessions).
Since v24 there’s a feature called Param-o, which are lib.parts driven by their own new visual scripting language, like ‘poor man’s’ grasshopper.
So, this VisualArq GH styles fearure = GH driven blocks, is just adding 1 + 1.
But it’s on the heap already, so no need to say no more.
Thanks!
