If I create a block while using a custom CPlane, I would expect the new block to use this CPlane as its orientation, or that I could at least have the option to choose between World or CPlane orientation. This would help a lot the workflow with blocks !
In the same spirit, if I use Insert command to place a block instance, the new instance uses my current CPlane orientation, but if I drag a block from the block manager panel, the new instance uses world orientation. Could we have a setting to choose here ?
Seriously, is there already a way to do this that I don’t know ? I can’t imagine everyone here is only creating blocks aligned to World Orientation ?
Well, here is an example of a workflow where I have a custom CPlane, where I draw things - here a simple box. Two other boxes are drawn to show World orientation.
I would like the option to choose not only a reference Point, but a reference Plane (or maybe let the user choose between World and CPlane orientation)
In the video below, you can see what is currently happening : the block orientation is illustrated in the end with the gumball. This feels really unintuitive to me.
The fun really starts when you then try to insert your new block : you have to revert to World Cplane in order to have it inserted with the same orientation… Again, with only a reference point, it’s no surprise some illogical behavior like this happens..
Similar to _Insert, if you right-click the block in Block Definitions panel and select Insert, it places the instance relative to the current CPlane.
_Insert places the instance relative to the current CPlane, but _Block defines the block rotationally relative to the World XY plane with an optionally translated origin.
And please allow an update block insert point / cplane.
expected behaviour:
define a block with a badly defined insert point / cplane.
after a few inserts you see that it makes more sense to have another insert point.
changing the block s origin / cplane should update all existing instances to not change their position / geometry placement.
Thanks for the script, but I already have workarounds. I would much rather have this behavior as an official feature. It would be a consistency question…
I mean, the block definition has to register some kind of orientation data at its creation, why not let the user choose a specific orientation ? In Grasshopper, Elefront always asks for a Plane when creating a block definition, and use world if none provided, which seems to make a lot of sense.
Thanks but again, I am not looking for an alternative. As a somewhat experienced Rhino user, I know well how to navigate this.
But when teaching, I have no senseful explanation as to why would Rhino not use the grid heavily shown in the viewport as block orientation when creating it. It honestly feels like a bug.
