Jump to content

P Retondo

  • Posts

  • Joined

  • Last visited

Everything posted by P Retondo

  1. Zoomer, I don't know what you mean by this. Do you have a minute to explain?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. @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.
  13. 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!
  14. 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.
  15. P Retondo


    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.
  16. 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.
  17. Thanks, Jeff. I wonder if it has something to do with which version of ACAD I'm exporting to. I'll check that out.
  18. @jeff prince Are you stating this as a NNA engineer?
  19. @jeff prince When you select "Export DWG layers as : layers", your layers should become separate layers in ACAD. That's the way it has worked in the past, and since it isn't working that way now, that would be a bug - correct? The behavior in v2020 is not consistent with behavior in previous versions, or at least that's what I'm trying to confirm with other users. Having all your layers come into ACAD jumbled into one layer is distinctly unhelpful to most of my collaborators.
  20. @jeff prince Jeff, thanks for your input. I worked with ACAD for 4 years, so I am well aware of the layer/class issue. My purpose in bringing this up here is to find out if this might be a bug so I could report it.
  21. Jeff, thanks. I have layers with different stories of a building in separate layers. I want the same layer structure in the exported .dwg, exactly as you describe. I was wondering if anyone else has noticed that this doesn't work any more. The way I know this is that my structural consultant complained that everything was in the same ACAD layer. I imported my .dwg back into VW, and everything came in as one layer - I don't maintain a license of ACAD anymore, but I trust that what the engineer told me is true. I had to export separate files for each story.
  22. Jeff, I don't want to export classes as separate layers in .dwg, I want to export layers as separate layers in .dwg. Used to work in the past, but now it doesn't seem to.
  23. Anyone else experiencing this problem? When I export a file, with multiple layers visible, to .dwg and select "Export as dwg layers: layers," the resulting .dwg has only one layer with all objects crammed into it.
  24. I hope this doesn't confuse you, but I ignore the "stories" concept completely. "Stories" offsets each layer by the story height from "ground," which is marginally handy if you want to modify story heights, but I prefer a simpler system. (Bear in mind that you can change things from project to project as you work into the software.) I just name layers by story number, with each layer set to 0 from ground, and move objects up by my floor-to-floor height for 2nd and 3rd stories. I use the "layer wall height" parameter to set the heights of my walls. These fields are accessed by editing the layer in question. When you look at a set of walls and 3d objects from an elevation view, you can select them and move them or align them to make sure everything is right. Check your doors and windows - there are some parameters in the info palette that set their heights, just play with them looking from the side to get them right. Also, when you need to extend walls up or down to meet something, use the "Fit Walls to Objects" tool in the AEC dropdown menu. I set up special layers just to make that easier. For example, suppose you want your first floor walls to go down to a foundation footing. Create a 3d polygon at the desired height, put it in a special layer, and extend your walls down to that object. The beauty of that is that your doors and windows automatically stay put after that operation. Have fun! PS: the reason I never adopted "stories" (i.e., "layer elevations") is that when you paste an object "in place" from one layer to another, it doesn't carry with it it's "actual" height when the layers have different heights above 0.
  • Create New...