line-weight

yes this is my habit too. It looks a bit like this is related to the vectorworks version rather than the type of mac hardware though. Either way I would agree it might be a reason to hesitate from upgrading if you are still on VW2018.

Eurghh... as I suspected, no longer being able to reliably render multiple viewports in one go presents me with some headaches. There is something peculiar about the way VW does renders, that means that rendering the exact same viewport with the exact same settings, doesn't always produce a pixel-perfect identical result. One use case for me involves multiple views of the same scene, each with identical viewpoint, but with some changes to the model geometry in each. I need to be able to extract these images into a photo editing application where I can lay them exactly on top of each other. It all needs to line up at a pixel level. But infuriatingly, unless you render all these versions in one go, VW is liable to output a bunch of images all with slightly different pixel dimensions. So, updating all the viewports in one go is the only way I have of achieving this. And if VW can't update multiple viewports without crashing......

Thanks, that's very good of you! It seems to work; the only thing is that it acted on all viewports rather than just the selected one like a previous iteration of your script (which I have) did. However, I could see that I just needed to change the line near the end to ForEachObject(RenameVP,(((T=VIEWPORT) & (SEL=TRUE)))); and now it works on selected viewports only. I notice it takes quite a long time to run (about 15-20 seconds) even if I just have one viewport selected ... is that what you would expect? Is it because it has to check every viewport in the document to see if it's selected, something like that?

Did you make a troubleshooting thread in the forum, or just file as a bug? And was this recently, or some time ago? I guess you have not had any response as to whether it's something we might see fixed?

Thanks very much! Seems to work fine. Really appreciate you doing this. Not expecting anyone to write this for me, but here is another thing that would be really useful to automate: >Activate saved view A >Create viewport named "A" on sheet layer X >Activate saved view B >Create viewport named "B" on sheet layer X >Activate saved view C >Create viewport named "C" on sheet layer X etc etc Would that be complicated to do, in principle?

I have a question about this script... It renames viewports in the format: Layer Name > Drawing no. > drawing title But I would like to name my viewports: Layer Name > Class of viewport > Drawing no. Is that something that could be done with a simple alteration to the script? (By the way, this is as part of a workaround to a slightly annoying behaviour in VW when I am naming viewports, which is that although viewports don't have to have a unique "Drawing Title" I am not able to batch-change the "Drawing Title" by selecting a number of viewports and then typing my desired drawing title into the relevant field. VW will let me type something in there, but it doesn't then apply it to all of the selected viewports. Unless I am missing something.)

