Hatches are a problem when zoomed out on design layers (or am I missing something?)

[line-weight]

Here is a wall, seen in 3d in a design layer, in a shaded view:

 

 

This is fine. I can see all the components clearly.

 

Here's the same wall, still in design layer, viewed in top/plan:

 

 

You will see that I use a hatch fill for three of the components.

 

An initial reaction might be that I am using very dense hatches. Actually I'm not, and the reason they appear like this is because I have all of my design layers set at 1:1 "scale" for reasons I won't try and explain here.

 

This is what the same wall looks like when I zoom out a bit:

 

 

Not very pretty but just about workable - I can still (relatively) easily distinguish the three different hatches.

 

However if I zoom out more:

 

 

Now the hatches look horrible and are barely distinguishable from one another. It's quite unpleasant working on drawings where a lot of the walls are like this.

 

My question is, isn't there a better way to render hatches when zoomed out like this? For example, could they just revert to a solid colour?

 

Alternatively, is there a way for me to set up walls so that when I'm viewing them in top/plan design layer mode, the components are shown as solid colours, but whenever they appear in a sectional viewport, they use the hatches I've assigned to them?

 

Or... could we have an option not to scale hatches when zooming in and out in a top/plan design layer view?

 

 

 

[Tom W.]

Can you change the Hatches to World Based? Most of my section fill Hatches are Page Based + I'm sure there's a good reason for that (so I can scale them in VPs no doubt?) but I'm sure I'd manage just as well if they were World Based.

[rDesign]

From the described DL behavior, I would suspect that they already are World-based hatches, no?

[Tom W.]

2 minutes ago, rDesign said:

From the described DL behavior, I would suspect that they already are World-based hatches, no?

 

I guess what I mean is that because the DL scale is 1:1 the Hatches look super small because they are page based + designed to be seen in a 1:50 or whatever VP. If the hatches were world based they wouldn't look so small on the DL because their size would be relative to the object (the wall) rather than the page.

[line-weight]

I want my hatches to be page based because that's how I want them to appear in viewports (if I have a 1:50 and 1:20 viewport next to each other on the same sheet, generally I want the hatch to appear the same in both).

 

However - I don't think page or world based actually makes any difference when viewing on a design layer. The hatch effectively remains at a fixed "world" size regardless. Zooming in or out doesn't adjust the size of the hatch relative to anything else.

 

The only thing that changes the size of the hatch relative to the rest of the geometry is changing the "scale" of the design layer.

 

Here's how the same wall appears if the design layer "scale" is set to 1:50.

 

 

This is more manageable - it still looks ok if I am zoomed out quite a bit:

 

 

And if I'm zooming out further than that, I probably don't need to see the individual components anyway.

 

But then there can be the opposite problem, where the hatch is really too big if you are working on a close detail. Here with design layer "scale" 1:50:

 

 

and here at 1:1

 

 

The speckled hatch of the top layer doesn't show at all in the 1:50 version.

 

 

 

[line-weight]

There's already something that helps deal with a similar problem with line thickness - the "zoom line thickness" function.

[Jeff Prince]

I find turning the component class(es) solves this problem 🙂

it really is a shame how some things look so muddy when zoomed out.  A LOD based on zoom factor would solve the issue, like how the Game/real time render engines work.

[Benson Shaw]

@Jeff Prince “turning” ? Please clarify.  Did you mean Off? Toggling? Or???

 

thanks. 
-B

[Tom W.]

7 hours ago, line-weight said:

However - I don't think page or world based actually makes any difference when viewing on a design layer.

 

My hatches are page based + looked terrible at 1:1 scale on the Design Layer. When I changed them to world based + adjusted their scales accordingly they looked much better.

 

If you keep them page based you could use a Data Vis to show them as solid colour on DL. Or turn off component classes like Jeff says. Or set up your detail levels so is low detail  at 1:1 (at low detail components are automatically off - but of course everything else will be low detail too which you might not want).

[Tom W.]

9 hours ago, line-weight said:

However - I don't think page or world based actually makes any difference when viewing on a design layer. The hatch effectively remains at a fixed "world" size regardless. Zooming in or out doesn't adjust the size of the hatch relative to anything else.

 

