Jump to content

P Retondo

Member
  • Content Count

    1,794
  • Joined

  • Last visited

Posts posted by P Retondo


  1. You are correct, this is the behavior of 2d reshape, and in fact it is true of all "select and drag" operations. Some have asked that with objects selected VW ignore other objects in the completion of certain operations, perhaps with the use of a constraint key. I think this is a great suggestion, but in the meantime isolating your objects using groups according to Islandmon's suggestion is the way to go.


  2. bc, in my experience copy and paste-in-place is to object coordinates, regardless of the view set in a layer and also regardless of whether the source layer has a z value. If you use layer z values, that can affect where the object appears in a layer link (its height is always augmented by the z value).

    Quite apart from all your questions, I just ran across a weird issue with Align Layer Views. I was editing an extrude in a symbol, and inadvertantly hit my key combination for Align Layer Views. After that event, all my OpenGL perspective views were white - in wireframe rendering they looked correct. I was able to get my perspectives back by going into a plan view of a layer and re-executing Align Layers.


  3. All of these add-ons really add up

    WinDoor is less than $200, or was when I purchased it recently. Even it has problems, but doing your own PIOs would only be worth it in the context of a very large firm that is able to devote resources every year to updating them and keeping them functioning both backwards for legacy files and forward with new versions of VW.

    What is it that you can't do with VW out-of-the-box?


  4. Following up on the discussion in another thread, it would be great to be able to adjust the origin of an associative hatch on an instance-by-instance basis without editing the actual hatch itself. In addition to numerical values which could be displayed in the OIP, there could be a tool whereby the hatch, once applied, could be dragged to the desired location.

    On top of that, I think it is high time we think about a more powerful interface for creating and editing hatches. The hatch tool should be able to take a user drawing and make it into a hatch. Placing and editing all those little line segments in that inscrutable interface seems to be the sort of thing modern CAD was designed to make obsolete!


  5. My experience may not apply to you, but I recently had a problem with VW freezing every 5 to 10 minutes. The crash was so bad I had to restart my computer each time. I thought I had a corrupt file, but unlike you I was able to reference the file into another. In the end, I reinstalled VW and the problem went away.

    You may in fact have a corrupt file, but reinstallation only takes a few minutes.


  6. Jenni, I'm trying to figure out why you are asking this. I think it's because you are zooming in to look at two 1 mil lines in your 1:200 layer, and they look fat and run together.

    If this is the case, I think you are trying to show too much detail for a drawing at this scale. If you want to excerpt this drawing, and show a portion of it at a larger scale, use the viewport method, even without scaling lineweights. You can show a portion of your drawing at 1/4" scale and the lines will still print at 1 mil, but will appear to be a lot thinner relative to the things you are drawing.

    Remember that in VW lineweight is for the printer's benefit. The line thickness is not like an object's thickness, and is not interpreted relative to the size of "real" objects. As Pat points out, anything smaller than 2 mil won't print consistently on even the finest printers.


  7. Erich, you're not really missing anything. It takes a trick to accomplish. (BTW, you didn't say but I assume you are using v12.5.n.) You can choose a custom door from the available options, which include some doors with various glazing types ("Parts/Leaf/Custom" in the door settings dialog). Or you can create a panel door, and in "View/Special Classes/Int. panel AND Ext. panel," assign a glazing class.

    Custom doors can't be edited in the same way as regular doors, not sure why.


  8. Take for example a VW drawn square and try and rotate it only about the upper square corner. It do not work in VW.

    clb, you can rotate any object about any point using the Rotate tool. Click on any point to define the center of rotation, click again to define the axis, click a third time to define the orientation to which you want the axis rotated. It couldn't be simpler or more straightforward, and is one example of a tool that is much more intuitive than the AutoCAD version.

    Alternatively, before executing the 3rd click you can enter an angle in the data box to constrain the rotation to a specific value.


  9. This, I think, exposes the basic problem with Viewports - the processor and storage overhead. NNA needs to put its best engineers on solving and optimizing this whole process, because it could balloon into a constant nightmare as users start to discover more and more creative uses for viewports.

    One solution I've suggested is caching a 72 dpi version of VPs for screen display, so that updating that screen version and storing it would take far less power and RAM. Another solution I've suggested is streamlining saves (incremental save), so that only changed objects are saved instead of the entire file. These things in tandem with allowing control over updates as suggested by DWorks would go a long way towards making things work faster.

    This is not just a problem with VW. AutoCAD stalls in a major way with multiple layouts.


  10. Try this: if you don't want the symbol object to take on the lineweight of the class in the new host file, select the object and make sure the lineweight is just a number, not "Class Thickness." If you have nominated "Class Thickness," the class in the new host file will override the lineweight in your standards file.

    This logic applies to all the other attributes as well. If you have nominated the "Use Class" option, the objects will conform to the host file's class attributes (provided that for that class "Use at Creation" is checked).

    Note also that when inserting symbols the active class has nothing to do with the class of objects inside the symbol, only with the class of the symbol itself. As a container object, the symbol's class does not affect the various classes of objects within it, except with respect to visibility. Not the clearest structure in the world, but at least we know what to expect.


  11. Susan, I think Mike may have responded by a private message so that in attempting to correct the facts it wouldn't seem he was giving you a public rebuke. I've corresponded with Mike on occasion, and I can assure you he is an honorable person.


  12. When the "target" file and "contributor" file contain symbols with the same name, there is a conflict. I just lost some work because I updated a WGR and an edited symbol in my "target" file reverted because it was replaced by a symbol of the same name in the contributor file.

    If this conflict arises, I would prefer that VW give us the option of renaming one or both of the symbols. Or, better yet, automatically rename all resources brought in by WGR with some kind of filename suffix. That will allow us to track things a lot better. This could be implemented by having a user-controlled resource suffix assigned the first time a contributor file is referenced.


  13. DWorks, I'm familiar with the building system you are referring to, and didn't qualify my comments in the interests of brevity. But, surely, you build your interior walls on the floor structure!

    The point, as you say, is still the same - being able to control the tops and bottoms of components separately would allow us significant advantages. In your case, for example, even though the brick walls extend through the floor structure, the interior finishes don't.

    If the NNA engineers take this request to heart it would undoubtedly require rethinking how components are constructed in the code. So while they're at it I'm sure they would be able to tackle the longstanding difficulties with component joins that you refer to.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...