Hi,
it would be useful to have a type of block or an object that would contain referenced geometry in Rhino. So, instead of containing the object geometry, it would contain instances of the referenced geometries. In other words, the block would act similarly to a regular block, BUT the original geometry would not be contained inside a block object itself, but instead would be freely editable and selectable.
I would find such an object useful in cases where I need to define piece asseblies for fabrication and drawing production. If I have geometry in 3D space, I can work on it, model details, define names, add drill holes, etc. Then, when I have to create assembly drawings or piece drawings, I need to orient the pieces to XY-plane, for layouting and dimensioning. If the pieces change, then this needs to be redone.
If such pieces would be referenced inside a block assembly, I could work and rework them, while keeping the layouted geometry up-to-date. And it would not have any impact on the original objects or the ease of their editability. (I know this is all doable inside Gh - that’s how I do it now, but there would be big benefits if this could work directly inside Rhino)
The block would update as pieces are edited, info added, or their locations changed in relation to a block’s base plane.
A little bit similar functionality as the dynamic section in VisualARQ - but instead of a projected line drawings, we would have actual 3D-objects…
Perhaps you should look into creating custom CPlanes for those non-standard orientations and then use these CPlanes when detailing the parts on layouts.
-wim
Hi,
no, because I’m talking about a functionality that does not yet exist in Rhino. The functionality could be wrapped inside a block-type object, but certainly is not what the block is now.
Closest that I can think of current system would be if I could define a block from a file, but not using the entire file, but only certain objects from that file. So the content of the file is wholly editable, yet parts if it updates to a different instance.
Hi, this was not a definition of a problem, more of a use case example that came to mind. When dealing with hundreds of pages for layouts, the XY orientation is easier to maintain.
But it would have other benefits as well. You could take out portions of architectural models and assemblies and layout them on different sheets, without having to copy and update the geometry manually. Or to maintain complex layer state sets. For example one could separate an instance of a bathroom for 3d axonometric view. Make2d is good and all, but VisualARQ dynamic section makes it updatable. Block is good and all, but a bit of an hassle when you want to edit the geometry inside. But what if you could define a “referenced block”, where you would define a block normally, but with the difference that the geometry you select would not be wrapped inside the block, but remain free and editable.
But how would you know what is being referenced if you don’t have it in any container? Do you know that double clicking a block will let you edit the contents of that block?
Hi,
I have been a Rhino user for more than 10 years, and I know what blocks are and how they work. I am trying to imagine a new functionality.
You could have the fact that an object is being instanced shown in different ways, I imagine. For example with grouped objects, the word “grouped” appears after the object type.
Well, I think that improving block functionality in Rhino would solve all problems you are talking about. In the end, we are talking about referencing parts of a drawing/file.
It’s been more than 10 years since last time I used 3ds max, but after reading the help, I remembered that functionality. I don’t think that’s perfect either, if I’m right, in order to know if an object is a copy or an instance, you have to check in the outliner how the name of the object is represented. If the object name is written with normal characters then the object is a normal copy, but if it’s written in italics then is an instance. Relying on this kind of visual language is not a good solution,as I think there is a chance that you modify something without realising that there are similar components affected by that operation. As I said, what is the different between a group or a block if both are going to be referenced, just the name as I see it.
To me, everything that is going to be referenced should be inside a special container, that way it’s clear that what we are modifying is linked to something else.
Actually, there is a way of doing that in Rhino. If you want to have a reference of a copy, activate History before copying the object. Now if you modify the original the copy, it will be updated too. This works with groups too. Still I prefer using blocks for this things.
In my original post, I’m outlining an idea that you could copy a collection of objects in a way that they are connected to the original. But not with a two-directional link.
The original would be there, unharmed, unbound, unrestricted etc. and the copy would be wrapped in a block-type of a container. If you would modify the copy, you would have to open the block-container, which would then take you to edit the original objects.
Somelike similar to when creating a block from file - the content of the file does not know it’s being referenced inside of a block in another file.
If you want to have a reference of a copy, activate History before copying the object. Now if you modify the original the copy, it will be updated too. This works with groups too. Still I prefer using blocks for this things.
History is not an adequate solution, you cannot add objects to it like with blocks, plus I think the main side is that it always breaks so easily - that is why I too prefer working with blocks.
Well, I think that improving block functionality in Rhino would solve all problems you are talking about. In the end, we are talking about referencing parts of a drawing/file.
Exactly - but in a way that the spacial relationships between a collection of objects is maintained. Just like they are in a block.
Agreed, it breaks to easily and your video shows its limitation clearly, that’s way I never use this feature. I really hope that blocks in V7 will receive a proper overhaul.
I made a very quick bubblegum sketch of the implementation, utilizing VisualARQ’s Furniture object. Update here happens through Gh, but the link is just based on GUIDs.
VisualARQ does not yet support outputting data, so I could retrieve Key/Values through it, for instance.
The just released version of VARQ supports planes instead of points as inputs, but could not get it working for this very fast implementation.
This is not a solution, but a hack. It would be nice to have something similar in vanilla Rhino.
Even for a quick test, it works surprisingly well. Selection is by name or by layer (Key-Value could also be added). VARQ objects are exploded to breps.
I will have to think how to utilise this on next projects. There’s a lot of possibilities - I could incorporate Make2D to this also, to get more final fabrication drawings out… All updatable based on Rhino geometry changes.