To illustrate this is at 1:50 design layer scale:

 

And this is at 1:1:

 

But yes if you want the Hatches to be the same scale in different scaled VPs this isn't going to help. It only solves the DL problem.

 

[line-weight]

36 minutes ago, Tom W. said:

 

To illustrate this is at 1:50 design layer scale:

 

And this is at 1:1:

 

But yes if you want the Hatches to be the same scale in different scaled VPs this isn't going to help. It only solves the DL problem.

 

 

What I mean is that in a design layer, changing between page/world hatches doesn't affect the behaviour of how the hatches display when you zoom in and out. If you zoom out from the design layer in your file, the hatches will at some point turn into a kind of dotted pattern where different hatches are barely distinguishable from one another. This is what I don't want to happen.

 

This is not so much of an issue for someone that is able to set their design layer "scale" to something similar to what most of their viewports are going to be drawn at, because the hatch will degrade around a level of zoomed-outness where you're unlikely to want to see different hatches anyway. My problem arises because I want my DLs at 1:1 but I think this can be an issue for anyone who might want to be able to work on things in the design layer at a wide range of scales.

 

It's a non-issue if classes are set up to show a solid colour (or in fact a pattern) in section - it only becomes an issue with hatches.

 

It pops up in "section-in-place" editing as well as top/plan view in the design layer.

 

For some time I have kind of dealt with it by starting projects out with things set up with solid colour fills - because that's easiest to work with when modelling and editing the model. But then at some point, when I'm moving on to more formal drawings, I change everything to hatches, so that it looks as I want in viewports on my drawing sheets. This is a totally unsatisfactory way of working though, because of the time it takes to switch it all over, and the fact that from then on editing the model becomes a rather ugly business.

[Tom W.]

4 minutes ago, line-weight said:

What I mean is that in a design layer, changing between page/world hatches doesn't affect the behaviour of how the hatches display when you zoom in and out. If you zoom out from the design layer in your file, the hatches will at some point turn into a kind of dotted pattern where different hatches are barely distinguishable from one another. This is what I don't want to happen.

 

Ok then set up a Data Vis so you see solid colours instead of Hatches.

[line-weight]

3 hours ago, Tom W. said:

If you keep them page based you could use a Data Vis to show them as solid colour on DL.

