line-weight

Yes sure - just drop me a message.

In the iPad app (viewing a VGX model): - clear glass is transparent, but appears to cast shadows. So I can have either (a) directional light & shadows on the exterior of the building but only ambient light inside or (b) directional light on the outside & inside but without any shadows - another glass texture (reeded/obscured glass)I have set up as semi transparent to look as I want it in shaded view in Vextorworks shows as completely opaque (as far as I can tell) in the ipad app Are these things working as expected/intended? The addition of ambient occlusion is welcome; makes interiors look a little less flat/featureless although I'd still like the ability to turn edges on.

Trying Nomad in the wild today (for a client presentation) after not touching it for some time. First problem - I have to remind myself what the process is for exporting the model so I can get at it on my ipad. So I go to here: https://cloud.vectorworks.net/portal/help/pages/generate-3d-models-from-vwx-files/?app=VECTORWORKS and it tells me But in VW2021 under File > Export I see no option for "Export VGX". Am I just going blind/crazy? (in the end I managed to get it exported via the cloud services desktop app instead)

Suspending snapping doesn't make any difference for me unfortunately. Tried in vw2021 and vw2022. When I view the sheet layer, with snapping activated, I can mouse over the wireframe views without any issue - the cursor will pick up lots of snap points but can move around smoothly. The problems come when I try to zoom or pan. This is when everything seizes up. It makes no difference whether snapping is suspended or not.

When you want a cavity over the whole building height (for air flow as you say) you use cavity barriers that have an intumescent treatment, so that in normal use they let air pass, but if there's a fire they expand to fully block the cavity. On your last question about whether buildings over a certain height should have a strict non flammable facade, this really is the big issue raised by the Grenfell disaster here in the UK. I think most people would agree that the answer is "yes". The question of how the Grenfell tower ended up with the entire facade burning has been the subject of the long and detailed enquiry that is just about concluded now. It came about because of multiple failures... at almost every stage of the process including the certification and testing of products, the wording of building regulations, the specification process, the design process, the construction process, the building regulations inspection process, the risk assessment process, the building management & evacuation strategy and the emergency services response. It really is a horror show. I agree with what Christiaan says, that including fire barriers in a 3D model would make it easier to visualise what's proposed and therefore more easily spot mistakes and problems. It might not have prevented Grenfell because there were so many other things that went wrong - but perhaps it could have reduced the scale of what happened.

For windows and other wall openings I would prefer that the basic concept involved a "wall opening" entity that purely set the location and size of the opening. (In an ideal world it could be applied to several wall objects so that I could have the opening pass through them all if I had them stacked in layers) Then, I could associate a window object, or window style, with that opening, and I could independently associate a sill type, lintel type, closure arrangement and cavity closer type. This as @Christiaan points out elsewhere would more closely match the way buildings are actually designed and constructed. You might have a standard window type across a building but installed into different wall buildups in different locations. The wall buildup might be different on the inside but not the outside, or vice versa, or both. And so on.

Agree with all of this entirely.

There's not only the confusion between cavity closer & cavity barrier, but between cavity barrier and fire stop (and I often have to look it up to remind myself which way around they are). All of these things could do with better names.

You're right that ideally it would be dealt with as part of wall closures (along with window or door insertions) though. But are cavity closers a bit of a UK peculiarity - because masonry cavity walls are very common in the UK (& some other NW european countries?) but not elsewhere? In which case we might not see much time invested in such a feature by a north american software company.

A cavity closer is a different thing to a cavity barrier of course.

Any reason not to use simple vertical extrudes? Or is the problem then how they interact with wall objects when seen in section? How do you use slabs for the horizontal ones - do you somehow wrap certain wall components around them? If a tool were to be developed for this I'd suggest considering a general-purpose "elevation embelishment" tool that could deal with different kinds of linear elements within/on an elevation, so that it could also be used for things like edging trims, or maybe even rainwater goods. (Really I'd prefer all the other tools to be fixed before developing an inevitably half-completed and ten abandoned new one though)

I think I'd definitely spend the money on extra RAM (and perhaps also HD size) rather than the better processor, as far as VW is concerned. My impression is that VW currently barely takes any advantage of the extra processing power except for RW renders. It's the memory that slows things down. On big files my M1 mini is pretty much constantly using as much of the 16GB RAM as it can get its hands on, and then frequently using 20 or 30GB of swap memory.

By the way something I don't understand about the memory figures in Activity Monitor... If I add up the memory usage of all the apps it comes to >48GB But if I add "memory used" + "cached files" + "swap used" I only get about 32GB. Why don't they match up?

