P Retondo

Resistance is futile! Has any thought been given to the idea of nomenclature tables? In this concept each part of VW would have variables assigned to the key words that show up in dialog boxes, etc. These variables would each map to a member of a nomenclature table, and a variety of tables could be made available for various markets and standards: Germany, IFC, Australia, etc., including a user-built custom table. Thus, for the US market "Department" would be part of the US institutional nomenclature, where "Bureau" or whatever is appropriate would be the equivalent term for the UK nomenclature table. It's the verbal equivalent of a color (colour) palette. Yes, we are growing towards a more interactive/interoperative environment, but with the power of intelligent programming we can still have flexibility and customization. I know that some have complained lately about incorrect terminology in the Window PIOs. I'd be willing to bet that many of the terms are standard in one market and inappropriate in others. The nomenclature table concept gives the user the power to work around what are perceived to be inappropriate terms, while still allowing VW to promulgate its best compilation of terms appropriate to multiple markets and standards. It also makes it possible to ship VW with different options selected for different markets, making it easier for users to get up and running without fussing with arcane settings, while at the same time allowing the opportunity for fussy customization when the user is ready to pay attention to such issues.

Christiaan, "Department" is one of those north american MacMansion concepts. I like your idea, particularly as it might be extended to a variety of other PIOs, like the oft-maligned "Stlye-1" . . . class names.

Katie, I know everyone at NNA is super busy, and you're probably at the limit - but to implement your idea, I wonder if it would be possible to dedicate a couple of forums (fora?) on this board to specific issues, so that you could accumulate the wisdom of a variety of users and so that we could all benefit from the dialog and refinement that would generate?

256 MB RAM is going to cause you big problems. Most of that is taken up just running the system and storing the program and your document. 800 MHz is going to be frustrating as well, unless you're doing strictly 2d work with no images.

The problem is that those loci (even if they are locked!) are going to disappear if changes are made in the contributor WGR file. Then VW completely rewrites the WGR layers. To get your loci to stick, you will need to create a layer link to the WRG layer in another layer resident in the container file, put the loci there, and use that layer containing the link in the VP.

Bring the 4 files into a single container file via WGR, make layer links of the referenced layers that need to be rotated, and after unlocking the links move and rotate them appropriately. The referenced layers will update, and the layer links will update and maintain their rotation. Be sure to have unique layer, class and resource (including symbol) names in the four separate building files. Some of your common resources, such as textures and stock symbols, can have common names, as long as you maintain discipline so that when VW asks to update one of those you aren't writing over something you don't want changed.

If you want to create a hole in a roof object, first create a rectangle or polygon that outlines the hole you want. Copy it. Then "edit" the roof object with the "Edit Group" by keying , paste your polygon in, and "Exit Group." Use a similar process to edit a roof face.

My dual core uses ~100% processor for final RenderWorks. I have hyperthreading enabled.

AZ, RenderWorks should be using approx. 100% processor. Other rendering modes will only use 25% (we'd like to see NNA fix that). When you look at a RW rendering in process on the screen, you should see the multiple threads at work as the rendering takes place in 3 to 4 horizontal bands at once. Your dual core is emulating 4 cores, that's why with other processes that can't hyperthread you're getting 25% performance.

Nicholas, we agree - if VW can meet the needs of product designers, all the better for architects!

Nicholas, as an architect I use and appreciate the window/door/wall objects. But I agree with you wholeheartedly, and many architects would also agree, that robust NURBS modeling would increase the attraction to VectorWorks. ArchiCAD doesn't have NURBS at all, nor AutoCAD ADT. And what Rhino specifically lacks is the separate 2d space that is always present in VW, no matter what the 3d view, and that allows us to construct extrudes, 3d polys and NURBS curves with precision in any orientation. Maybe Calatrava is going to use a more expensive and sophisticated program than VectorWorks, but if I were NNA my goal would be to provide a program that could meet the sculptural needs of architecture. VW already has a leg up, it's good to build on strengths, and freeform expression is the wave of the immediate future.

Nicholas, Rhino is a great program - but the last time I used it I had trouble accurately creating the kind of objects I wanted because of the lack of a 2d/3d interface. I wish we could get VW 2.5D (i.e., extruded objects) combined with Rhino's NURBS power.

I note that you are on version 12.5. I'm not positive, but I believe that 12.5.1 contains a fix regarding this issue, if I understand correctly what you are referring to.

Good suggestions. I had a 350MB file that became 35MB after turning off "cache Viewports." The only problem is having to regenerate those viewports. I hope that at some point VW implements an incremental document save so that with adequate RAM we can deal with the larger file size.

Mike, you're being too generous. AutoCAD has a couple of features, such as move and copy by vector, that VW lacks, but one simple fact puts VW way ahead in terms of productivity: it is not necessary to hit after every command. Add the 3d/2d interface that VW has mastered from very early on, and I find that my productivity in VW surpasses ACAD, which I used for 3 years, by a significant margin. Fortunately, I learned MiniCAD first and didn't have to deal with reconfiguring mental pathways. I find that most ACAD users have trouble at the conceptual level when learning VW.

Jeff, not quite sure I understand your question. (0,0,0) will be the same in both files.

Christiaan, I believe those lines extending into the sill are zero-thickness jambs. Like you, I think that a major overhaul of the window and door PIOs would be a tremendous boost to VW's utility and sales. I hope that NNA agree and follow through with a thorough job of polling architects in the trenches and in different regions to come up with something spectacular.

Nicholas and Thom, I agree that we need a better way to control the generation of contours. Control points come to mind as a concept. It would be good, also, to come up with a more refined and interactive method for creating proposed contours.

Peter, this is real simple and doesn't require you to change your class structure. Set up a Viewport on top of and registered with your "main" viewport. In that VP, activate only the LAYER you want to be your background info, i.e., your base plan. Then, in that VP only, edit ALL the visible classes to change the pen color to gray. If you have only one class, that's okay, just make that one class gray. And yes, your classes must be checked "Use at Creation" for the over-ride in VPs to work. But whether or not you are using symbols, this method will still make everything gray provided that you edit all the classes indicated as visible in the Viewport. Your individual object line thicknesses should hold (I haven't tested, but when you change an object's lineweight, you change it from "Use class" to a specific value, so editing class attributes should leave that alone). Then send your VP to the back, and your background will show all objects gray. The easiest way to create a registered Viewport is to duplicate the existing foreground VP, then edit the layers so that only the background "base plan" layer and all the appropriate classes are visible. With Jonathan's advice about simultaneous class edits, this should be almost as fast as the method you'd rather have.

mm, check out this discussion for a work-around: http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=80336&page=1#Post80336

Jonathan, didn't know you could edit attributes for multiple classes at once. Brilliant! Thanks, this makes it a piece of cake.

Peter, your desire to control the "standard" gray is a good idea. Short of being able to do that, since it is not now possible, you can resort to the following procedure. It's tedious, but can be replicated once done: create an overlapping viewport. In that viewport, with the desired layers visible, override all the visible class pen colors with the gray you desire. It's tedious because you have to edit classes individually. If you have someone who can create Vector Scripts, I would think this chore could be automated.

Bruce, try converting your curved walls to NURBS surfaces first. I don't know how this will be treated by the IGS translator, but it's worth a try.

Don, you probably feel the way I felt that last two or three times I had someone on this board point me to that same solution!

Don, double check your class view settings. When you are looking at the model layer, you may have certain classes turned "invisible" which will supress their display.