Change plane of block definition but keeping position of instances

Hello, what would be your strategy to change planes of block definitions but keep position of the instances?

I am using elefront plugin to modify blocks but i cant think of any clean way how to do it. I came up only with idea to internalize current planes of block instances, then modify the definition and in last step to reorient instances between original and new planes.

Is not there a better way?

hi @ivan.galik I am not quite sure what you are trying to do or what the desired outcome is. Perhaps you can post a diagram or a example model of what you want to do. Happy to help, but just need to know a little more.


this is bunch of blocks

i realized that my block definitions planes are not aligned to planar rebars inside so that x is the longest direction i decided i need to redefine them. that part i have achieved.

problem is that all the instances are therefore affected in transformation and i need to keep them put.

this happens after i redefine block definition planes…

Hi @ivan.galik

Ok, I think I understand a bit better now. I am assuming for now that the block is embedded in the active document and that you want changes to the block to be reflected in the model. If this is not the case, let me know.

If you change how the block is defined (like the plane it is oriented to), then yes the change will be reflected in the instances of that block. You will need to adjust how the instances are instantiated to reflected the orientation change. One possible way to do this is to store the current plane of the block as an attribute on the instance itself or some other reference geometry like a point and then in a separate, one time process in GH, re-instantiate the blocks with a transformation from the old axis system to the new axis system.

If you send me your files, I can try and take a look at it for you.

I have achieved partial success, but still few instances go crazy, i assume it is those which planes were changed including insertion point not only orientation.

i am going to play with it a bit and then if i dont succed i will send you the file.

i think this could be cool as a separate component to redefine block orientations but keep instances positions intact. inputs would be name of block definitions old planes of definitions, new planes of definitions and after triggering TRUE component would just change all the definitions and transform instances accordingly.

do you know who is behind elefront plugin? i think this would be a good suggestion to include in the package

I am one of the people :slight_smile:

Nevermind! I saw your suggestion. We operate on blocks as McNeel defines them, so there are limitations. What you describe goes against the concept of a block I think. You might be able to achieve what you a describing by storing the block as an external file and not having a link between the block in the document and the block in the external file. If and when you want to change something as fundamental as the orientation of the block, you have logic that handles the instantiation of the block to deal with all the transforms.

The logic of blocks is logical as it is but it happens in the design process sometimes that you need to redefine the axes for whatever reasons. Even in plain rhino it could be that when editting block, one should have a way how to change plane orientation, not only insertion point. When edditation dialog is closed there could be a prompt asking if you want to change instance positions or not (to change is default now, not to change would be a useful novelty) @pascal what do you think?

OK so i am sending you the files.

in .gh files i have prepared list of block names of interest. there are planes of original blocks internalized as well as intended new planes. in 3dm file block definitions are not yet modified.
the result should be to change definition planes from original to intended whilst keeping positions of instances as in original state.

please have a look at it. i will be grateful because this is somethin i need to get done but i am quite incapable to do that.
ganovska piliere new.3dm (5.5 MB)
please help.gh (14.3 KB)

Ivan, I’m not understanding what you are trying to do. The internilaized planes are all world coordinates. The actual block planes look well defined compared to the geometry.

Yes because you should use insert block component not reference all instances.

Just seemingly. I need to achieve that boundary rectangle of each block is aligned so that X is the longest side.


*i might have picked wrong example as i am looking better. not all definitions are good, 90% are ok, few are bad but i need to figure out solution because this problem will repeat every time even if i a really try to define them always correctly

What you are describing is that you want to apply a transformation to the block definition (such as re-orientation), and you want to apply the inverse of that transformation to all of it’s instances. That way, when the block definition is updated, the instances themselves are effectively “in the same place”.

This is possible with eleFront.

One catch:
If you only click “Bake”, it will only change the definition, and then bake a bunch of new block instances. The old instances will still be there, now with some incorrect orientation. You need to delete these. Therefore I added a section at the bottom which will move all of those old blocks to a layer called “DELETE”, where you can then manually delete them.

If you use a BakeName (which I’ve added here), then eleFront will go ahead and automatically delete the old ones, whenever you bake new ones. You can then change the definitions as you like.

Block_Orient_R6.gh (20.7 KB)

@ivan.galik, @krahimzadeh beat me too it! He is the other guy behind elefront!

I have also whipped up a version that uses the newest version of eleFront, which is still in Beta.

In this version, you do not modify the model directly. You open a new, empty Rhino session, and fire up Grasshopper. The new components have the ability to bring in geometry from another file, and also push geometry to outside files.

In this case, we can reference in the blocks from your file:

I have to do some a bit of fancy footwork on the trees, because you are using asterisks in the blocknames, which work as wildcards. For example “K132" will also return "K1032”, “K11*32”, etc.

Once they’re organized, the script follows the same structure.

This time, you bake objects into your current document (which is empty). It returns back to you the new objects’ GUIDs. You can then reach into the old file, delete the old objects, and add the new ones. It is critical to set the input for “Duplicate Block Names” to “Overwrite”, this way it will update the definition in the original file to the newer version.

Hi Ivan - I guess you’d need to track the change in plane, then then apply the reverse of the plane-to plane-transform to the instances that you do not want to change.

-Pascal

bit unfortunate but it is a diameter of rebar behind *. i have other scripts then which creates schedules…

i will test the script and let you know if you saved my day. i am sure you did. thank you very much. BIG KUDOS TO THE PROS!

do you think this is too niche of use case or more users would benefit if this whole process was hidden inside one component? (i know i can cluster it for my use)

yes yes i could think like that but could not practically make it work :smiley: i had partial successes but something was always off…

@Gijs Why not include this when block handling are being rewritten ? :stuck_out_tongue: