Consistent Scale of Hatch in Layout Space

Can the displayed hatch pattern for sectioned elements in VaPlanViews and VaSectionViews be kept consistent regardless of the scale of a detail view in layout space? (Similar to the way text scales can be the same in all views in a layout regardless of scale.)

Hi David,

Unfortunately that is not possible. Plan View and Section View object are like a snapshot of how it looks the model. All objects (including hatches are converted to lines (edges, silhouettes, etc), and then VisualARQ computes the visible/occluded parts of each lines. So once a plan/section view is computed, there are no hatches, just lines.

What don’t you use realtime plan and view viewports?

Regards,

Enric

  1. clipping planes can’t jog, Va section lines can.
  2. there have been a host of bugs in line display in all display modes but wireframe when plotting from 3d objects.
  3. Dimensioning to blocks (which all Va objects are) has led to corrupting dimensions in the past.
    Those are the main reasons, but also:
  4. Make2D generates a complicated layer structure; VaViews remain true to the model.

Rhino clipping planes does not support jogged sectuons, but VisualARQ sections does. You use the sections manager to enable a section on a viewport, even with jogs.

We’re constantly improving the hidden vector output. If you see any error, let us know and we’ll try to fix it. Remember to use the “Hidden” display mode.

I don’t know what are you referreing to. What is not currently working are associative dimensions, but they doesn’t work with Plan or Section Views neither.

I’m not telling you to use Make2D. I recommend you to use realtime sections, as they don’t need to generate the curves.

Enric

Planviews > Realtime Plan:

  • Quality of linework
  • Ease of export for dwg and other formats
  • Annotation(Especially in cases where it’s on top of furniture or outside of the building envelope but is only supposed to be visible in one view)
  • Cleanup or addition of lines (Using a white hatch)
  • Hatches are kept as hatches(This is incredibly important, especially with section views where the hatches end up all over the place and are not aligned to the construction elements, the ability to explode the view into curves and hatches is essential for creating a good section imo)
  • Creating dimensions that will always be visible above the plan itself
  • The promise of “what you see is what you get” is much stronger with the 2D Views. I don’t really trust the realtime export for more than the initial exports.

There are a few more, but for me personally that’s the main ones I think.

Hi @rheinason,

I agree that there are still some advantages with Plan and Section Views over Realtime Viewports and Details. But our plan is to continue improving (aka fixing) these differences, as Plan Views and Section Views are obsolete. We’ll probably remove them in a future VisualARQ release, and they will be replaced with some commands to export Realtime Viewports and Details to DWG, and probably some kind of non-updatable Make2d-like command to get curves.

The reason is that Plan and Section Views objects has some features that cannot be implemented (like support for solid hatches, texts, etc) and they are slow.

Moreover, one of the more important problems with Plan and Section Views are that they make the model slow, as they require a lot of geometry in the model. We want users to start using realtime views, and let us know all problems they find, so we can fix them until there are no reason to use the old Plan and Section Views.

The idea is to put 3D geometry in the model views, and do all plan/sections using details in layouts. Realtime plans and details viewport are meant to be used for working, not for printing.

Some of the things you mention do work with Realtime details, like dimensions or using solid white hatches to hide a line. Just create a detail with the plan/section you want, and put dimensions or hatches in the layout (not inside the detail).

Enric

1 Like

@enric

The plan and section views are helpful in many ways because they are distinct from the model. They form a kind of middle ground between the model and the layout which allows you to overlay additional notes, information, etc that does not clutter the model but is able to float and be selected independently of layouts. I am also able to control the plan style using Layer States with selected layers turned off or colors changed by restoring the Layer State and then updating the plan or section view. This is useful in cases like a site plan or floor plan showing different information from the same level or an elevation not needing all the extra linework that would show up on the floor plan.

In addition, the model linework and the annotation together form a complete drawing. Its not intuitive or flexible to split them up into two separate parts of rhino.

Please do not phase out the plan and section views yet. They are a really helpful part of the workflow.

That’s exaclty the goal of realtime viewport/details, to not clutter the model with lines/annotations/notes.

IMHO, in a perfect BIM application, model views should only contain 3D geometry, and layouts should contain details (that show the 3D model in a specific form, like plan, section, etc), and extra geometry to annotate (dimension, notes, extra lines, etc). This extra geometry lies in the layout, so it is not inside the detail/model.

We won’t remove Plan View and Section View until Realtime viewport cover all required features by users, but we won’t improve Plan View and Section views.

Enric

1 Like

One idea we had some time ago is that all 2D geometry (lines/dimensions/text/etc) created in a realtime plan/section viewport/detail will be automatically attached to that specific view, and it will only be shown in this viewport/detail. So, you can create model 2D geometry, using standard Rhino commands, but it will be only visible in the viewport you used to create it.

Another idea is let the user pick a visible line on a realtime plan/section viewport/detail, and specify that this line is hidden (for this particular viewport or for all).

Enric

I find that dimensions snapped to blocks in 3d space have a history of unreliability in Rhino which doesn’t exist with 2d geometry.
Mcneels’s recognition of this issue isn’t reliable either, with techs agreeing there’s an issue and planning to investigate without follow up and months later questioning whether there’s an issue at all.
See Lowell’s initial response vs Pascal’s response 8 month’s later:


And the absence of follow-up here:

I don’t think it’s a priority at McNeel.
Without reliable dimensions in 3d space, using it for construction drawings is impossible.
My opinion is that McNeel’s orientation is to reinforce it for the creation of nurbs models to be exported into construction drawings in other CAD packages, which makes annotation issues like dimensioning a low priority.

FWIW, the follow-up happened in plain view on YouTrack and that bug was fixed:
https://mcneel.myjetbrains.com/youtrack/issue/RH-47897

Sure, ideally everything is linked from Discourse - I’ll try harder…

Thanks Wim. Often an issue necessitates elaborate work-arounds and in some cases the discarding of entire modes of working like using 3d modes for construction documentation as is the case on this string. There are so many such situations in a Va-Rhino workflow it’s really hard to know their status if the forum post doesn’t identify progress through development.

This one is the reason I don’t use 3d views for documentation. It was identified by Va as a recognized concern last june as an apparrent (at that time) rhino issue with dimensioning blocks in 3d space; and nothing’s been further reported on this. This is why I continue to struggle through using 2d generated views, and am concerned that nothing is being done to develop 2d views with which I discover some basic obstructions to standard drawing practice. (VaSectionView Clipped Plane Outline Weight Control)

Hi Enric

Thank you for your response. While I agree that there are a fair few nice advantages of having a single 3D model in the model view, the reality is often that there is a distinct need for different line weights, colors, visibility and so on. Even for us doing mostly single family homes it’s proving difficult to get all the drawings out of just a 3D model. Walls need hatches and shadows(a whole other discussion on the problems with Rhino’s shadow mapping and the level of “Peter Panning” there is). Sometimes plans need a solid black hatch, sometimes they need an bold outline, sometimes they need more detail and sometimes they need less. It would be great to hear your thoughts on that and how you see this system coming into action in VisualARQ. A few examples of drawings we do where we mix the 2D plan/section and 2D work on top:

  • Reflected Ceiling plans: The plan view get’s exploded here because we prefer it without a solid hatch
  • Sewage Plans: We hide all movable furniture from the 3D view, make the plan view and then annotate the sewage on top of the 2D Plan view.
  • Elevations: Often we end up exploding this, but otherwise we do silhouette curves, add hatches(I just find this to be a pain to do on the 3D model, especially because the generated CPlane and the wall are often a bit far from each other), draw shadows ( I prefer do draw these so that I can keep the entire drawing vector)
  • Detailed Section views: This is a topic onto itself, at the moment VisualARQ lacks most of the tools necessary for this drawing (Discussion: Keeping two different detail level models linked?) among them: Aligned hatches, slab-wall joints, wall-roof joints, getting a cut silhouette would be great. A workaround would be to do the hatches in 2D on on top of the layout, but this would be a pain when working with external collaborators.

Also, 2D views are a way to hack the Plan Visibility problem, by moving the window up/down to the cutting plane, making the 2D view and then placing it correctly again.

I guess what I’m saying is that one of the main reasons we chose VisualARQ was the level of control we had over our 2D drawings

Wouldn’t the easiest way of supporting this just be to copy it to the 2D plan? Hatches, texts and so on are already 2D? Just copy these elements from one reference point to another? Though this might be difficult when 3D elements are on top of these 2D elements and occlude them.

I also wanted to ask about this:

This sort of makes Franscesc’s comment here a bit confusing:

Hi @rheinason,

Have you tried to use realtime plan/section details in layouts and then place additional linework in the layout space (outside the detail)? This is how many modern BIM applications work, and is the main idea of model/layout separation.

Regards,

Enric

I have done that mostly for early prints of a project and it works well, but the line quality is a bit hit and miss, often with multiple lines on top of each other and sometimes an issue or two with line thickness? I don’t really know if that was because of the way a particular file was setup or not. In general I’m all for this methodology, as long as the quality of drawings can be kept to the same standard as the 2D plan view or better. I must also admit that I find placing additional line work on the layouts to be a bit uncomfortable, where there’s now two places to look for a particular line or detail, but that’s probably just a matter of getting used to the new way.

Roi, you could manage this by layer visibility per detail viewoport in page layout.

This is working with Section View styles, but not with Plan View styles. It should work in both.