Rotating and scaling hatches - again

[Helvetosaur]

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.

2. 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.

[John_Brock]

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?

[Helvetosaur]

@John_Brock

See if you can avoid this whole mess by starting a new file in CM (the known units of the DXF file),

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$$.

[John_Brock]

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.

[Helvetosaur]

@John_Brock

If you manage to guess the actual unit system the AutoCAD user intended, then you’re set.

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.

[jespizua (José Espizua)]

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

@Helvetosaur

And suppose if there were more hatches with many different rotations? Then we have a nightmare.

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…

[Helvetosaur]

@jespizua

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

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.

[jespizua (José Espizua)]

@Helvetosaur

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).

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.

[Helvetosaur]

@jespizua

I used export with origin.

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°)

(close, but no cigar)

[jespizua (José Espizua)]

@Helvetosaur

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.

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)

[Helvetosaur]

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.

[John_Brock]

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.

[Helvetosaur]

@John_Brock

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

[John_Brock]

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

[Helvetosaur]

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)

[Helvetosaur]

Re-opening this topic:

The original complaint has only been partially addressed in V7 - but the YouTrack item has been marked closed.

The Rotation issue has been solved and works correctly. However the scale issue raised in the original topic was not addressed. Therefore I respectfully request that the item be re-opened and the scale issue fixed as the rotation issue was.

To see the problem, another simple file. One single hatch plus an outline. First use Rotate to rotate it from the current angle to the horizontal. Works correctly, notice the hatch angle in Properties also updates.

Note the current hatch scale is 1. Now, use Scale (or Gumball handle with Shift) to scale the hatch and its outline 1/200. The geometry scales, but hatch scale doesn’t change. It’s still 1.

The HatchScale command must be enabled and used with the same factor to scale the hatch correctly in model space. This is completely unintuitive and requires of course for the user to first know about the existence of that command, but also the particular scale factor that needs to be used. Plus it’s 100% useless if you export the hatch via DXF for example and import into another cm file. If HatchScale isn’t enabled in the importing file, and/or you don’t know what the scale was supposed to be (say the hatch came from someone else), likely you won’t even see the hatch on import because it’s 200x too big. And you will never know what the original scale was supposed to be - that information is lost.

When the Scale command is used on hatches, the hatch pattern scale needs to scale with the object - just like the rotation angle now correctly does with Rotate. That was part of the original request. @lowell

RotateScaleHatch.3dm (1.8 MB)

[Tom_P]

Dear Mc Neel, Dear @John_Brock
I have a similar or the same ? problem, running rhino 7 latest Version 7 (7.10.21256.17002, 2021-09-13) und Mac Os X 10.15.7
The dxf I handle is drawn in Meters, i need it to be Millimeteres and therefore scale it with factor 1000 either by the dialogue in the preference → units or manually.

the result will mess up the hatch positions:

Import as Meters

After changing to Millimeters with scalling

all the black noise is displaced hatches.

I will send the file to support / upload, if you want to have a look at it and address it with the basic “tech” address.

kind regards - tom

[pascal (Pascal Golay)]

Hi Tom - Sorry - I see your file on our server but for some reason I cannot get at it through our download system - I see that it has a sort of ‘double’ extension .dwg.zip. I don’t know if that matters but could you please try naming the file without the dwg extension in there and upload again?

-Pascal

[AlW]

Usually when I’ve seen a filename with two extensions like this it just means a .dwg file has been zipped. Have you just tried unzipping it using your usual means? Or doesn’t your download system allow zipped files? Maybe there’s a way to override it if you are certain it is trustworthy?

[Tom_P]

the upload to support asks to zip the file before uploading
Please compress your files into .zip, .rar, or .7z format before uploading.
uploaded a second time with one extension only.
kind regards -tom