Yes, I have considered using Data Vis. But if I have tens of different "material classes" then I think I need to set up tens of data visualisations, one for each class that I want to change the fill of. And then apply all of these each time I go to the design layer (I don't use data vis in DL much - does VW remember what data vis I want, in between visits to design layers?). And each time I make a new class I have to remember to add & apply a new data vis.

 

The other option is to have them all set up as solid colours, and then use data vis on viewports, to add in all the hatches I want. Some of the same problems remain. When I've thought about doing this in the past, it's felt like it would be impractical because not only would I need to update the data vis themselves but keep making sure they were all applied to all the viewports. This, possibly, is made more practical using viewport styles.

 

3 hours ago, Tom W. said:

Or turn off component classes like Jeff says.

 

I'm not quite sure what's meant here - turn them off where? But I don't want the fill to disappear altogether - the whole point of having coloured fills is to make it easy to see what material class is applied to what object or component, while working on the drawing.

 

 

[Tom W.]

7 minutes ago, line-weight said:

I don't use data vis in DL much - does VW remember what data vis I want, in between visits to design layers?

 

Yes a DV will remain in place until you turn it off + it can also be included in Saved Views.

 

8 minutes ago, line-weight said:

But if I have tens of different "material classes" then I think I need to set up tens of data visualisations, one for each class that I want to change the fill of.

 

You should be able to do it with one DV + also save it in user folder for use across all files.

 

9 minutes ago, line-weight said:

3 hours ago, Tom W. said:

Or turn off component classes like Jeff says.

 

I'm not quite sure what's meant here - turn them off where? But I don't want the fill to disappear altogether - the whole point of having coloured fills is to make it easy to see what material class is applied to what object or component, while working on the drawing.

 

 

Yes if you want to see the separate components then this won't work. I think what you are asking for has evolved/become clearer as the thread has progressed as in the OP it seemed the issue was purely to do with using page based hatches at 1:1 scale + the fact that they then appear too dense, regardless of the zoom level.

[Tom W.]

11 minutes ago, Tom W. said:

22 minutes ago, line-weight said:

But if I have tens of different "material classes" then I think I need to set up tens of data visualisations, one for each class that I want to change the fill of.

 

You should be able to do it with one DV + also save it in user folder for use across all files.

 

eg:

 

 

[line-weight]

4 minutes ago, Tom W. said:

 

eg:

 

 

What DV setup have you used to do this - there is a way of doing it with one DV rather than one for each class?

[Tom W.]

In my case the criteria was 'All Objects' because it was a test file with only two walls in it but even so because my classes are dedicated Wall-Component- classes that should work in all circumstances. Then the Display Criteria was Objects using Function > Classes. Just selected all my Wall-Component- classes + applied the colours. If you use 'material classes' that apply across multiple object types then you will probably want to restrict the criteria to Walls.

[line-weight]

54 minutes ago, Tom W. said:

In my case the criteria was 'All Objects' because it was a test file with only two walls in it but even so because my classes are dedicated Wall-Component- classes that should work in all circumstances. Then the Display Criteria was Objects using Function > Classes. Just selected all my Wall-Component- classes + applied the colours. If you use 'material classes' that apply across multiple object types then you will probably want to restrict the criteria to Walls.

 

Ok, thanks.

 

The "display criteria" bit of data vis always confuses me. So I have a tendency to use "define criteria" to choose the objects I want to do something to and then just stick to "all objects" in the display criteria. Anyway, your description helped me get where I wanted. Screenshot below shows how I have set it up.

 

(NB it's important to to set "retain original texture" so this doesn't get over-ridden in shaded 3d views)

 

 

 

I use "material classes" across multiple objects but I want this to apply to all of them not just walls. This comes into play when I use "edit section in place". This solution appears to work quite well and I will road test it a bit.

 

Here is the before & after of what "edit section in place" looks like.

 

 

 

Much better!

 

Edited February 6 by line-weight

[Tom W.]

There you go!

 

So you should be able to create a master DV that includes every single one of your material classes then save it in your user folder (Manage Data Visualisations > Export...) + easily recover it in any file going forward (note: I have had issues using saved DVs in that they need 'resetting' by editing the criteria before they work - I'm pretty sure I filed a VB on this).

[line-weight]

4 minutes ago, Tom W. said:

There you go!

 

So you should be able to create a master DV that includes every single one of your material classes then save it in your user folder (Manage Data Visualisations > Export...) + easily recover it in any file going forward (note: I have had issues using saved DVs in that they need 'resetting' by editing the criteria before they work - I'm pretty sure I filed a VB on this).

I see I can also just import a data vis from another file, under "manage data visualisations" which is the messier method that I might end up using in practice.

 

DVs don't appear in the resource browser for some reason. Maybe there is a good reason for this, but it feels like they ought to be in there.

[Tom W.]

8 minutes ago, line-weight said:

I see I can also just import a data vis from another file, under "manage data visualisations" which is the messier method that I might end up using in practice.

 

DVs don't appear in the resource browser for some reason. Maybe there is a good reason for this, but it feels like they ought to be in there.

 

See if the same thing happens importing the DV from another file (doesn't work initially until you kick it).

 

I guess a DV comes under the umbrella of preferences rather than being a resource. So the same as all sorts of other saved preferences: Data Manager, Site Models, Dimensions, etc. 

[line-weight]

28 minutes ago, Tom W. said:

See if the same thing happens importing the DV from another file (doesn't work initially until you kick it).

 

I seem to be getting inconsistent results. Got it working in one file, and in another, it won't take effect at all, however much I try editing the DV. Maybe it's me inadvertently doing something wrong somewhere though.

 

Edit - in this case, the imported DV won't work at all. However, when I duplicate that DV, the duplicate version works fine. The originally imported one continues not to work.

 

Edit 2 - renaming the imported one also seems to get it to work.

Edited February 6 by line-weight

[Jeff Prince]

9 hours ago, Benson Shaw said:

@Jeff Prince “turning” ? Please clarify.  Did you mean Off? Toggling? Or???

 

thanks. 
-B

Oops, Off.