line-weight

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?

I'm curious about this too. One thing in particular I don't understand... if I am looking at my model in 3d perspective view (which usually means I'm using OpenGL) and then ask to see it in hidden line... some time passes while it works it out, and then the scene appears in hidden line. But then I am able to fly all around my model (including parts not visible in that initial view) with it rendered (apparently) in hidden line, and this all happens in realtime. I can look at any part of the model in detail, all in what looks like a hidden line render. But as soon as I stop flying around, VW asks me if I want to rerender the scene - and if I say yes, it stops, thinks for a while and then shows me what I was looking at a few seconds earlier and seemingly rendered in realtime.

I haven't used it a lot for real, but some testing did seem to show that VW2022 was slower than VW2021 for certain things, mainly viewing sheet layers with a lot of complex vports, and switching to a design layer view, again in a complex and large drawing: (copied from another thread)

I'm quite happy to "think VW" ... the problems generally come when it's such hard work to figure out what VW is thinking, because the underlying logic is so deeply buried beneath layers of half-baked, inconsistently implemented tools, interfaces and features. Sometimes it seems like all the true lifting power of VW was written 20 or 30+ years ago, and it's quite impressive really that its usefulness has survived in spite of the big mess that's been built upon it since.

Shell doesn't work on a 3d polygon - is that right? Has to be converted to a generic solid first?

New to me too! It's not entirely inconsistent as there are a couple of other actions that happen from the mode bar, for example when you click the green tick to extract a face.

I find using NURBS useful in many cases but also often hard to control, partly thanks to a lack of documentation about how they actually work in VW, which I have complained about several times. I also find that they are useful for generating one-off objects but as soon as you want to fit anything to them, they become very inaccurate, so when I've got curves where I need things to fit together exactly, I often end up resorting to segmentedlines instead of true curves. There's an additional problem with the way VW renders gradual curves, which has been the subject of a few lengthy threads.

My approach would have been less sophisticated than those described by @Benson Shaw ... I would convert the 3d polygon to mesh and then to generic solid, then I'd duplicate it, move the duplicate up or down by the desired Z value, manually draw 3d polygons to make the "sides" connecting the two meshes, and then do an add solids of everything to get the end result. Reading this: has been very helpful for my understanding of what a 3d polygon actually is. VW seems to understand that if I draw a 3d polygon all on the same plane, it's a flat "surface", because it will let me extrude it. Also useful to have it pointed out that there are several different possible trimeshes that can be made from a 3d poly. As VW will convert a 3d poly into a mesh... it must somehow make its own decision about which one to choose. Is there a rule for how this happens?

I'd recommend not wasting your time with the Nomad app to be honest, at least for 3d stuff. Unless there's been some change made to it since the discussion on that thread.

I have never noticed this before either! I can see how to use it to toggle between the multiple selected items - they are briefly highlighted in red and the OIP shows the details for each object in turn - but how do I then delete one of them?

That's disappointing to see as I thought I saw a post from someone else saying this had been fixed. Very annoying when you're trying to work on a sheet layer. Usually I have to restart VW to get rid of it.

That's exactly what I thought too.