Inconsistent Section Representation

All the mouldings in my drawing are set to display solid fills where clipped in section. But a couple of these do not display that way in a VaSection. The below image shows the problem mouldings in the section below. I will upload the file to my dropbox and it will be identified by file folder and name.

Hi Djhg, these mouldings are open polysurfaces and for that reason they are not filled properly in section views. Make sure they are closed solids and then assign the section attributes. Finally update the section views to see them with the solid fills.

1 Like

Ah. Okay.

Strangely, every moulding in that project (there a lot of them) is an open polysurface, but only those particular casings don’t display the solid correctly.

Francesc, I am having trouble now with the plan representation displaying the section fills properly for these mouldings. Can the closed polysurfaces be intersecting/overlapping and still fill properly in VaPlanViews? I can’t get mine to do that. Any of my recent uploaded models should have mouldings if you need a sample project to help me troubleshoot.

I’m confused about when fills will show in section and when they won’t. But I did figure out a fix.

Open polysurfaces will sometimes correctly show fills in section.

Also, a closed polysurface may not fill when clipped in section: In the case below, the blue moulding is a closed polysurface but wouldn’t fill until I adjusted the project tolerance from .003’ to .0025’. I see that there’s a tolerance adjustment available in Properties>VaView. Please let me know if that’s a better place to make the tolerance adjustments.

When I had performed Boolean Slpit operations involving the blue mouldings, a requester popped up and I had to approve the adjustment of the project tolerance in order to perform the split. I don’t know if it was adjusted only for that operation, or for the entire project from that point on, but it clued me in to adjust the tolerance to solve the fill problem.

The ortho view below is of a Va Plan View. It’s worth mentioning that the Va Section Views of this area appear to respond differently to the tolerance adjustment than the Va Plan Views do. .0025 was the only adjustment I tried which filled both the orange and blue mouldings in both VaPlan and VaSection. Other tolerances caused one object or the other not to fill in one or both VaViews.

I have sent a link to the file.

That’s not possible. I’d like to see some case where open polysurfaces show fills if you have found one.

Plan/Section view Tolerance matters when it comes to calculate these drawings more precisely. And as you have found out this precision may make a complex contour be detected as an open or closed curve and therefore show or not the fills. Changing this Tolerance factor by object (plan or section view) or by Document Properties has the same effect on the 2D drawings, although in the second case this change will only affect these objects and not the geometry in whole document.

I think it’s happening in my project. Take a look at section C-C on the following file in my dropbox: InconsistentFillOnMouldingSections.3dm
The filled section of the baseboard is indeed of an open polysurface. That’s great, but it isn’t reliable behaviour in Va. It would be good if it were.

This may be worth attending to.

The effort required to close all intersecting mouldings is considerable (see Trimming/patching/surfacing operations with intersecting/aligned polysurfaces/solids), but “Section Tools” by Rajaa Issa (of McNeel) will relaiably close any continuously-boundaried section through an open polysurface. (see this message between us, if you can- Maybe you and Rajaa should get together.

You are right. That baseboard of your file is an open polysurface that shows up with a section fill in section view, when it shouldn’t. I think this happens due to the document unit tolerance, that reads that object as closed in terms of generating the 2D drawing when it isn’t. We will take a look.
(I cannot open your message with Rajaa)

@djhg I let you know this has been fixed in VisualARQ 2.5, which is already available to download: VisualARQ 2 - Version 2.5 released

In my case that was a feature, but I suppose for many it could cause trouble.