Hello - you can non-uniformly edit the contents of a block (BlockEdit - the definition would be changed to be scaled accordingly) but you cannot non-uniformly edit a block instance and then BlockEdit that block, if you see what I mean.
-Pascal
Yes, but why?
I mean, it would be nice if it was possible, AFTER a warning was shown of course.
OR if it said, “This block is nonuniformly modified, do you want to temporarily uniform it while it is being edited?” kind of like how editing an inserted file opens up another Rhino and puts the other Rhino on hold.
Also, it would be greeeat if it was possible to pop up a scale and rotate dialog box for any block where the scale and rotate info is shown and can be edited… (kind of like what any other 3D program has…), I mean, Rhino already knows that data for any given block, it just isn’t available to the users… I have wished for that for years 
Count me in for that one :). Maybe this would be a tab, BlockProperties, similar to BoxEdit, with the transforms that are editable from the dialog…
Hi Jorgen - when you block edit, you get at the block definition, transformed for convenience to the instance location and orientation. Remember, when you’re done, the stuff you modify goes back and becomes the definition. So if you stretch an instance, the definition is unchanged but another transform is applied to the instance. You can’t then get into the definition of the stretched block from this instance with stretch applied - if you could, then the stretch would go back to the definition and all instances would be stretched.
-Pascal
Obviously, and that would be OK in many situations, just like editing a uniformly scaled instance 
(IF a warning was shown of course)
Sometimes all we need to do is to edit the content, move to another layer, change colors, delete some stuff. Things that is OK to edit in a scaled block and thus affect all scaled and unscaled versions. Just like it is OK to edit a scaled block, basically it is no difference IF the user knows what it is doing, and or is warned about the consequences. It would be convenient IMO.
But what would you expect to see once BlockEdit launches?
-Pascal
Scaled content, just like when editing a uniformly scaled block 
Hi Jorgen - and that would be essentially inert, except for attributes, is that correct?
-Pascal
I am not sure if that was in the english class I attended back in the day…
Joke aside, I don’t know what that means, but to me, as a user, editing a block that is 3D scaled to say 0.2 and editing a 1D scaled block that is only scaled 0.2 in it’s X axis should act the same.
I fully understand that this is a can of worms though, hence the needed warning.
Well, part of the can pf worms that I see is that say, for example, adding a fillet to a box that has been skewed by scaling into a parallelogram… would not work - could not be reverse-scaled and applied to the definition - as Rhino works now - but changing an attribute such as a color or layer or user text could.
-Pascal
Am I hearing “we want dynamic blocks”? Rhino blocks currently aren’t even at a baby stage. They’re in embryo stage. That’s in 2019. Not that it matters. Rhino was never an architecture/construction oriented CAD software. And it won’t fully be as long as RCPs detail views aren’t natively supported.
I mean AutoCAD dynamic blocks were rad back in 2005 as long as you had a triple quadros in SLI… /s otherwise you’re better off without that performance hog POS.
Hi Pascal,
I guess part of what we are asking is to let user do weird stuff if they are ready to face potential consequences, by enabling non-uniformly scaled block edits. As you mentioned, just changing objects attributes is harmless, as well as many transform operations. Of course you can try to edit a block that has been transform-projected into a 2D space and these are the can-of-worms cases, but as long as you display a warning that editing non-uniformly scaled block instance may yield weird results, users should be fine. Or it can just fail if really weird stuff is being attempted.
Here is a test script that actually does just that - acts on any-transform block instance, and lets user fillet edge and add a box to the definition, which in turn gets updated in all instances. It is reasonably simple matrix transform play… So I assume block-edit could do the same, with its elegant UI, plus a warning…
https://www.screencast.com/t/xUAgm25dMO
sample file to try:
NU_BlockEdit_Sample.3dm (73.7 KB)
test script:
test_NonUniformBlockEdit.rvb (1.5 KB)
–jarek
Finnaly someone said it!
Yes , for me it is so painfull that this wonderfull technology is soooo bad at rhino! I mean so bad that you even do not know what to start with!
If it is hard due to rhino math limitations then may be:
-Please add at least automatic rescale to uniform when double click on nonuniformly scaled block and back when it done and maybe it would be very usefull to keep ghosted lock-like ticks or edge lines of finall block during editing.
-Only mesh blocks ?! I am sure this is easy to implement with mesh objects only!
-Only polylines/curves blocks edit?
-Freeze objects in block during editing that cant be edited in non uniform scaled block!
I hope rhino devs will pay attention to that weak point.As i said before current block system keep many arch studios on skp+acad pipeline which is kind of primitive and boxy.
Exactly!
Wonderfull!
Hi Jarek - I did not try it yet - I believe you and I’ll take a look tomorrow - my point is that I can’t imagine it can be robust - imagine there is a feature near the edge - the fillet rail will be closer to or farther from the edge depending on the angle of the skew, so may impinge on the feature or not - differently in a skewed version than on the squared up one, or the fillet will be round in once case and not the other - that sort of thing.
-Pascal
Agree, it would be ridiculous to fillet edges in skewed block transform, can’t imagine it would be helpful. But this is just one of many cases, and in the others it would be perfectly fine (changing attributes, adding some objects to the block, moving a face, operating on really simple objects). The question is should these simple ones be banned, because the complex ones don’t make sense. I’d say NO
–jarek
Hi Jarek - but adding objects - if you open a non-uniformly scaled block for editing and see the scaled objects - what happens to the added objects when the edit is finished? How does the definition absorb these? Reverse scaled?
We get into trouble as it is with solid editing- works great on boxes, but it is very easy to create a pile of junk… that is about the level of messiness, at best, that I’d expect. My preference of the moment is to suggest allowing positional and attribute changes - I’ll ask the devs to comment on anything more than that…
-Pascal
Some time ago, I wrote this up. Several people had contributed.
yup, see the added box sample in the above video. The “original” could stay as-is, the way current BlockEdit handles new object additions.
What the sample script does, is simply reading the xform of the transformed block, inverses it, uses that xform to put back the edited block objects to its no-transformed state, and replaces the original block definition by redefining the block in its not transformed state.
I’ll let go for now, I think there is plenty to look at if anyone from the devs team would look into it and needed input. Thanks for looking into it!
-j
This objects adding to non uniformly scaled blocks with reverse scaling in original block seems pretty good workaround ! Then there is no need to edit geometry inside n-u scaled block if you can just create it outside and then add !