a Degree 3x3x3 cage with 4x4x4 cvs.
all Cylinders are BlockInstance, one Blockdefinition for each height, the Insert / base Point of all blocks is at the center of the bottom circle
For me it feels correct that blocks are rigid and only the (matrix) transformation of the block gets modified. (no deformation).
But - I would expect that the Block Insertpoint ( “Origin” of Instance-Transformation ) is the key . if i draw the Insertpoint and add it to the cage, the block’s origin should stay with the deformed point-location.
…but it seems like there is some magic based on the boundingbox center or similar. - As the Size of the Block-Definitions Boundingbox seams to matter.
please make the block in cage behaviour more intuitive. worst case: an options on blocks behaviour: “natural rubber-like / bbox based - the current approach” vs “rigid locked at insert point”
I can report this. The Space morphs are a series of vectors in space. So, how an object is influenced has to do with the volume it takes up. Even though in this case one way to think about it, is only the insertion point that should matter.
I will try and see if I can get a better explaination.
Dear @scottd thanks for looking at this.
i think i understood the concept of space morph and the vectors in space.
no need for better explanation - thanks.
and yes for blocks i think the insertion point should matter most.
i am not sure if we need an additional priority - which direction is most relevant.
zxy ?
xzy ?
at least it should be documented.
my wish is, that does blocks - even if the geometry is the same - behave different in space morph because of their insertion point and orientaiton:
Actually, deforming blocks would have its uses, and I’ve encountered one problem where it would be a significant improvement. This is the case where we want to deform identical texture-mapped objects - road curbs are a perfect example. Bending meshes without breaking their texture mapping isn’t that simple or intuitive in Rhino.
the base concept of a block is, that it only has a matrix transformation.
(move, rotate, shear, (non-uniform) scale, project to Plane, …)
A bit technical and quite limited… see reading below.
…as soon as you do something else (all UDT stuff) then this, its no longer a block.
but i see your point - seams like a new topic “cageEdit - preserve UV-Mapping” my guess: set up a custom Rendermesh-Resolution, set up a Mapping with UV-Editor then Extract Rendermesh, do the UDT-stuff with this Rendermesh - as far as i understand the Rendermesh has u,v s for the texture mapping. - not a Render expert and did not test it.
If it’s not possible to deform blocks and let them share the same geometry for technical reasons, then I’m fine with that. However, from the user’s perspective, blocks also serve as a convenient container and a way to control shared properties across many block instances. Sometimes I think Rhino needs something beyond the current block definitions (and I’m not even talking about parametric blocks).
