line-weight

I agree this would be useful. But don't forget that for frequently-used layer/class visibility switches, you can use saved views, and once set up, achieve the change with a single double-click on the saved views list.

There are certain aspects of those details that I'd agree shouldn't be expected to be created by an automatic wall-wrapping function - but there are others that I would say should be. It'll always be somewhat diagrammatic but the closer the diagram is to reality, the clearer the drawings and the less potential for them to be misunderstood. Vectorworks doors not showing door stops is a good example of a level of detail that really needs to be there at least at a diagrammatic level, but isn't.

Thanks. I imagine it must be very complicated to work out the best way to control all these multiple variables and you have my sympathies/admiration if you were one of the people who has had to try and programme this!

My first challenge to this feature would be to see how accurately it could represent either of, for example, these quite conventional jamb details: The thing is that it's maybe a bit academic whilst the window tool itself remains so embarrassingly primitive. Maybe the Windoor tool will mean that we can start to draw stuff that looks even half convincing at say 1:50 scale?

Does it still create an object made out of a load of surfaces rather than solids? So still looks horrible in section and can't easily be converted to generic solids for customisation?

I'm not sure if 8 can be considered done without testing it for real (maybe you have). When the datasmith export to Twinmotion came out a while ago, it turned out that it had various bugs that made it unusable (for me at least). It's great now to have a direct link, as long as it actually works, and I'm not going to assume anything actually works until it's been tested out by users.

I've been using Vectorworks for nearly 20 years, and using it "properly" in 3d for maybe 3 years ... and all the above is true for me too. I try and tell myself that it would be the same using any other software ...

Hello @Dave Donley It's good to see that VW2022 has a direct link to Twinmotion, which will make it a lot more useful. Are you able to update us on whether the various bugs have been fixed in VW2022?

Can the closure/wrappings be defined by object style as well as by wall style - or is it individually set per object instance?

Some quick experiments done on the same file in each version of VW. Mac mini M1 16GB like @zoomer also has. VW2021 // VW2022 Open Vectorworks 40 seconds // 18 seconds Update several viewports, mixture of hidden line & OpenGL/shaded: 18 seconds // 13 seconds Open large file (1.17GB) into sheet layer view: 22 seconds // 28 seconds Then go from sheet layer to openGL/shaded 3d view of design layers, by activating a saved view: 10 seconds // 22 seconds: Update renderworks viewport 2m31 // 1m50 (according to VW progress bar) 2m50 // 2m13 (according to my stopwatch since pressing update button) NB some things there where VW2022 is faster, but also some where it's slower! Haven't tried it in 'real world' use at all yet so can't really comment on whether it "feels" faster or not.

In VW2021 it was sometimes happening for me on a quite big model that is about 0.5km x 0.5km in size but in VW2022 it's happening on much smaller models too.

Are you viewing in perspective, or orthogonal mode? It seems that it may be an issue when viewing in perspective (which is what I always use when in 3d) but not in orthogonal (which seems to be how a lot of people work but I don't get on with it).

It's not georeferenced and I don't think it's far from origin, no.

I don't think there are stray objects. And it's present in two separate files. I've DM-d you a copy of one of them.

Hm, doesn't seem to be producing happy results on my M1 mac

First test run of VW2022 immediately produces some major problems using "shaded" (previously OpenGL) view. These flickering patterns seem to appear on objects that are within a certain distance range of the viewpoint. I have reproduced it in two different files. Turning off "draw edges" in "shaded options" makes it go away. I was already experiencing this in VW2021 (see posts here) but it's even worse in VW2022. This is on an M1 mac mini. Screen Recording 2021-09-15 at 15.11.37.mov Screen Recording 2021-09-15 at 15.12.16.mov

So...does this mean that we are still using OpenGL, and it's just been renamed, or does it mean that we (at least on mac) have moved to Metal instead, which I thought was the plan?|

Thanks for this. The proof of the pudding will be in the eating... but looking at this list, it looks like one of the more promising updates of recent years. If all the things listed actually work, and if a whole load of new bugs aren't introduced, then I will be pleased.

No - no background photo. All the objects do have a renderworks texture, which I have visible in my OpenGL views. Turning off "use texture" doesn't get rid of the patterns but I see (checking just now) that turning off "draw edges" does get rid of them. Looks like you have "draw edges" on?

Just tried this. It does improve things but not completely.

I've not found a way to get back to normal other than changing the perspective to a setting that's not the one I actually want.

Here's what it looks like when panning around Screen Recording 2021-09-14 at 09.24.49.mov

This looks a bit like a problem I have been seeing in VW2021. I get similar effects in OpenGL sometimes and a way to provoke it seems to be to set perspective to "narrow" and then zoom away from the model somewhat. For example here's the same bit of a model, with the camera viewpoint a bit closer/further. Where it's further, you can see these kinds of patterns creeping in. This is on screen rather than in a PDF. The pattern usually seems to be a a kind of hatch effect but if you look carefully you can see it is divided into square portions.

I have been setting things up with "object" classes and "material" classes. Object class assigned to container of some kind (often a group) and then materials classes for the individual objects within that container. Certain parametric objects like walls or slabs go in the "object class" and their components in material classes. Then I can define "object" classes as structural or non-structural, or insulation, or finishes or whatever, and control visibility like this. However - that system falls apart a bit with composite objects like walls, because some of their components are structural and some not. Then I end up having to define some materials as structural or non structural, in order that for example in a structure-only view, I have the composite object's class turned on but only its structural components turned on and others turned off. So I end up having to duplicate materials... "rough timber-structural" and "rough timber-non structural" and so on. As a consequence of this, I have kind of abandoned "object classes" and just give the structural version of any material its own class, and control visibilities entirely by class. If I want to show structure only, I set "rough timber-structural" and "steel structural" etc as visible. This then potentially gets messy if I want to have primary & secondary structure separate (then I need "steel-primary structure" and "steel-secondary structure classes). Then if I want to make some change to attributes of all steel objects, I have 2 or 3 classes that I have to make the same change to. And if I have a group of lots of objects (let's say a directly-modelled truss or something) that needs to change from primary to secondary structure then I need to go in and change the class of all the relevant contained objects, instead of just changing the container object's class. The same applies to any material that appears in more than one construction stage that I want to separate out. But in practice, that doesn't happen very much. For example, plasterboard is always going to be a "finish" element - it will never be insulation or structure. It feels like this is probably the "least-bad" approach for me and the kind of projects I do. I think I've managed to export a structure-only model for engineers just using class visibility control.

This kind of workflow makes a lot of sense to me. I would suggest that some thought should be given to how insulation would be treated. It doesn't fit within the finishes category. Insulation is quite often associated with the structure (it might be any one or any combination of: within the structure, outside of the structure, inside of the structure). Obviously it tends mainly to be associated with the parts of the structure that form the external envelope. The way I currently tend to set up my models at the moment is so that using saved views to control class visibilities, I can easily show: 1 Structure only 2 Structure plus insulation 3 Everything including finishes Depending on complexity and the particular project, I might have intermediate stages between 2 and 3 and they will generally be determined by construction sequence. And I might have a primary and secondary structure. I find it very useful to isolate out the thermal insulation layer in order to visualise/check continuity.