line-weight

Unfortunately you can't actually solve this problem entirely by changing those settings - in OpenGL the curves will always be faceted to some degree and there will be some mismatch between the profiles when you zoom in.

Of course, many builders hate keynotes and references because they don't want to shuffle between different sheets to find out what something is - they want the info in front of them directly on the drawing. Unfortunately for the builders, it's usually not them that pays for our drafting and editing time though....

I try and limit my use of colour on most line drawings. Generally everything is black and white. If I use a colour (for example to make annotations or dimensions clearer) then I try and do it in a way such that the drawing is still legible if converted to black and white. This is largely a habit left over from the days when drawings went out on paper, and then may have ended up getting photocopied before reaching their final destination. Arguably this is no longer so important, because drawings are now mostly distributed digitally. However... not everyone has a colour printer, so there is still the possibility that a black and white version of a "colour" drawing is the one that ends up on site and gets built from. In any case I find it's quite a good discipline to try not to rely too much on colour. I often see drawings where multiple colours have been used as a lazy way of putting some thought into legibility. Communicate as much as possible using linetype and lineweight. If a drawing is getting very crowded with information, this probably means that you need to change the scale or split it into more than one drawing, each showing different types of information. Where separate drawings show different bits of information relating to the same location or area... split that information in a way that makes sense and is useful to those who will be looking at it. Usually for construction drawings that means splitting by trades.

Post some example drawings of yours and I'm sure people will be willing to constructively criticise! Good drafting is a skill that isn't easily learnt from a book.

I'm ever so grateful to VW for choosing "not to compete" with something better that was not available to me anyway, and letting me use the deficient tools for years instead. And choosing not to fix repeatedly complained-about bugs with those deficient tools. Literally for a decade. Taking customer care to the next level.

I'm going to start using Windoor even if the official line is that the long term solution is to improve the native tools. That's because there's no reason to have any confidence that they will be fixed on a timescale measured in anything other than years. Even if they were magically fixed in VW2023, then on the basis that most VW releases are not really safe to use until SP3 or so, that's more from a year away from now.

Those look like mainly issues with the window tool rather than the new wall features. There have been no changes to the standard window tool in VW2022 so I'd not expect it to be anything other than as terrible as it always has been. I think I recognise some of those corner window problems. Have you tried using the Windoor tool instead?

I also have a nervousness about objects that are sitting there as complex subtraction/additions that one day VW is going to give me one of those "unable to compute object" messages. And have the feeling that once I convert it to a generic solid it is then "safe". But I'm not sure if that is rational or true.

Where I have some object that is, say, an addition, or an extrude along path, or suchlike, and I know that I won't need to edit it further, am I right in thinking that it's best to convert it to a generic solid, to reduce file size and let the drawing load faster and so on?

I've realised that I've confused myself here, I think. Because there are "undos" and then there are the "previous / next view" arrows at the top left of the screen. They take you back between views, without making any changes to objects. What happens is that I want to get back to a view I was looking at just recently - and it feels like it was just a couple of moves back, but actually I have changed view using multiple zooms/pans, perhaps simultaneously, because I'm using the mouse scroll wheel and so on. And to me these were just a couple actions but to VW they were a long string of small actions, and it's these that I then have to painstakingly step back through. And sometimes there are enough that I run out of "previous views" before I get to where I want to be.

I'm sure I sometimes find myself stepping back through multiple view states, even when there are no changes to objects involved.

Well, that's strange - I just checked my settings and it's set to "never" undo view changes. And then I tested it, and zooming and panning don't seem to be included as "undos". And yet I could swear that it's the behaviour I see sometimes, so I am now going to watch out for it and see if it only happens under particular conditions.

You can also effectively lose a bunch of undos if you do something, then do a bit of panning and zooming around, because then you have to undo many many view changes to get back to the point where you can actually undo something you "did".

Thanks for the response! Hmm... I wonder if I added the wrapper myself, so that I could add it as a menu command. If I did, I don't remember exactly what I did, and it's very likely that I did something wrong because I'm not any kind of Marionette expert at all. I've attached the file I've got (including version with wrapper) with this message. MarionetteDivideCurve_MFarrell.vwx

