line-weight

Another question for @Matt Panzer I think.... is this a bug?

Another version, now with viewports 10 & 11 added. This is the system I am going to use for now I think. I have to accept stacked viewports, and some manual work done in annotation space. I may get around to making this into a proper VE submission at some point...however I've already spent rather a lot of my own time messing with this and now need to get on with the actual drawings that earn me some fees for a bit. I think all the info is here in this thread for anyone who wants to look at what does and doesn't work in HSVPs as far as site models are concerned.

That explains what confused me then!

If assign it to a dedicated class, and "make all attributes by class" then those attributes are carried through into what I see in section.

Does that remain the case if you go the site model's graphic properties and change the pen colour under "2d site border attributes"? So that this is no longer controlled by <site model class>?

Right, of course. Had everything set to "by class" except fill. So as far as I can understand, in a section viewport, for the cut plane through a site model object: - The pen is determined by whatever is set under "2d site border" in the graphic properties of the site model object. - The fill is determined by whatever fill is set in the attributes of the site model object itself - Whether or not "draw site border" is ticked in the 2d display settings of the site model has no effect on these settings - However, unticking "draw site border" stops the pen type chosen for section purposes appearing in plan views of the site model. It doesn't really make sense to me that these two separate things (the outline of the site model in plan, and the outline of the cut plane in section) should share the same attributes and be controlled by the same thing.

Not quite sure what setting you mean here?

I have: (1. temporarily turned off "components" for the site mdoel) 2. Turned off "draw site border" in the site model's settings 3. Set "2d site border" attributed to be <site model class> (as per screenshots below) 4. Put the site model in its own "site model object" class 5. Set the attributes of that "site model object" to have a certain pen and fill But I still get the same: the pen has effect on the section line in my section viewport but the fill colour seems to have no effect (fill simply remains white)

