P Retondo

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?

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!

My wish: you should be able to move the origin of an associative hatch by means of a tool that allows dragging the hatch pattern after it is placed.

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.

Kyle, check out this discussion of the problem: Hatch technique The second post in this thread shows a method for accurately placing a non-associative hatch.

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.

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.

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.

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.

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.

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.

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.

Out of curiosity, what is driving you to use groups more?

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.

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.

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.

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.

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.

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.

Jim, are you saying one can use the eyedropper tool to modify class attributes? How is that done?

Yes, Katie, thanks! Is this really possible? I mean, I know it is possible, but is it a realistic request (rhetorical question)?

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!

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.

Peter, I wasn't giving you a hard time, just taking the opportunity to harp on one of my perennial complaints!

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!