Is there a way to use something else in Rhino instead of hatches? Hatching sucks in R5

The only reason we have to use hatches is to make surfaces printed black and white distinguishable from each other if they represent different product. Color PDF looks fine 'cause you can distinguish them by color, but when you print grayscale paper set - same “brightness” colors are printed the same hence use of hatches.

That wouldn’t be a problem is Rhino rendered hatches infront of the surfaces if they are coplanar, but sometimes Rhino gets confused and you have to go back to your model and move hatches millimeters infront of the surfaces to see them in detail views. That’s very annoying and time wasting.

^ It looks something like this.

1 Like

Perhaps a different working display mode you can raster print would work instead.
Have a look at “Simple Bright” on this page:
https://wiki.mcneel.com/rhino/advanceddisplay

Rhino has Movetofront etc for draw order, have you tried these?

Btw: Using the layer hiearchy for draworder is something I have wished for for years. Maybe this can be revisited for v6?

3 Likes

On a layer priority property similar to what Microstation has, where you can assign a value to a layer and that controls the display order.

Initially I would prefer Illustrators approach where layer 1 is in front of layer 2 and sub layers within layers also follow that approach. But I can see that this could cause issues if one accidentally clicks the “sort alphabetically” button…

We often use two hatches on top of each other to get different effects for landscape plans, where in example grass is green, rough is green with hatches and armored grass is green with cross pattern.
(So I would love to have both background fill and pattern in one hatch, but I don’t think autocad supports that and I think that link is pretty important for the majority)

Actually, AutoCAD does support background fill and pattern in one hatch. It would be a very welcome addition to Rhino in my opinion.

This is what BringToFront does. It’s global and screws up all other views and the model looks like a mess.

Relevant:

That’s very close to our the display mode we use. Again, grayscale print outs will make all materials look the same or indistinguishable, 'cause no more color. The hatching was the only sensible way out, but it’s way too far from good, especialy on massive projects with several different products and multitude of parts.

Greetings John,

Maybe you can clue me in about which directory to place the xxx.ini files to get them functional?

The ini files are just delivery vehicles.
The actual display mode lives in your Rhino on your workstation.

Download the ini and put it anywhere.
In Rhino Options > View > Display Modes, click on the Import button and browse to the ini file.

Once read, you’ll have the new display mode on your list.

Thanks John!

you still have steps to configure the drawing order of each object individually.
bring to front places something on the most upper layer which of course hides everything else.

^ Not with hatch and a surface case. Surfaces draw order is not affected by those commands. You can’t force R5 to draw hatches infront of particular surfaces.

well i can confirm that this is a bit bugy, also on the mac, but bringing the back one to the front and then the front one to the front again seems to help. no matter if surfaces and hatches are involved. try if that works for you either. otherwise you have to explode the hatches, that for sure will do the trick even though this is sure the last option.

^ I don’t know how it is on Mac, but on PC you can’t select surfaces to apply any of the draworder commands. We normally suffer through it by moving hatches infront of the surfaces. And bring forward acts the same as bringtofront on hatches. They will bleed through all the geometry in your model in all the detail views.

strange yes surfaces and surfaces and general objects over objects does not seem to work. only curves. and hatches over surfaces workes only when you send the hatch infront of a surface or to the back of it.

@pascal do you know if thats intended?

Hi Richard - correct, draw order only applies to curves and annotation.

-Pascal