P Retondo

Right, but walls were solids before - in other words, you can cut through them in sections, etc. I don't quite understand what you mean. I've overlaid window openings with custom 3d objects before, not sure what difference you are seeing. WinDoor would be cool to have - is that in the US version? I used to own it as a 3rd party add-on. It was way cumbersome, but, if so, that's the kind of thing I'm looking for in an upgrade. Just a few little improvements would keep me happy! BTW, I started with MiniCAD version 2, I think. This software was originally based on the idea of a hybrid 2D/3D environment, and at that time there was no such thing as a "Screen Plane" object, all 2D objects were in true two dimensions (unlike ACAD, which always had a Z component to their objects). Then I guess VW got AutoCAD jealous, and had to put a Z component on 2D objects, which were then called "Layer Plane." That's when VW started to lose its original inspiration, which was solidly based on centuries of 2D design and representation of 3D objects, linked to the new 3D modeling capabilities of fast computers.

Besides eliminating Screen Plane - which you didn’t like - is there any positive reason, for someone who actually thinks screen plane was a brilliant concept, to upgrade to 2022?

I've purchased both 2021 and 2022, but I'm still using 2020 because I haven't heard anything that makes it seem worthwhile to update. I'm strongly considering discontinuing my Service Select. Can anyone with good architectural experience with VW give me a good reason or two to continue getting updates? Even some minor improvements would be worthwhile, though I have to admit that VW's failure to understand the importance of screen plane objects is deeply discouraging as an indication of future trends. But, for example, window sills in 3d have never (ever) worked - is that working now? Window and door types do not correspond to common real-world objects, such as multiple track sliding doors. And my current pet peeve, there is no longer a way to model a U-configured stairs with two landings at the turn instead of 1 (for some reason you can do 2 landings and 1 step, but not 2 landings).

Really encouraging exchange of information and perspectives between experienced users and conscientious VW insiders! I haven’t submitted a bug report in at least a year. My feedback has been that the effort “seems” to go down a black hole. Maybe VW gets too many reports to do this, but it would work better if reporters received at least two notifications, one upon initial analysis (bug confirmed/not confirmed, already reported, working on it, etc.), and another at the time of resolution.

I hope VW takes note. I am not happy to be paying every year for "improved" software that performs worse than earlier versions. Still sticking with v2020, even though I own licenses to 2021 and 2022. Unless someone with user experience can tell me v2022 is at least as fast, I'm going to have to pull the plug on wasting money on future updates.

Boh, and others, here's a question: do the Attribute Palette default settings trump the "use at creation" directive in class settings, or vice versa? If there is no clear priority at the algorithmic level, that could be a problem. As a user, it's a problem to me that there are two possibly-conflicting default settings in different places. Later: Okay, so I just did a quick test. "None" class set to "use at creation." Set default attributes to red fill. A "None" object was created, resulting in the None class fill (white). The default red fill setting did not change. A "Dimension" object (not set to "use at creation") had a red fill. So, "use at creation" trumps the attributes palette default settings, but that potential conflict did not change the default attribute palette setting. Leaving me to wonder why there is even a "use at creation" setting in the class definition, if the attributes palette can be set to default to class attributes.

Matt, never use Create Similar command, but I frequently experience the problem others refer to. I always set the Attributes Palette to the default value "all by class," chosen with no objects selected, but it frequently changes to another setting, and I haven't noticed any particular pattern.

I don't use the filter at all, and seldom use the callouts database because its functionality seems convoluted to me. I wish it were designed in a more intelligent and user-friendly way, and I assume this poll is intended to show one way in which the interface is poorly designed. I'd like to be able to edit an xml file directly, and have those files saved in a folder instead of having the mess managed by the software. Then just populate the keynotes with the xml file, instead of this clumsy interface.

I believe you have to get into Marionette and Python scripting for those advanced capabilities.

Zoomer, I don't know what you mean by this. Do you have a minute to explain?

