This is why I said.
By “ground” I do not mean anything negative, I am naval architect so I needed a way to differentiate 
Make a box, use Block command to turn it into a block.
Now double-click : you can enter the BlockEdit mode. Great. Exit the mode. Scale the block 1D in any way.
Double-click now. Can’t do it for non-uniformly scaled blocks. The argument is in many cases it should be OK, but in some, it won’t work. We’d like this to work for the cases it can.
Why would you scale the block instead of scaling the objects inside when you open it for edit?
What is the purpose of that?
Can you give a practical example, I cannot understand?
Imagine your block is a tree. You populate model with them, each of them scaled slightly randomly, in a non uniform way, for more natural look.
With that setup, you can’t double click and edit any of them, not even change block object materials that does not change model at all.
This is just one of a lot of examples of non-uniform scaled block uses.
Another one could be a simple column with different lengths, for more technical-minded folks to imagine 
3 Likes
I understand now.
Why don’t you use Grasshopper for all this?
I think also if you have a script that will manipulate the object inside the block will also change all instances of that block.
hm… that does seem kind of wrong doesn’t it…
https://mcneel.myjetbrains.com/youtrack/issue/RH-52030
-Pascal
Block technology is very popular and if we are talking about exporting those trees eg 3dsmax or skp or whatever, they will preserve the connection like in max they will be displayed as instances in skp as components . Grasshopper is greate and i absolutely understand you position , i am working in grasshopper also and from my experience i can say that it is good as long as - 1.the project is not big 2.you can do everyhing in rhino and there is no need to share it
By the way , scattering is not the best example) It is indeed should be done in grasshopper but when you need to make a design with repetitive things - thats where blocks and direct modeling tools are really needed
This is irrelevant, GH does not make sense in a lot of our workflows that are much faster and more efficient with direct modeling. I don’t see how GH has anything to do with editing non-uniform scaled blocks.
I use scripts to change objects properties inside blocks, which works with any block instances, but when it comes to direct object manipulation / removal /addition, scripting these is not very practical.
Well, I was trying to defend your case from your original post, scattering has nothing to do with this; I may have 2-3 tree models only, and it was used just as a random example, you may as well take any jewelry ornaments, structural or architectural elements that may come in a form of a block instance are quite often are non-uniformly scaled.
If you don’t get the point by now that means you probably don’t need or use this functionality.
–jarek
1 Like
I understood how you’re using it but not why are you using it this way.
From your descriptions I understand you use blocks inside these blocks you have multiple objects with configured materials (I assume you’ll render this afterwards).
You don’t want all objects (blocks) to appear the same. Right?
You cannot scale a block instance and then edit the contents (Rhino limitation)
So workarounds I see are:
- Use grasshopper creating different instances of the same object modifying them randomly. (You reject that approach)
- Use scripts to randomly modify (scale) the contents of the instances. (you say not practical)
- Duplicate your block instance (make a different block definition). Edit the contents (scale, rotate). Now you have two block definitions one the original and the second one is modified.
- Use event watchers. This may be very huge scripting project on its own.
While typing this, I came to the conclusion that you may need 100-1000+ instances of the blocks and all of them different size. If that is the case I’m afraid Grasshopper is the only solution right now.
hi Ivelin,
‘why’ is different in each project case, the question is ‘why not’ be able to direct-edit non-uniformly scaled blocks, if there are cases when it is completely fine, even with changing the geometry inside, not to mention just simply project properties).
I use blocks in many different ways, and I was using a tree block just as an example of a non-uniformely scaled block, not realty asking for advice of how to deal with scattering etc. - we are doing just fine in that area.
My comment about Grasshopper as a solution to everything was more general. While it is super useful in many many scenarios, especially when you want to keep your design parametric, people seem to forget the power of direct modeling. Many times GH is an overkill. I see users that have no idea how to use Rhino without Grasshopper and build complex definitions for super simple tasks that Rhino can just handle very well, with no need for being parametric or so complex. I know Grasshopper well and can use it when needed, but never consider it an ultimate solution for all Rhino tasks.
Having said that, and IF I was looking for a workaround, by far the simplest workaround was to just insert a non-scaled new instance of the desired block, and edit that one. But the hope is we can save this step. Forget about scattering of 1000s of instances. How abut I just have 1 instance in the file, that is non-uniformly scaled. I want to edit this. Can’t now. End of story.
Looking at your proposed workarounds, they all seem to defeat the very idea of using block instances. The idea is you really have just 1 copy of the geometry, and each instance just remembers the Xform applied. This makes the file small and fast. Your proposed ideas, whether implemented with GH, scripting or by hand, don’t take advantage of this.
Defeats the purpose of having block instances to keep small/fast file size and single geometry source
I want to modify the content not only randomly, but manually, using snaps, moving things around, using my brain and design sensibility, not algorithms
How is it different than #1. In any case, still created extra geometry for each instance, which I don’t want to.
huh ? 
I think we veered off the subject here a bit. Let’s just say I add +1 for enabling non-uniform block edits when possible. Other than that our workflows are fine.
thanks,
–jarek
1 Like
When you edit non-uniform block, do you expect all other block instances to reflect the changes as well?
And second question:
How many objects do you have usually in a single block?
Just to be clear, I’m interested, perhaps I can use blocks more and what you suggest may indeed be a necessary feature.
Update:
Do you do this? Keep instances of otherwise nested blocks separately so you can modify?
Sure, that’s the very idea of having a block instances. The only variation between the same block definition possible are properties that are set ByParent. Geometry is always the same across all instances.
It is more of a convenience thing, not a big new feature.
You can either keep them, or re-insert them when needed to edit in place (as long as the instances are present in your model, the main definition is alway available to be insterted unchanged). The thing is, many times it is an extra step; or perhaps you need to edit the non-uniformly scaled block instance to fit a particular placement in the scene in reference to other object, so editing it elsewhere is not intuitive).
5 Likes
What about using grouped objects inside a block instead of blocks in blocks, anybody ever do that? I group objects I want to scale as a whole. You know the group command.
Blocks discard grouping information (even if you don’t care about the benefits of nested instances). It is another thing on the Blocks wishlist to retain groups.
1 Like
oh, I see now. I gave it a look and managed to find a problem. if I individually group three items and block those groups, done, then after I double click one of the groups I see on screen the Block edit Dialog pops up, says three groups. When I click OK I get a serious error message. So lucky me.
that error must be RhinoCAM specific. Normally groups are just being discarded once inside Block definition.
it is, I unloaded it and it quit doing it.
Ok, so I made a block, border like, and added 3 objects into the border block. Then I slightly dragged a scale handle, and got the message when I tried doble clicking to add another object.
So now I can be glad I don’t need to do this.
1 Like
so if I wanted stretch one of the three in the border block, I could explode the block containing the three items, explode the one I want to stretch one way, stretch it, make it a block again, then remake the border block and insert the three items back. That is a real block blocker for me if that is what it takes.
It’s somewhat understandable why editing non-uniformly scaled blocks creates problems transforming the changes back to the original geometry. Think what happens when a shear transformation has been applied to the geometry…
However there’s another approach that I’ve seen in some other modelling software to edit non-uniformly scaled blocks. When user edits the block, it’s displayed in the original scale without the other geometry shown. That seems like a good compromise. Why couldn’t that be implemented in Rhino?