So... the problem with just making a "hole" in a site model using a pad modifier is this: You get a hole with vertical sides: And in a section viewport which uses objects "own attributes" for the cut plane this looks something like this, once a building is placed in that hole: The thick green line is the outline of the cut through the site model. [As an aside - this line's attributes seems to be controlled by "2d site border" in its graphical components settings. Is that what's supposed to happen? And I can't work out what controls its fill] Those vertical sides can't have any kind of undercut, so if you have something like this strip foundation, there is this kind of problem where the green line crosses the foundation: If I could simply tell the site model to draw the surface of the ground but nothing for the sides & bottoms of these holes, then this issue would go away - but I don't think that's possible - there doesn't seem to be an individual setting that controls these elements. I was curious to see what happens if I use "components" in the site model. If I use two (each determined by a dedicated class) then this happens. I am using a green upper layer and a brown lower one. I noticed that the sides & bottom of the hole seem to take the attributes of that lower layer, so I wondered what would happen if I turned off the class that determines the attributes of that lower layer, and it is this: Here is what I now get in section: The unwanted bottom & sides have disappeared and I get a kind of shell surface to the terrain (I can adjust the thickness of this). I can then go ahead and use a 2d polygon in annotations to "fill in" the ground. It would be nice not to have to do this, but it at least works, and I can always "live check" & adjust the ground line if there are changes to the site model. As can be seen in the screenshots, this change to the "components" approach causes various types of mayhem with mesh triangles appearing where they weren't before (including in top/HSVP views), but my next step is to understand what's controlling that exactly.

@Matt Panzer ok - taking a closer look I see what you mean - so sadly it's rather further away from providing what I want, than I thought. It also makes me realise that what I thought was a usable workaround has some issues. Attached is a revised version of the file where I've added "viewport 8" which shows basically how my (best current effort) workaround works. From your comments above it sounds like it's not going to be easy to make site models compatible with HSVP workflows, if the strategy is to use the 2d component of the site model. I don't know if there are any ways in which something using the site model's "3d contours" could be made to work. For example, if in my example, I was just able to tell the viewport to show the 3d contours in a different pen, that would get me 80% of the way towards what I want, and would provide something acceptable "for now". VB site model v2.vwx

If section vports could just be told to always draw site model cut plane polygons "behind" all other cut plane geometry....most of these issues would go away.

They can't (as far as I know) do any kind of undercut so it doesn't work for foundations that step outwards below ground level.

Likewise - which is why I'd like to be able to show just a surface line, taken directly from the site model, in my section vports and then use this line as a guide/check when drawing in the 2d fill. That's why I was interested in the idea if a site model that would just be a kind of surface shell, with holes in where necessary for buildings to sit. Unfortunately I still can't find a way to achieve that.

Yeah sorry my remark doesn't actually make sense. In fact the way I tend to do it at present is by drawing the ground fill as a 2d polygon in annotations. For me this feels less fiddly than stacking viewports. And it has the advantage that it can block out any linework that would be hidden by the "ground". There is often some slightly messy linework visible through the floor void, which ideally I'd not have there (because it doesn't really aid in understanding the drawings) but can live with. I tend to make that linework grey too.

It's easier to ignore the linework beyond cut plane when it's not a suspended floor with void under!

Have been revisiting this old and perpetually unresolved issue once again: I've been fiddling with "components" in site models which is something that has appeared since I last looked at it in any depth. Seems to have potential to generate a kind of shell surface. Thought maybe making a recessed pad would result in a shell surface with holes in it but it doesn't. I will probably post in a bit more detail after further investigation.

Oh well.

Further sources of confusion: inconsistent naming - Decide what these site modifiers are called and stick to it. Is it a "pad with retaining edge" or is it a "retaining edge"? The confusion is compounded by the existence of the "retaining wall" site modifier which is something else again and is created in a different way. This is the kind of stuff that badly needs to be sorted out in a general review of user interfaces throughout the programme.

Glad I'm not the only one finding this tool frustrating. What I've written below results from reading this thread, trial and error, and quite a lot of cursing. The first key thing: Do not update the site model prior to doing the "send to surface" command! Because if you update the model first, it'll create a big mess with sloped edges, and then when you "send to surface" it will send the relevant polygon to the already-modified surface, which is almost certainly what you do not want. Another thing When you first draw the modifier, and view it in 3d, it looks like there's just a single polygon, sitting at whatever elevation you'd specified for the pad elevation. But in reality there are two polygons superimposed: one outlines the pad itself, and the other represents the top/bottom of the vertical wall that's going to extend upwards or downwards from the pad edges. This only becomes apparent if you activate the reshape tool and try moving the vertices. I don't know why the tool is designed like this - why would you choose this tool (which is specifically to make pads with vertical edges) if you didn't want any vertical edge? Because if the two polygons are identical that's what you are going to get: a pad with no vertical edges. Why is that second edge not sent to the terrain surface by default? Isn't that what 99% of users are likely to want if they are using this? Alternatively, have them offset by some default dimension (perhaps one that can be set numerically in the toolbar/OIP). Even if that dimension is not what the user wants, it at least would provide some visual clue of what's going on. Also - even once they are not superimposed, give us some visual clue about what each polygon is, that doesn't require the reshape tool to be activated! In most cases, I won't want to manually adjust them - I will simply want to send to surface. Here's what I get at first, after creating a new "pad with retaining edge" modifier at arbitrary elevation: Here's what I get if I change the pad elevation to something closer to what I want: At this stage the upper polygon is a mystery to me - no clue about what it represents, no numerical control in the OIP. That's why most people are probably tempted to press "update site model" at this stage and if they do they get this: Which is almost certainly not what they wanted. Instead you have to first go for "send to surface (fit the retaining edge)" and this is the first point at which anything seems to make any sense: And it's only now that it's safe to update the site model:

As far as making holes in site models is concerned....has anything changed since this thread was active?

Thanks for the explanations @Matt Panzer. Before submitting a VE request I think I'd like to clarify what things are actually bugs - because actually maybe it can already do what I want it to, if the bug(s) are fixed. See attached file and screenshots. - In viewports 4 & 5 it seems to know the "tree trunks" should be visible above the site model, but not the curved steps...why's that? - In viewports 6 & 7 it fails to draw the portion of the "tree trunks" between the cut plane & ground surface. Is that a bug? VB site model.vwx

@Matt Panzer, the behaviour where it only shows the 2d component if not intersected by the cut plane, is this intended rather than a bug? I don't really see in what scenario this would be useful.

If I open the file (and update the viewport) I don't get quite the same result - I can see the mirror but it does not have the hatch fill that it should have. Exploding/ungrouping the symbol it's part of fixed it. I also tried changing it from an extrude to a generic solid - and this caused it to disappear altogether in the section view (it was still present in 3d). It's part of a "flipped symbol" and occasionally I find odd things happen with flipped symbols so maybe that's relevant?

One of the issues there would be that the HSVPs would not cover the site model contours (this would be less of a problem if they could accept solid fill, hence my earlier question). There's a whole other thing about 3d objects that intersect the site model at non vertical angles. Vectorworks knows where they intersect the site model surface because it can show me in shaded view. But getting this to show as I want it when using stacked viewports gets complicated. Think of a non vertical tree trunk, represented by a cylinder. In my ideal world I'd like my plan to show the trunk above the surface (in elevation), I'd like to see the line where the trunk intersects the surface, and I don't want to see any of the trunk that is below the surface. And if my cut plane is intersects the trunk I want to see that too. Using my normal setup, all of this is easily achieved if the ground surface is modelled as, say, a generic solid. But if it's a site model object, it's not.