Bug: Block definition out of sync with model scale with units change

Adding to block frustrations from the other thread: Wish: Make embedded block parent always visible like other geometry - #15 by Jarek

  1. Start a new file in mm and make a block
  2. Change the scale to meters with option “NO”
  3. Insert the block definition.

It’s tiny.
If it’s geometry is edited all instances will get as tiny.
If one of the other instances is exploded and edited the other instances stay in size. There is something going on with the logic here.

Hi @ThomasAn,

An instance (e.g. block) definition retains the unit system from the document in which it was created. This way, when you insert the instance into another document that has a different unit system, it will be scaled appropriately.

But, the unit system of an instance definition is not linked to the unit system of the original document. If you change the unit system of the document, you will need to edit the instance definition and scale it’s geometry appropriately. Use the BlockEdit command for this.

It’s common for users to keep multiple sets of blocks in specific unit systems.

Hope this helps.

– Dale

Yes, so … if the ORIGINAL document changes its units, then it makes sense for it’s own block definitions to follow suit automatically along with the rest of its geometry. It is not happening that way, as shown above. (those blocks were not linked from outside, they are local)

Oh, I think you were thrown off at step 3 where it said “insert the block definition”. That was a definition created on step 1 and then re-inserted within the same file.

Yeah, the newly inserted instance has a scaling transform applied, as if the answer to the scaling question on unit change had been ‘Yes’ I suppose. @dale - is that expected?

Make a block, change units (No to the scaling question) , insert the same block - the new instance is scaled.

-Pascal

My apologies for not explaining this better.

Rhino does not treat instance definitions you create in a document any different than embedded instances you insert from an external file. The instance definition knows is originating unit system, and this does not change if you modify the unit system of the host document.

Let’s say you create or insert a standard 30" sink block into a document whose unit system is inches. Now you choose to change the unit system of your model to meters. When you insert the sink block again, it’s size should remain 30" (0.762 meters), not 30 meters.

Let me know if this makes sense.

Thanks,

– Dale

So, if I make a robotic arm and then decide to make scaled replica by 10x (say change it from mm to cm), then I am screwed. All block definitions stay tiny.

You guys assume we are all architects ?
Essentially you need a third option in the Dialog:
a) Scale geometry
b) Do not scale geometry but shrink all blocks
c) Do not scale anything.

You are missing option (c)

Wait a second, you had me going there for moment. If an architect changes model units they will answer “YES” to the rescaling question. Otherwise their whole building will go from 100 ft to 100m and the ceiling would go from 8ft to 8m.

This bug report is only when the answer is “NO” to the rescale question.

If you choose not to scale your model when changing unit systems, then after you close the Options dialog box, select one of your instance references and explode it. With the exploded geometry selected, run the Block command and create a new block with the same name as the one you exploded. When prompted to replace, click Yes. Now run the Insert command and pick your block - it will insert as the scaled size.

– Dale

So it’s not a gotcha ?
What do I do that if all instances have different sizes and rotation ? Which one do I pick?

You guys do things once but we deal with these things for years when not done right, we just don’t always come here and nag you.

Units.3dm (44.3 KB)

I don’t know - I’ve only tried to explain how the system works and to help you move forward (hopefully).

I’ve logged the issue in our issue tracking system so we can consider other options:

https://mcneel.myjetbrains.com/youtrack/issue/RH-65016

Your welcome to “nag” all you want. All this helps us better understand how (and others) work.

– Dale

I know you guys mean well and always have, but I am noticing a number of small stuff are slipping through the cracks.

The problem is, as a user, I end up more frustrated by small things if I get a hundred paper cuts from them a day. In this case (not the simple example I sent you) I had to delete all instances in the entire file and do over while yelling “to hell with blocks” all day long because someone wanted 8meter ceilings but the kitchen sink should stay the same.

When users end their days bruised or are being told to solve a Rubic’s cube and that they should have discovered an undiscoverable UI feature they end up with a sour taste too tired to recommend Rhino and you guys rely on this for growth. So while you focus on big features with world-class nobel-prize math it’s the small stuff that stay and annoy (also most users don’t like to come here to nag, because at best you will put something on a 70,000 long bug tracker for 2030 anyway)

1 Like