Rotating and scaling hatches - again

This is not precisely a WIP question, but as nothing will be done in V6 or likely in V7 about this, I am putting it in this category as “Future”.

HatchTest.3dm (1.2 MB)

So, above I have a façade. It has been imported into V6 (or WIP, doesn’t matter) via .dxf. Rhino guessed the file was in mm on Open, but in fact it was originally drawn in cm. So, the measurements are all 10 times too small.

Now, I need to have the file at 1:1 scale in cm, plus the façade rotated so it’s horizontal so I can continue to work on it. (Note this is just a simplified sample, the actual file is much bigger and more complex.)

  1. Convert the file from mm to cm and accept the scale.

The hatches are now 10 times too large in scale. IMO they should have scaled correctly with the units change. Run _HatchScale – set to Enabled and the value to 0.1 – OK, things go back to normal. But, again IMO, this is not a good solution, as it only works while HatchScale is enabled. If it is disabled, or the file is transferred to another computer where it HatchScale is disabled, the hatches blow up again. The hatches need to be scaled “natively” when changing the model scale.

In the end, I will need to have the file back in mm and at a certain scale for production of a physical model, so the craziness starts all over again.

  1. OK, let’s deal with the rotation now.

Select all and rotate the façade so it’s horizontal (the angle is ~50.98°). The hatch rotation angles do not rotate with the rest. So, one needs to figure out what angle to input in Properties to get them back to their original orientation. There is no “rotate incrementally” (relative to current).

This one is relatively easy because bricks should be horizontal, if the pattern was correctly made originally, one can simply select them all and enter 0. Ooops, nope, the bottom row is actually a vertical tile pattern and it has already been rotated 90°, so you already need to do those separately from the rest.

And suppose if there were more hatches with many different rotations? Then we have a nightmare. For each different hatch rotation, you need to figure out the difference between that and the rotation you applied to the façade and then enter that in Properties. Luckily in this file the windows have a sort of random ‘sand’ hatch that doesn’t really matter if it’s rotated – because there are like 7 different hatch patterns in there and they have some different scales and rotations as well.

This stuff basically just sucks… I agree that the original file is a mess – but it’s the type of mess modelmakers most often get from architects/planners. We need to be able to fix this stuff easily.

I have scripts that help in some aspects of this, but it’s not the type of stuff you hand out to first week Rhino apprentices in class. Those scripts really shouldn’t be necessary if Rhino handled this type of operation correctly.

1 Like

I suspect the DXF is in the unitless “decimal” setting in AutoCAD.

In that case, Rhino does not guess. It just uses the last settings since there is nothing in the DXF file that has a specific unit.

See if you can avoid this whole mess bu starting a new file in CM (the known units of the DXF file), then Import the DXF and not scale anything?

Does that avoid the post open/wrong unit guess/scaling mess?

It’s not actually ‘known’ until you open the file and measure something common - like a building story height - to see what a logical value should be. But the main complaint is not about the import units - I no longer expect that to be right and haven’t for ages. Yes, if you manage to “guess” correctly CM, the hatch comes in correctly initially.

But that doesn’t really change much, because the rotation problem as outlined above still exists and sooner or later I have to scale the geometry in the file down to the correct scale for producing physical model parts - and then the hatch scaling problem will come back and bite me in the a$$.

I don’t know what to suggest. If you manage to guess the actual unit system the AutoCAD user intended, then you’re set. I wish Autodesk had never adopted the unitless system for this very reason.

When I run into these problem on tech support, checking the units and tolerance are the first things I do.

No, you missed the main point… Even if I guess correctly and the import is good, later I have to rotate and scale the whole model for production purposes (say 1:200). That’s where the hatches don’t follow and that’s a completely Rhino-internal problem.

I fully agree with Mitch on everything he said, it is a real pain with a complex file!

I was about to suggest that you could change the CPlane to match the building orientation and use Plan to align the view. Then export as dxf and bring it back to Rhino so the file gets properly oriented using World Top CPlane but the problem now is that hatches don’t come with proper scale, why is that??
HatchTest2.3dm (4.2 MB)

I tried opening the same dxf in Archicad and it came the same as in Rhino hence the problem comes from the dxf exporter…

Don’t think it works that way - a .dxf export uses the World orientation and not the current CPlane orientation (which is internal to Rhino). So the object remains in its original orientation when re-importing.

It works, I used export with origin. Try the file I posted, it is the imported dxf file generated from Rhino. Run CPlane WorldTop and you will see that the building is correctly aligned.

Yeah, that’s what I tried as well - the first time it didn’t work… Now it seems to be working, must have hit the wrong button somewhere… But yeah, the hatches are the wrong scale again - maybe because you don’t have HatchScale enabled in the importing file… In any case, it’s a mess that’s difficult to workaround.

I also get some funny values for rotation in Properties - should be 0° (or some even multiple of 360°)

image

(close, but no cigar)

That was it! You are totally right, you have to be a genius to remember to do all this properly. I tried again and everything is working properly, even the rotation is correct now

At least we have a workaround until they fix this.HatchTest3.3dm (4.5 MB)

Yeah… painful. It also presupposes that you actually know what the hatch scale factor should be - i.e going back to ‘guessing’ the original file units and then trying to figure out the correct hatch scaling via the unit conversion factor. A lot of really iffy propositions.

1 Like

I’m not aware of any mechanism in Rhino to lock a hatch pattern base and rotation to a specific object, that will survive scaling and rotation as long as it is a Hatch object.

If you get the Hatch the way you want it, and know you’re going to rotate or scale it and need it to stay linked to it’s border, then Exploding the Hatch and Grouping it with it’s border curve is the only thing I can think of.

Yes, and you can imagine the file size afterwards if it’s a fine brick hatch and you have lots of them. Plus you still need a script to do this on numerous objects at once.

I was curious to see what kind of file size this would generate so I started to do a test… But try exploding one of the brick hatches in the file in my first post… Notice anything?

So now having completed my test:

  • just the hatches in the file in the first post - file size: 300Kb
  • hatches exploded - 61467 curves - file size: 14Mb

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

Just in case anyone needs, here are a couple of scripts to incrementally scale and rotate hatches - that is to say from each hatch object’s individual pattern scale or rotation, multiply by a given scale factor or add a rotation in degrees. This then allows scaling the pattern in any number of hatches by a factor no matter what their original pattern scale might be, and rotating the pattern in any number of hatches by a certain amount no matter what the original pattern rotation might be.

RotateHatchPatterns.py (1.1 KB)
ScaleHatchPatterns.py (1.2 KB)

2 Likes