Jump to content

P Retondo

Member
  • Content Count

    1,806
  • Joined

  • Last visited

Everything posted by P Retondo

  1. Wezel, assigning a special class to background objects in Section VPs works for me. The one problem I've encountered is that walls in the background still show up as their regular lineweight and color, with the line you want to see superimposed over it. This has been logged as a bug and is with the engineers.
  2. Ronin, you can't snap across layers unless you are in Top/Plan view, and the other layer is as well and at the same scale. As an alternate, you can create a layer link. Then you can snap to the objects that live on another layer.
  3. Tad, try Select All ( again. It always works, unless you don't have a viewport crop object at all. That's always possible. To double check that, draw a rectangle and close the edit - if there is more than one crop object VW will warn you.
  4. 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.
  5. Out of curiosity, what is driving you to use groups more?
  6. Christiaan, good comments. I think we should be given the choice, and your idea about displaying all the objects in one window so we could make choices in one go is excellent. Clearly, once there is a sufficient number of symbols involved, the glut of objects could become similar to the $name nightmare of AutoCAD Xrefs.
  7. 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.
  8. 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.
  9. 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.
  10. It would be great if we could selectively make 3d edges invisible in the same way we can make segements of a polygon invisible. That would eliminate a lot of graphic imperfections in line-renderings of 3d models.
  11. 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.
  12. Jim, are you saying one can use the eyedropper tool to modify class attributes? How is that done?
  13. Yes, Katie, thanks! Is this really possible? I mean, I know it is possible, but is it a realistic request (rhetorical question)?
  14. Thanks, Katie! There is a lot to add regarding walls and components. For example, I speculate that the reason DWorks uses 2 walls for his exterior walls is that he can model the way sheathing and exterior finishes cross over the floor structure, but wall structure and interior finishes don't. Islandmon refers I think to the same issue. It occurs to me that separate control over the bottom and height of components would accomplish this in an integrated way. Then, for example, the exterior sheathing elements could have an override so that their bottom z = top of foundation while the bottom z of the structural center is at the subfloor and bottom z of the interior finish could have an override to sit on top of the finish floor. Add to this similar control over the top of components, and the ability to wrap components around the freestanding edge of a wall, and you would have the perfect wall tool!
  15. Going back to the original question posted by DWorks, it sounds as though he'd like to extend all his walls down past floor level, instead of extending them up past the next-higher floor level. The wall style definition allows for automated adjustment of the height (and hence the top) of the wall, but not the bottom z value. His suggestion makes sense, but he threw me off by talking about "importing" walls, by which I thought he meant copying walls from one document to another. By the way, if you look at the "insertion" tab of the wall styles dialog box, that adjustment value is called an "offset." This suggests that the wall z value would be offset by the number inserted there, but as we know the number inserted there instead modifies the delta z value. This language is a bit misleading. Anyway, DWorks, Peter is suggesting that you define the layer z at that point below your floor slab where you want the walls to begin. The flaw with that approach is that all your interior walls, which I assume you want to sit on the slab, will be low as well. Katie is suggesting that you select all your exterior walls and modify the "Bot Z" value, which seems to me to be the best workaround at the moment. Having a "Bot Z" offset as part of the Wall Styles Insertion definition seems to be a worthy request, and I'd like to add to that clearer language in the dialog box.
  16. Peter, I wasn't giving you a hard time, just taking the opportunity to harp on one of my perennial complaints!
  17. Katie, I often want to adjust the height of things like windows sills to roof elements, or other things that are on different layers. If I create a layer link in the layer I'm working on, I often get so many objects it clutters the screen and I can't see what I'm doing. So I want to paste one, or just a few objects, in from the other layer. The VW system prevents me from doing this unless I just ignore the "Layer z" system, which is in fact what I do. Actually, because we can't set the texture of the edge of a floor object, and also because horizontal textures don't align to a common datum, we often have to adjust the exterior walls so that the top of a wall below aligns with the bottom of a wall above. In that instance, I like being able to paste a 2nd floor wall into my 1st floor layer to make sure that there is no gap, or that the transition point is occurring where I want it to be. Then I can render the 2 in OpenGL and apply a fudge factor to the texture vertical so that I get seamless rendered exterior treatments. PS, Katie I was editing my post above when you replied, so you may want to go back and look again!
  18. Peter, while what you say is true, I've always felt that this "layer z" approach of VW's is fundamentally flawed. That's because "layer z" is only implemented in layer links or when "stack layer views" is on. Here's the ArchiCAD approach, which I feel is much smarter: you can set a "layer 0" so that objects are automatically drawn at whatever height you desire, and you can toggle an option to read out the object's height either relative to the layer 0, or relative to absolute 0. That way, an object's absolute height stays with it when pasted from one layer to another, but you can always choose to work within a dimensional context where the height coordinate reads out relative to, say, 3rd floor finish floor. By contrast, with VW's method when you set a "layer z" value, the objects are actually drawn relative to absolute 0, and their height is augmented by "z" when shown as a layer link. Try pasting a 2nd floor wall into your 1st floor layer, and you will see that it sits down on the 1st floor level instead of up where it should be. In a reply to a "wishlist" item that mentioned this issue, NNA seemed to show some interest in implementing automatic "z" adjustment when pasting from layer to layer. This may put us functionally into the same ballpark as ArchiCAD, and would probably solve the importation issue mentioned at the beginning of this thread. Personally, I like the cleaner approach. An object's z value should be relative to absolute 0. I think it is time for NNA to bring some simplicity and clarity to this issue, and to implement a translator that will adjust all legacy layers with "z" values. It would be consistent with the UCS approach to allow different coordinate contexts that interpret absolute coordinate values to the immediate context, so they should provide an integrated 2d/3d coordinate system control that allows named user coordinate systems to be selected based on translation and rotation of all 3 axes. For example, when working on the 3rd floor 20' above the first floor, we could have a "Third Floor" named coordinate system where the system adjustment factor is z+20'. We could then toggle our coordinate system choice to see that the bottom of walls is at 0 in the "Third Floor" context, but at 20' in the "absolute" context.
  19. Things like dashed lines for footings are better implemented through classes, so that they can be dashed in one viewport and solid in another. Just set your wall style options to "use class" at the appropriate locations.
  20. Jim, I have a DeskJet 1220C that prints on 13x19 (Super B) paper, which allows a 50% print of a Arch D format. There are other reasonably-priced printers out there which can take that paper size, and with "best" output the prints are very readable.
  21. Jan15, thanks for a rousing tour de force that manages to be funny without insulting anyone but Petri - who richly deserves the treatment, which in your hands manages to be quite a bit less sharp and more sympathetic than in his. He must hate you for that. I, myself, have less talent for comedy than others posting to this thread. Sorry, but I'll have to live with having more appreciation than creativity.
  22. Wezel, a thoughtful suggestion, but I myself would prefer a solution built into the software. Even if I had the time to fuss with customization, I have found that updating these kinds of things over and over again with new versions of the software is just uneconomic. Even excellent third party add-ons for VW suffer, at the least, from being behind the curve when it comes to updates. Speaking of which, very tangentially, I wish that NNA would consider purchasing Info Editor and having it's author keep things up-to-date. This tool is now indispensable to me. And it has very interesting potential spin-offs when it comes to creating more controllable exported reports and interactive schedules. Back to doors: it is known that the door and window PIOs are being rebuilt by NNA, and I hope that this and other suggestions (such as having the hinge centers be actually accurate with respect to trim thickness!) could be considered by the team. It would be great if Jeffrey Ouelette could post the features and improvements which are current candidates for implementation so that users could comment.
  23. Brian, could you give us at least one specific and replicable example? I've had these problems in the past, but not lately, except for one: it is not possible to join an arc to a line where the line is tangent to the arc at the intersection point. At least, not always possible when the join tool is used in one of the possible orders, but usually possible when you reverse which object is clicked on first.
  24. David, I think you have figured it out. The Sheet layers are all at 1:1 scale for objects placed directly in the layer. Viewports override that scale, and have their own independent scale factors. When you place objects and dimensions "inside" the viewports using "Annotation" editing, they appear at the Viewport's scale.
  25. The symbols are unique. I use them when I have to add a non-standard muntin pattern to the PIO instance. Robert, thanks for the tip. I had considered doing exactly that but my uncertainty regarding how "&" and "|" are processed stopped me. By the way, the worksheet automatically rearranged the argument as follows: =DATABASE((INSYMBOL & (R IN ['Door']) & (Door.OnSched=TRUE))) Also, this spontaneously caused the sorting to revert to the previous random arrangement, and I had to reapply sorting to the ID Label column. Could you explain when "&" acts as an inclusive versus exclusive operator? It seems to me in the above argument that the first "&" is inclusive, while the second operates to exclude those objects for which the statement is false.

 

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