line-weight

I've become completely baffled in very similar scenarios in the past. And have only managed to fix by making the heliodons anew. This seems to confirm that I'm not imagining it, there's something up with them and I always treat them with caution. Have also had problems where things like brightness settings get all messed up.

I find heliodons to be generally a bit buggy. For example, potentially they don't like being duplicated, renamed or having their class changed. For one of your problem viewports, try creating a new Heliodon, already in the class you want it to be in, and see if that makes any difference.

The more I try and use Viewport Styles, the more I am convinced that we need something like this to make them fully useful.

The answer on this is that, yes, behaviour is different in proposed vs existing "phases" of site models. It is not considered a bug and so will remain like this for now but consistent behaviour will be considered as an enhancement.

Yes I see. I also never use the "bearing height". It's something to do with how roofs meet walls? It would perhaps be interesting to know most people actually use roof face objects and also how they approach the setting-out of roof heights when it comes to construction drawings.

The datum is effectively a plane within the roof buildup. Say I have my datum set at bottom of joists but I want to change it to top of joists. The joists are 150mm deep, so I just want VW to offset that plane by 150mm but keep the roof object in the same place. The reason I might want to do that is top keep the top-of-joists on the same plane and then increase or decrease the joist depth. With something similar to what you can do with walls, I'd just ask for the old version of the roof face to be replaced with the new one such that the tops of the joists stay in the same place. That operation could be done without changing the datum within the roof object of course but it would be useful if I could then also move the datum within the object, because maybe I've decided that from now onwards that's where it's most useful to have the point of reference. This is true yes - the diagrams look similar but they are showing different things. It might be helpful if they didn't look so similar.

Ok, thanks. That's basically what I have done. It would be good if roof face styles could be replaced/edited with the same level of control as is possible for walls. Looks like the same applies to slabs.

I want to redefine where the datum is within a roof face, but I want the roof face to remain exactly where it is. So, previously the datum was on the bottom surface of the ceiling, but I want it to be in between two internal layers. The dialogue above initially looks a bit like the one you get when you replace or edit a wall style, which gives you a lot of options of what component to align in the old wall, with what component in the new wall. But actually it doesn't give you any of those options. When I click OK, the red line will stay in the same place in the model, and then the roof face will shift relative to it. So my ceiling will drop. Am I right to think, there's not a way to do what I want? I want to redefine the red datum line from where it is in the left hand diagram, to where it is in the right hand one. But I want my ceiling to stay exactly where it is.

As mentioned further up the thread, this discrepancy surely can't be intentional & I've filed a bug on it. The question is, which version of the behaviour is the one that's intended? If it's that the grade limits are required for pseudo-vertical edges, this business of offsetting something by a tiny amount seems a horrible workflow to me, and suggests that the pad with retaining edges modifier is the one we are supposed to be using. If it's that the grade limits aren't supposed to be required, then how would one make a level pad with sloping rather than vertical edges? The way I think I'd want the tool to work would be: if it is not surrounded by grade limits, then the edges are (truly) vertical, and if it is surrounded by grade limits, then sloping edges are formed.

and that's one benefit of using classes over layers - much easier to change the attributes of everything in a class than everything on a layer.