I have noted the "working plane" methods that might be basically the functional equivalent of screen plane in views other than Top Plan, provided we can paste a planar object created in some other view onto the working plane. Seems like a lot of effort went into that engineering when Screen Plane was working perfectly well. So now we can have ephemeral 3d planar objects floating in space in addition to 3d planar objects on the layer plane. What's behind the fervor over that? We always had 3d polygons, and VW since day one has had Screen Plane 2d objects, even though they weren't called that until Layer Plane came in. I don't get it. Why does someone like Zoomer want to get rid of a method others use and have relied on? As for the alleged simplification that started off this thread, I'm not seeing how Working Plane 3d planar objects makes things simpler - just different, at a cost to engineer all that. Thanks, though, to those on this thread who have pointed out that we can work with v2022 when creating, editing and orienting objects in views other than Top.

I'm not sure why anyone who doesn't use Screen Plane cares about it. For those who do, like me, not having screen plane is a deal killer regarding future upgrades of VW. I've already paid for v2022, but won't even use it if Screen Plane doesn't work. I'd appreciate any further feedback on whether the legacy capability actually works.

If you are on a Windows computer, there is a key called “Num Lock” that toggles the functionality of the numeric keypad from numeric input to 3D view modes and back.

Tom, this is what the wall looks like when I edit one of the components to "wall height": It looks this way because of the bug I noted above, where the wall itself changes from a top boundary of "Layer Height" to "Top of Slab" in a project where I don't have a slab. I note that you are using VW 2021 on a Mac where I am using 2020 on a pc. Possibly the bug was fixed in VW 2021.

Just discovered at least one glitch that explains the behavior. When you edit a wall component by changing it to relate to wall height, the wall height itself, as shown in the OIP, changes from "Layer Height" to "Top of Slab." That is definitely a bug. Change that setting back, and the components display as desired. Now I have to go back to the project I was having trouble with, and look at every wall to see if that setting was corrupted when I edited the wall style. I don't know if VW tech is monitoring these discussions any more, that would be helpful. One gets tired of the black hole that is bug reports.

Tom, in answer to your request I made a simple file containing a single wall that was taken from default wall styles. I discovered some really buggy behavior when I tested this. wall height.vwx 1 Edited wall style by right-clicking on the wall, and edited the core component, changing its top & bottom preferences from relative to story to "relative to wall." That is the state you find this drawing in, but the first time I did it, it worked - i.e., that component became 8' tall. 2 Did the above operation again, this time editing another of the components in the same manner. Instead of making that component 8' as well, everything reverted to the state you see, which is everything 0' tall. I undid that operation, and saved the file without that change. The undesired behavior stuck, for some reason. Try it, you won't like it! I conclude from the above that we might be dealing with a bug, and that my tech support person might have just been trying to get through the call as quickly as possible. Rather than filing a bug report, which I have found in the past to be a time-consuming drain for practically zero return, I wonder if getting engineers to tackle my request - to make this setting operate as it should - would lead to an examination of the bugginess I see, and possibly also to the improvements you describe. I hate to think it is too much to ask that VW fix this whole unwieldy wall height (and component height) system so that it works smoothly and transparently. For example, if you have a wall that is set to layer height, and then want to change its height, top or bottom, editing the offset often gives undesired results. Likewise with editing the wall height directly. I often resort to creating a 3d planar object, and using "Fit Walls to Objects" to get what I want, that works reliably and logically. As to why I don't use stories, just look at the building pictured on my profile and you will see how a single story building can, in the world of VW "stories," make no sense to the software.

Tom, that, according to my experience (using VW2019) and according to my tech support person, is unfortunately not correct with respect to my specific comment. I was unable to make a global change to component height RELATIONS (not offsets) after making no changes to any instance of my styled walls. Also, and to be clear, I am not asking that the instance-by-instance "override" of height relations be dumped or interfered with. I'm just asking that we not be prevented from making a global change by editing the wall style. Also unfortunately, this is an incredibly and (IMHO) unnecessarily complex issue. The behavior of wall heights, with the confusing and ungovernable "offset" concept in the OIP and the added complication of component joins to horizontal objects, has created a bit of a nightmare. I think it might be made better, somehow, but this is quite a mess of a corner VW has painted us into. VW engineers have tried to make it easier for designers of certain building types to change their floor-to-floor heights without manually modifying a lot of objects. I'm thinking this problem could have been solved in many ways, but the ones chosen have led to very muddy waters. Glad to have THAT discussion, but in the meantime, does anyone see anything wrong with making this styled wall component height relation mode editable globally, as long as contrary overrides for instances are preserved? It's either relative to wall height or relative to story, and I don't see why that simple choice can't be globalized and isolated from the infrequent instance when someone would want a particular wall to have a non-global choice.