sections through site models have their own issues for me ... but in this case (ie what I'm doing at the moment which prompted my comment) there is no sectioning involved - just perspective views rendered in renderworks. They do all contain a site model though. I might try turning the site model off just to see if that makes any difference.

Hm. i wonder if this deserves its own thread in the troubleshooting section then.

yes, that's how it looks to me too. So I don't really see why the RAM should be a problem. I don't get an error message ... it just crashes or freezes with beach ball. Right now it's freezed, but it only seems that 12GB of swap memory is being used, which doesn't seem that extreme...

Hm, is this in VW2022 as well as VW2021?

Something I have noticed running VW on my M1 mac mini. Previously I could update a large number of renderworks viewports on one sheet in one go. I'd simply select them all and press "update". It might take a long time but it would do it. On the M1 this often seems to provoke a crash. I can get away with doing maybe 10 at a time, but if I try it with, say, 25, I often get a crash. I can't exclude this being a VW2021 problem (because I switched to the M1 and VW2021 at around the same time). But wonder if it could be relate to RAM in some way - as noted elsewhere, VW seems to progressively eat up an increasing amount of RAM that can only be released by quitting & reopening. In activity monitor VW is often listed as using more than the installed 16gb.

That would be great - thank you.

@Jesse Cogswell this script continues to be useful to me. One question ... would it be complicated to add a "class" column in the dialogue box? In other words, to let me sort the viewports in the list according to the class they are in?

Has anyone tried using floating view panes in vw2022? Any improvement? I am guessing not.

What kind of trouble are you seeing with external monitors?

Some of the issues are discussed in the thread linked below - although that's a bit out of date now. Horizontal sections are the "least worst" option for me at the moment, but the pros and cons will be different for each user depending on what kinds of projects they do.

I would look at the geometry contained inside the symbol, to see what class(es) it is assigned to, (NB this is not the same as the class the symbol itself is assigned to) and then check whether you have these classes visible. If that's the problem then you can choose between making those classes visible in any views you want to see the symbols in, or changing the classes within the symbol to match your existing classing system.

Having just played around with settings, here is one thing I think can cause confusion. When an object is selected, the attributes palette shows the attributes of that object. But when no object is selected, what does it show? If you asked me that without letting me go and try it out, I think I'd say that it shows the attributes that will be applied to the next object drawn. But actually that's not the case. If I change the active class to one that has "use at creation" on, then that's what determines the attributes of the next-drawn object, not what is shown in the attributes palette. I would argue that this is counter-intuitive because if i don't have a "use at creation" class active, then the attributes palette *does* show what will be applied to the next-created object (assuming nothing is selected). So in other words, anyone who commonly draws with "none" active and without "none" being set to "use at creation", gets used to the idea that the attribute palette shows you what the next object is going to look like. But if you then switch to another class, with "use at creation" active, this behaviour changes. The attributes palette continues to show whatever you last chose there, instead of what's going to be applied to the next object. And of course, once the object is drawn, and remains selected, it shows those attributes. I think this confusion would be avoided if, when you selected a "use at creation" class, the attribute palette switched to show the attributes set for that class, because that's what's going to apply when you draw something. Go back to "none" class and it reverts to whatever you last selected manually. By the way VW is not the only application where I find some confusion between "attributes of selected object" and "attributes of next drawn object". There's a drawing application I use that treats this in a different way but can still be confusing. It makes me wonder if it would be best just to have two separate locations for this information: one that shows attributes of currently selected object, and one that shows the attributes chosen for the next-drawn object. In fact it often feels to me that it's inconsistent that certain attributes of a selected object are shown in the attributes palette while the rest are shown in its object information palette. Isn't there an argument that all attributes should be shown in the OIP? Then the attributes palette would have a clear purpose - to choose what will be applied to the next thing you draw.

I think this might be the reason I seem not to have "none" class set to "use at creation" whereas I do have it set for other classes. Because sometimes I want to be able to draw something with attributes different to the "none" defaults. I suppose I could still draw it as none, and then change its attributes after it's created, but that could be cumbersome when I want to draw a bunch of things with non-default attributes, which aren't all in the same place. Thinking about it, the attribute I most often want to change is whether something has solid fill or no fill. I want a polygon to have solid fill whenever I want to subsequently extrude it, for example, whereas in other situations I want to draw a polygon without fill so that it doesn't obscure stuff behind it.

For me this is one of those things where VW seems to behave not in the way I expect - in that I go to draw a new object and the attributes are not what I feel they "should" be, according to what I had done previously. That might be that I am expecting them to be the defaults but they aren't - or I am expecting them to be something else but they are the defaults. I can't pin down exactly when/how this happens, all I know is that it does happen, and it's quite likely that VW is doing everything entirely consistently and logically while the fault in expectations comes from me. But somehow there is something about the way it behaves that constantly trips me up.

This happens to me all the time too! But I am never sure if it's me at fault, or VW.

I have only done this very quickly, so I don't know if it's much help, but this shows the kind of approach I would take; you can look at the attached file to see the settings. I haven't attempted to make the top/plan ones consistent as well - this is because I have mostly stopped using top/plan, and for my drawings I use horizontal sections instead. SUPPORT_WÄNDE DECKEN--lw.vwx

I do not use the attributes of container objects to determine fill or lineweight in sections. Instead they are determined per component, and I then fiddle around with the settings in "advanced section properties". Having said that, I have not yet tried to use "detail levels" - instead I have two setups, one which uses merged sections and one which doesn't, and these effectively are my two detail levels. If you posted your file, maybe some suggestions could be made as to how to get what you want. Agreed that there are lots of inconsistencies like this in VW though.

At least until some even faster desktops appear ...

A horizontal section creates a "true" horizontal slice through the geometry whereas a top/plan viewport doesn't. If you don't need to represent pitched roof spaces, and don't have a lot of custom 3d modelled geometry then you might be ok with top/plan.