Does the newer "GIS stake" tool help at all? (Haven't tested myself)

When I used to draw in 2d, one of the main purposes of classes was to control & keep line types consistent. I'd have a thick line for section cuts, thin for elevational lines, dotted for above, etc etc. Each would have its own class and each would also have a colour to make them easily visible on screen (rather than relying on zooming line thickness). If only using layers, would you just do all this manually? So each time you want to change the type of line you are drawing, you have to go to the attributes and set it all to what you want, rather than just choosing the class? That sounds rather cumbersome to me.

Assume you mean that you'd place it in the annotation space of a sheet layer viewport? (Beware this thread is nearly 20 years old!)

Either way it doesn't seem right that the behaviour is different according to whether it's applied to an existing or proposed version of the site model object.

Ok. Thank you. For now I'll report the different behaviour when applied to existing vs proposed versions of a site model as a bug.

I might report it as a bug. Can you clarify what you meant when you mentioned ticking the "vertical sides" box - is it the one in my screenshots above? Would you agree this actually is not really relevant in this case? Another thing to clarify - the method you describe applies when configuration = planar pad - is that right? If I make configuration = retaining edge, then it seems like I have to follow the more complicated method (involving sending to surface and son on). But I seem to end up with the same result. So what's the purpose of "retaining edge"? Does it actually do something different, or is it effectively superceded by "planar pad"?

Hm - if I apply it to the Proposed model, then yes it does have vertical sides. And it doesn't seem to make any difference whether I have that vertical sides box ticked. As you say, the setting suggests it only applies to inner modifiers but it's the only "vertical sides" tickbox I could see that fitted with @Jeff Prince's description.

Here is what I'm doing: 1. draw rectangle 2. right click, "create objects from shapes", choose site modifier 3. I'm presented with this dialogue: 4. I've ticked the "vertical sides" box 5. Under "configuration" I choose "planar pad" (is that right?) 6. I click ok and I get this: 7. I update the site model and I get this, which isn't giving me vertical sides: What am I doing wrong? I get the same result if I choose "retaining edge" under the "configuration" options. This is using VW2025 update 3.1.

Can you explain which tool exactly? Is this something that's in Landmark only?

I've tried to replicate. I don't think what you're getting in the viewport has the clip cube applied. It's just that it looks exactly the same as it would, because the object happens to be symmetrical about the "cut plane". Try switching to a front or back view and I think you'll find it's showing you the whole object. Or add some extra geometry to the half of the object that's clipped out by the clip cube. I think you'll find it appears in your viewport because it's just showing you a wireframe elevation of the whole thing.

Not sure what you mean here - either you have a job specific copy or you don't - the yes/no about updating the database will apply to whatever database you are using in that file. In any case, if you select "no" then it means that any other instances of that note in the same VW file won't update - and doesn't that kind of defeat the purpose of using the database? (By the way I find the whole setup much more precarious than I'd like, even when I am using it carefully - there's a whole other issue about keeping backups of the database that are in sync with backups of the drawing file. Once you accidentally mess something up in the notes database - which is very easy to do - it can be very tedious to undo it all or revert to a previous state.)

Ok, now I understand what you want. When you said "create a viewport from clipcube" it was not clear whether you were talking about one way you can make section viewports, which is to make a clipcube and then choose one of its faces to generate a conventional section viewport. But you simply want to be able to view a clip-cubed wireframe in a viewport, like you can in a design layer. So something like this in principle - I can see why it would be frustrating that it's possible in a design layer but for some reason not in a viewport.

To some extent that's me too. Mostly it's shaded and hidden line or sometimes hand drawn too. For the most part "photorealistic" renderings aren't something I feel the need to do and I feel can even be counterproductive. Possibly for similar reasons as you. I do however use renderworks a bit for what you might call partly abstracted renderings. For example what I think of as white card models. It's for that stuff, that being able to do what I can do in renderworks but much more quickly, would be very welcome.

As a matter of interest, which parts of Europe? (In the UK, it feels like we are decades away from that being vaguely realistic)

I wouldn't write off the notion that an awful lot of architects still use VW as a primarily 2D application. I certainly know practices (small to medium size) who still do. I was able to transition from 2d to 3d some years ago because I'm a sole practitioner. That was painful enough - and I didn't have to work out how to change the workflow of an entire office with multiple overlapping projects. When I talk about a 3d workflow I mean, as a minimum, that elevations and sections (say up to a scale of 1:50 or so) are generated from a 3d model rather than drawn in 2d. Never mind formally BIM compliant models. Going to the OP's point - yeah I wish we could have an efficient, fast renderer within VW. Having to import and export from external applications is a massive point of friction. We were told we were getting "live links" but they don't work.