About that dialogue box. It confused me for a while, because I didn't understand why everything was greyed out. Eventually I realised that if you tick the "wrap" box, then that component is no longer greyed out. This is another example of inconsistent UI design, because normally in VW if something is greyed out it means you can't change it - usually because it's over-ridden somewhere else, for example in a style setting. So when a user meets something that is greyed out, the message is "you can't change any of this here". That's the message I received, and why I went off looking for where I could enable those settings. I didn't try ticking the "wrap" box because there was nothing to tell me this was available to be changed. After all, if I try clicking on most of the columns nothing happens, confirming my understanding that all of these settings are closed to me. I realise that ticking in that column then un-greys the settings that are now changeable, but there needs to be something to make clear to the user that they can tick or un-tick certain columns. This could at least be improved by having an X in those columns where they are unticked (a bit like in the class/layer visibility dialogues) because if that X was not greyed out, that would be a clue to the user that it's something that can be changed. A blank space doesn't tell anyone anything. With all the talk of VW improving its UI, this kind of bad design just shouldn't be allowed out in what is a new feature. I'm pretty sure I won't be the only person who has been confused by this. Also, it's not really on to leave one column un-labelled. If the problem is that it would make the dialogue too wide ... this is called a design problem, which means it needs to be solved by changing the design of the dialogue, not giving up and just ignoring the issue.

Hello @Marissa Farrell I have made much use of this script in the past... and am just trying to use it again now, in VW2021. I'd previously used it in VW2018 and all worked excellently but something is going wrong in VW2021 and it is leaving me with a 3d polygon that seems to have infinite or very large dimensions. Any clue what might be happening? I tried opening the marionette file that I previously had saved as VW2018 version, into 2021 and re-adding the command to the menu. I notice that if I open the file linked at the top of this thread straight into 2021, the "wrapper" object doesn't appear.

I have it set up to appear at a certain keystroke (I am using "."). Then I have assigned that keystroke to one of the side buttons on my mouse. So I click the side button to bring it up, meaning it only comes up when I want it, and I don't have to wait for it. I'm still in the process of training myself to use it.

My experience so far is that it takes a lot longer than "standard" renderworks, and produces worse results.

I actually have a special viewports on their own layer which I call my "section control viewports". This is where all the linked section lines live for all of my important sections in the file. If I want to tweak the section cut position, I go and do it here. Then the section lines on the actual drawings are often unlinked (just dumb objects in annotation space). I can fiddle with them a bit to aid drawing clarity, without worrying that things will change in my section viewports. This is not really how we are supposed to use them...but it tends to work for me. It's kind of a system that I settled on several releases ago though, and some functionality has changed since then so at some point I might review it and adopt a new strategy.

So it seems like this is really a VW problem - in other words there's not really a good reason why VW shouldn't run ok on a machine with 16GB RAM.

Hooray! I'll look forward to moving to Monterey when it's stable. Meanwhile one of my frustrations is to do with running several monitors - for which Displaylink works pretty well, except for one annoyance which is that Displaylink does not support rotated monitors on M1 macs. And I have one of mine rotated, so I have to make that one the "native" one even though it's not my main one. And my main monitor (which for most of the time is my Vectorworks one) works just about fine via Displaylink but I do notice that it's just a little more glitchy when doing stuff like flying around in 3d, compared to how it runs if it's the "native" one. There's a very long thread on the Displaylink forum of people asking when they are going to support monitor rotation... but zero response from the company on whether they have any intention of doing so. I wonder if the problem is somehow on the "apple end" and things will change with Monterey.

I seem to be on 100 undos. Perhaps I should try changing it.

So does the problem arise whenever you have a floating pane open? Because my feeling is that in VW2021 (and maybe 2022 as well, haven't really tested it yet), having a floating pane open can cause various problems with jittery motion, odd snap behaviour and so on. To the extent that I've kind of stopped using floating view panes.

This prompted me to watch what is happening with memory on my M1 when I'm working in a big file in VW2021. Because sometimes, the file becomes really unresponsive, but is fine when I quit and re-start Vectorworks. It seems like VW gradually fills up the memory while I am working, but it never does anything to reduce the memory use. So eventually it always reaches the limit. I don't know enough about how things are supposed to work, to know if this is what should be happening. Here is what it looks like after I have had the file open for a day or two while I work on it. Here is what it looks like when I close that file (but keep VW open): And here is what it looks like when I quit VW, and then re-open that file to start working on it again: So, is it when I am working on sheet layers that it is somehow filling the memory up?

Is this in VW2022? If so is it the same as this problem?