You got it, Brady.
Just to clarify for other readers of this thread, dynamic blocks are also very helpful with modeling, not just drafting or 2D symbols.
You can have one kitchen sink block that has internal representation for many different models/materials of that size sink.
You can have one OH door that has styles for Windows or no Windows.
You can have one style fastener that has multiple lengths in one block.
I will not elaborate any more. There are many more really good examples of 3D uses for a dynamic block feature in Rhino. But #1, when you import or open a DWG from AutoCAD that uses dynamic blocks, it won’t open and look like this.
I was (well still am) able to drastically increase my productivity with dynamic blocks, using mostly the “action” parameters. It’s a really really good system. So many people overlook it, or create lousy blocks that don’t work quite right. I’ve used the “constrain” parameters as well with some success, but the “dynamic” parameters are what really drivers productivity for me.
I actually learned to create Revit families prior to learning how to make AutoCAD dynamic blocks. In fact it wasn’t until I got good at Revit that I realized “I can do this 10 times faster in AutoCAD”.
I multiply my productivity gains by combining dynamic blocks with AutoLISP.
So far, no CAD program I’ve used has been able to take an “AutoCAD” style block (with actions) and port it to 3D. Some have copied AutoCAD’d 2D dynamic blocks. One CAD program claims to have better blocks and in 3D… I have a bit of beef with that particular program’s community because they outright lied or had no clue what they were talking about (they were likely either resellers or add-on developers, or both) and it led to a lot of lost time and money for myself… that program’s “parametric” blocks, as they coined them, absolutely sucked. Revit Families tend to be a little clunky. Once you get them right they work well (sometimes that is, and within the confines of what the program can do that is) but they are very time intensive to create… correctly, hence why so many broken Revit families exist.
I’m JUST getting into Grasshopper. I avoided it mainly because I had to deal with some Dynamo disasters back in the day and shunned the visual programming altogether. It also didn’t help that 100% of the GH definitions I tried didn’t work up until recently. I’ve finally started to learn it and it’s actually quite good. It might come reasonably close to matching ACAD’s dynamic block ease of use and versatility in 3D… but it comes with a far steeper learning curve. And is a little slower to implement (but you do get 3D capability in return).
Anyone who hasn’t mastered ACAD’s dynamic block system is unaware of the outright production speed available.
I’ve been following dynamic blocks for a long time and it has somewhat different definitions for different people. But as for mine, I’m talking about “trimmable” dynamic blocks as in Autocad. I’ve asked this question before but have not quite gotten an answer - Is it possible to apply a trimming effect for 3d Blocks? I know Blocks can’t be fundamentally trimmed unless we go into the block and trim the geometry itself, and that is a feature in rhino but can’t there be a way to hide a portion of the block somewhat like a controlled Section? Coz if Autocad can trim/hide portions of it’s 2d blocks, why can’t it not be applied to 3d? This is an important question because in fabrication, a lot of unique components are just cut-up pieces of a modular one, so with regards to 3d modelling one could save a lot of computer memory by creating a lot of unique parts from a source block that is “trimmed”. By the way, I put air quotes on the word trimmed because it’s not really a trim command as we know it, but rather something different.
Ok, but this is practically impossible in the building industry. 2D representations all over the place. Plans, drawings, communication graphics… Even in times taking tablets to the site, AR, etc.
But is it maintained as a Block though? What I mean is, are the blocks exploded and cut; or create a new block with the trimmed geometry; or no extra memory is used whatsoever? What I’m requesting for is if we can trim/clip/boolean blocks without losing its block property. Something like a “Hiding Volume” that doesn’t really delete anything - A visual trick, if you will. I’m very curious if it does what I’m technically looking for. It does seem that way in the video, but I have to know if the process did that or if it spawned a new block altogether.
Hello! Yes, it remains a full parametric block. No exploding necessary.
If you want to change the subtractor, you can extract it again, work on it, then do the boolean again.
Very interesting. I’m sorry for my interrogating you but I’m just very curious. Does this work with multiple block panels? Like in a building faced situation where i have lots of panels that i have to cut. Or a flooring tile which has to have edge tiles that are cut because of an irregularly shaped surface? I’m downloading Visualarq trial now so I can test.
I do realise that dynamic blocks do have some advantages but from a managing perspective they’re not ideal as it creates anonymous blocks whenever you modify the original dynamic block and you may end up with a lot of those, unless Autodesk made changes in that area in 2023.
With proper parametic 2D/3D blocks as BricsCAD is doing this shouldn’t need to happen
BricsCAD can open and edit dynamic blocks from AutoCAD but doesn’t create them. Instead they have parametric 2D and 3D blocks using proper parametrics and keeping it as a named block when changing/overriding the base settings and in my opinion that is how Rhino should do it as well. This in addition to being able to read and modify dynamic blocks for compatibility with AutoCAD which is still useful to have.
One important thing to consider when working with these VA booleans: the first object (the one which gets subtracted from) needs to be a VA object. However, you can convert any solid to a vaWall.
When you run that command, you need to pick a curve - the wall axis, which in this case can be just any.
The subtractor can be any solid, then.
Subtractor cannot be a block, though (just tested). That means, if you want to use a subtractor object multiple times, you need to make copies (you could history enable the copies).
Tested the live boolean feature again with a parametric, Grasshopper-driven box. It works.
When I change a parameter of the box (which lives inside a vaElement), the resulting boolean updates automatically.
I tried Visualarq, and did all sorts of experiments including creating blocks as furniture and elements. I even tried what you suggested with wall and used the Subtract from Solid but unfortunately it’s still not functionally a Block because it treats it as only as regular geometry. Every time I saved the file, it’s size becomes bigger and bigger. I also tried exploding the Wall element and found that it’s the same as a regular box only without the VA attributes, also it has the same file size addition. So in conclusion, fundamentally it’s not a Block and doesn’t do what I hoped. Hopefully someday @mary and others can implement a graphical trick that visually omits but not deletes portions of 3d blocks without breaking it or incurring significant memory usage.
VisualArq blocks are as ‘blocky’ as it gets. Of course, if you convert some brep into a vaWall, it remains a brep inside. What would you like it to do?
Did you try to create dynamic blocks with Grasshopper inside?
Aren’t you compounding clipping xrefs and dynamic blocks?
As for clipping, in Rhino 8, you can use clipping planes to selectively clip certain geometry.
-wim
Thanks for confirming clipping planes are a (possible) solution, I had (wrongly) assumed that the poster had already tried that and it wasn’t working for some reason.
a really powerful implementation can be found in vectorworks with (vectorworks-) plug-ins or with marionette.
the basic concept is kind of a block that can be defined by parameters and referenced objects.
for example a wall element is based on a line with some parameters for bricks / bricks size.
and a pascal-like scripting language - or alternative - a visual programming interface “marionette” - like Grasshopper - can be used to define the relation between input (geometry and parameters) and output (mainly geometry)
what is really powerful: those parametric blocks can be nested.
you can define a brick - based on parameters - and define a wall using those bricks based on an additional set of parameters.
i always miss this kind of functionality.
Visualarq brings something similar too, “grasshopper style objects” see here
looking forward to see those new features in rhino.
Not necessarily because in the past discussions in different threads a lot of users viewed “dynamic block” as a morphable block that is adaptable to a particular shape. I know that it’s impossible to morph, bend etc. a block without breaking it. But maybe a solution would be to use some clipping to make that block into a desired shape. As a sample problem, let’s say I have to cover an irregular flat surface ,whose edges are curved, with modular Block panels. With a “Block trimmer”, one can simply distribute block panels throughout the shape and then cut all the panels along the edges to conform to the shape boundary. This requires a block that is able to be trimmed and maintain instancing. Hence, dynamic block.
Unfortunately that is not what Autodesk/AutoCAD means with dynamic block.
In general it is either modifyable by changing dimensional parameters or it contains preconfigured instances of a block (e.g. a closed door, half opened door and fully opened door or different door sizes you can select) which can be selected/updated as needed for each instance of that dynamic block.
The “morphable” part that people are talking about are actually the various preconfigured instances that are included in the dynamic block.
The downside of AutoCAD’s implementation is that each instance becomes an anonymous block with the disadvantages that come with anonymous blocks.
As enticing the idea of trimmable blocks sounds, one question that comes up is if it can be undone later (or unintentionally by someone who doesn’t expect/recognize that kind of trimmed block), and how will this be exported to a 3rd party that does not directly support it (e.g. dwg based software). If it would then become destructive (i.e. decompose and permantently trim the object) this will affect roundtripping.
Sometimes the quick and easy solution can become a burden because if it isn’t implement well, so the big question for me would be how it should be implemented to keep it usable/manageable in the long(er) run also with regard to exchane with other software as Rhino is not always the only CAD software used in a project.
Thanks for the reply.I completely understand your point. Just to reiterate, I’m putting in this discussion the idea of requesting Mcneel, if they can, to improve the block system in Rhino such that “Boolean/Trimming” operations can be applied to a block in a non destructive manner. I’ve read through almost all of the topics regarding blocks in this forum and I’m well aware that “Dynamic Blocks” mean different things for different people.
I’m specifically pointing to a “Dynamic Block” that is very flexible in nature. The dynamic block you’re talking about is relatively simpler in concept than what I’m asking for, because yours only require Constraints and proper nesting of blocks, like in Revit. What you’re describing is the system that’s already in place in Revit. What I’m asking for is maybe some modification of the fundamental block system itself , and a clipping command, because as we all know blocks can already be clipped, that can modify the shape of a block without destroying it and without incurring memory costs.
So again, I’m using the word “dynamic” this way because it literally becomes dynamic(follow a shape, cut holes, reduce length & width) with what I described. It stills falls within the definition of dynamic.
In other words, ‘live’, or history-enabled booleans. If it existed, it should work for blocks AND normal breps.
A thought: wouldn’t this in fact be some sort of solid modelling feature then?
As mentioned, VisualArq offers a boolean feature that comes close to ‘live booleans’. Problem is, not everyone has VA, and the workflow is somewhat… strange, since the first object needs to be converted into a vaWall.
Features like this should be native to Rhino. Actually, there are numerous VA features that would be useful for many users, not only architects. There seems to be little communication between Asuni and McNeel regarding this. Correct me if I’m wrong. It’s not ideal that features are developed double (like section styles).
With Grasshopper it should be possible to create scripts that read multiple objects for boolean operations. However, it should bring native block support, as well as a wrapper object for GH in the Rhino scene (like the vaElement).
Clipping planes
They don’t work on a per-object basis. As of now, they clip everything, including blocks.
In R8 WIP it is possible to turn clipping off per-object, by these new object parameters,
but you cannot tell a ClippingPlane to be related to only to specific object/block.
Section styles are a new R8 feature, but they don’t work with objects inside blocks (yet).
Does this work with multiple block panels? Like in a building faced situation where i have lots of panels that i have to cut. Or a flooring tile which has to have edge tiles that are cut because of an irregularly shaped surface? I’m downloading Visualarq trial now so I can test.