I thought I understood that settings in Wall Styles were global - in other words, change a setting and all walls with that style change. Turns out that is not true, and it can play hell with your 3d model. Especially if you don't use stories, which are not my cup of tea at all. But that is another discussion. It turns out that the way component heights show up, which is a setting you can change in a wall style, is not affected by the global change you make. VW tech support claims this behavior is "by design," but unless someone can convincingly illuminate, I maintain the belief that this feature makes a mockery of the concept of "design." And, by the way, this whole problem is almost guaranteed to crash VW if you start to work with it. I started out wondering what the heck was happening with walls where only certain components displayed as full height. Like the wall on the upper left, instead of as expected (lower right): Turns out that the various components were defined differently in the wall style as to how height is handled: I changed the settings to "relative to wall height." Nothing changed in the display of the wall. I called tech support, and they pointed out that EACH INSTANCE of a styled wall can be edited as to this behavior (and no other behavior) as evidenced by the fact that these settings are black instead of gray when you click on "Components" button in the OIP: Tech support says that this particular choice "sticks" whether you edit the wall style setting or not. So depending on how things were set when the wall style was created - in this instance, a stock wall style from VW defaults - that's the way it will be, even though you can change the option in the wall styles component settings windows. This situation makes absolutely no sense to me. A global setting should operate globally, just like ALL THE OTHER SETTINGS in a wall style. The fact you can work around this by editing individual instances is tedious, at best. Does anyone see any logic to this situation? I don't, and my request is to make this component setting operate globally when a wall style is edited.

Issue resolved today after some troubleshooting with Dave from VW tech support. We unchecked "Export as flattened 2d objects" and also unchecked every option in the 2D Fills and Files box. The exported file size went down from 65 MB to 217 KB, and every object could be imported back into VW as a circle. When exporting for CNC work, I recommend these options.

I just exported a reasonably-sized drawing consisting of circles to .dwg, and it turned every object into a polygon, resulting in huge filesize bloat, plus not the object we need for CNC. Anyone have any experience with this? I can import .dwg circles as circles, why can't I export? Is there a trick to this?

@Art V Some users may not see the need for Screen Plane objects, but those who use them do see the need, especially in design layers. No matter what working plane view you are in, Screen Plane is there to import and create geometry and relationships.

The screen plane was the original VectorWorks 2d object mode, so I would not be surprised if it is embedded somewhere. The Layer Plane object is almost like a 3d polygon, while the Screen Plane object is the essential bridge between thoughts best expressed in 2d from any view, and 3d modeling. But if you don't like it - I hope they can fix the preference so you can avoid meeting them!

Will, I had the opposite problem. No use for Layer Plane, but VW kept reverting to that preference. I finally figured out it was a bug that was triggered by editing the crop in a sheet layer viewport. That has been fixed as of VW2020. Maybe that will help you track down the problem. Everytime it happens, try to track what you just did, even if there is no apparent logical connection.

I make my own title blocks, so I don't know about the canned VW objects. But making your own works fine. Make them a symbol, and attach records to enter the info items you want. See "Link Text to Record" to display that information in each unique instance of your symbol. When you select a symbol set up this way, you will look at the "Data" tab in the Object Info Palette (OIP) to be able to manage your records. Here's what that will look like (you can have more than one Record Format for a symbol object): Other users may have advice tailored to the VW title block object.

Under the “View” menu at the top of your VW application window, pick “Projection” and then one of 3 “Perspective” choices. Under the light bulb tool set you will find various ways to navigate.