Well I just spent a bit of time doing my favourite procastination/avoiding real work activity: unpaid beta testing for VW. I've compared VW2021 SP5 with VW2022 SP4 (as part of my decision making process about whether I dare move to using VW2022). This is using quite a large file and it's on my mac mini M1 16GB running monterey 12.2. The numbers are gb of memory use by VW according to Activity Monitor. Note that 2022 seems to behave better, memory wise, up until step 7. However, once I untick "save VP cache" in document preferences everything starts to go wrong. I have several sheet layers in this file which contain a large number (eg 44) of renderworks viewports. Where these have been rendered out in a previous session, and the completed render images are retained in the file thanks to "save VP cache" being ticked, then VW2022 can deal with that sheet layer. It doesn't use loads of memory, and I can pan and zoom about it reasonably well. But once I've unticked that box, and reopen the file, all of those VPs are shown with a wireframe view of the model, because the rendered images haven't been cached. This causes issues in VW2021 and VW2022 - a much larger amount of memory is used, and panning/zooming around that sheet layer becomes very slow indeed. But it's worse in VW2022 than in VW2021. And when I want to switch to another, similar sheet layer, then VW2021 can cope with this but VW2022 can't. What this means for me, at least with this file, is that I potentially can't operate using VW2022 because as far as I can see, there may be certain sheet layers that I simply can't access. I potentially can't even get at those sheet layers to reduce the number of viewports to a level that VW2022 can deal with. Maybe by keeping "save VP cache" ticked, I can render a sheet layer, save and close the file, reopen it, move to another sheet layer, but that's very laborious especially if it's necessary each time I change something. Or maybe if I left things running with memory at 56gb and beachballs spinning for long enough it would eventually settle, but I suspect not. I'd be interested if anyone else can replicate the same thing. My guess is that you can, if you just increase the number of VPs on a sheet layer to some threshold amount.

So frustrating that it's not possible to add memory to the M1 minis.

You're more likely to get help if you do as much work as you can yourself. So, provide a vectorworks file for us to look at, with the DWG already imported. Anyway, I imported the DWG into a VWX file. Looks to me like the spot heights for the general groud level are labelled "NS" in pink along with a height value (eg 13.15). There is a crosshair symbol superimposed on a 3d locus for each. Examining the 3d locus suggests its X, Y and Z values are correct (but you will need to tweak import settings to make sure the units match what you want). So it looks like it's these 3d loci you want to extract to make your site model. Your surveyor seems to have provided a reasonably well organised drawing (not always the case!) and those 3d loci seem to be in the class "NS". So it's quite easy to extract them all using the "custom selection" tool using these criteria: Use this to select those 33 3d loci, and follow the good advice from @jeff princeabove - get them into a new layer. And ignore the contour lines drawn on the survey. Then you can use them to create the basis of your site model. It'll be up to you to interpret the other height data on the survey, some of which relate to building heights. Some of it might be useful measurements of local ground level adjacent to buildings ... quite how you integrate building models with a site model is less straightforward (and in my opinion not well catered for in Vectorworks). You'll need to do a fair bit of homework to understand what the best approach is for you. It'll depend what you need to use the models/drawings for.

Does SP4 continue to have the problem of memory usage gradually creeping up and up and up the longer the file is open? (I've only done a bit of testing so far, haven't tried to spend a day working in it)

Again no improvement, as far as I can see, in SP4. @jblock or @Dave Donley are you willing to give us any update on this?

I've also repeated this test in VW2022 SP4. Things are perhaps a little better - such that VW2022 behaves not significantly worse than VW2021. Navigating a large sheet layer with multiple viewports remains painfully slow.

I've just repeated these tests on VW2022 SP4 (again on my 16GB M1 mini) and am sad to say that I see no improvement.

I'd be interested to know if anyone has seen any improvement with SP4 now released. My initial testing suggests: not really.

Yes please! Worth putting the explanatory video in this thread too:

That detailer tool looks incredibly useful. Why don't we have it already!

I don't understand what the second image is showing - what are the blue boxes? As for the first one, the "successful" viewport on the left, I'd just duplicate that, then adjust the crop on the duplicate so it only takes in the bottom part of your worksheet, this will give you a viewport that's not in the location you want but you can then just move this alongside the other one. I use this approach quite often - it's a pain to have to do it, and there ought to be a better way, and people have asked for this for some time, but with no success.

Ah yes, of course - true.