Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by line-weight

  1. 7 hours ago, zeno said:

    I did a Bug for the same reason


    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?

  2. 14 hours ago, Jesse Cogswell said:

    Updated plug-in attached.  Let me know if this creates any bugs or issues that I might have missed in my (admittedly rather quick) testing.

    Copy Viewport Settings.vsm 15.7 kB · 4 downloads


    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?

  3. 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.)

  4. 6 hours ago, Tom W. said:


    I'm not sure if this is exactly the same topic being discussed here but I definitely have issues updating section VPs. I NEVER attempt to update more than one at a time. Even then I hit the button with trepidation. See:



    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.

  5. 16 minutes ago, Will said:

    I get this on my intel MacBook as well. After updating lots of section viewports Vectorworks uses lots of memory and becomes very sluggish. It’s like there is a memory leak in the section generation process. I also have to quit and reopen to be able to continue working.

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


    3 hours ago, zoomer said:

    At first I thought VP Update may now be multi threaded and therefore

    needing more RAM when updating all VPs at a time according to how

    many cores/threads are available.

    But when I watch VW's Status Bar it looks like it does one VP after the

    other anyway.


    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...



  7. 5 hours ago, zoomer said:



    Yes, I also was used to "Update all Viewports" on Intel Macs.

    Same experience here, RAM went up until it needed more Swap Memory

    than what was free on my system SSD (240 GB or so).

    Not 100% sure if it finally crashed macOS, but at least I got a warning message

    and at that time macOS also started to close all my other Apps running.


    For now I only Update one by one.


    Hm, is this in VW2022 as well as VW2021?

  8. 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.

    • Like 1
  9. 1 hour ago, arquitextonica said:

    Thanks A LOT!
    Out of curiosity... is there a reason for the change?


    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.



    • Like 1
  10. 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.

  11. 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.

    • Like 4
  12. 14 hours ago, P Retondo said:

    So, "use at creation" trumps the attributes palette default settings, but that potential conflict did not change the default attribute palette setting.


    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.

    • Like 1
  13. 5 hours ago, Boh said:

    So it sounds like you all want your attribute palette to be set to use class attributes by default


    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.

    • Like 2
  14. 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.



    • Like 1
  15. 17 hours ago, E|FA said:

    Other than being able to create orthogonal or perspective views for illustrative purposes, are there any benefits to generating floor plans via the Clip Cube and/or Horizontal Section Viewports, as opposed to creating a "standard" top/plan viewport?  Asked another way, If I just want to generate permit & working drawings, should I stick with the standard plan viewport (draw a rectangle on the DL of the area I want in my SLVP -> "View" menu ->"Create Viewport...")?


    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.

  16. Basically you can't do that in VW. That will seem crazy to you if you've come from SU but that's how it is.


    I used to use VW for 2d and sketchup for 3d, until VW 3d became tolerable enough for me to draw in 3d (in fact it was largely the introduction of the push-pull tool, copied from SU that made a difference). I tolerate VW's shortcomings because of the time it saves me, not having two parallel drawings, and because of the other stuff that VW can do and SU can't.


    If you only want to do quick 3d modelling, and don't really need the kind of drawing organisation or capabilities to generate production drawings, you are probably better off staying with SU which has a much more fluent 3d interface if you're doing mock-up type stuff. VW's could be improved massively but unfortunately it doesn't look like this is going to happen any time soon.

  17. 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.

  • Create New...