P Retondo

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.

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.

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.

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.

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.

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.

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.

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.

Remind me not to take up practice in the UK.

Robert and wezel, thanks - got it! One final question. Now that I can see my doors in order, I find that doors which are incorporated into a symbol have tags on the drawing, but they don't show up in the schedule. The criteria argument for the database is: =DATABASE(((R IN ['Door']) & (Door.OnSched=TRUE))) How do I edit this to include door objects with ID tags that are part of a symbol in a wall? My workaround is to copy the door PIO instance to another layer.

My window schedule has automatically sorted the windows based on ID label number. My door schedule seems to be randomly sorted - is there any way to cause it to sort on the ID label?

In the Window PIO there is a field for "Sash operation" that is set to "Custom" when we have a multiple-unit window. That designation is particularly unhelpful when we generate a window schedule. It would be better if it could be set, for example, to "Casement/Casement". I think it might be best to have a separate field that could be edited, and that would be the source of the data for the schedule (I do that now as a workaround, and use a user data field). This field would be automatically filled with the "Operation" text string, but could be edited without changing the actual window geometry. I would distinguish this field from the one that sets the window geometry by calling the latter "Type."

I find that one of the biggest drawbacks to the new Viewport capability is that filesize, if the Viewport image is cached, becomes incredibly large. That in itself would not be an issue if it weren't for the fact that intermediate "saves" require writing the whole file. I have a very moderate project that has a 350MB filesize and takes over a minute to save on a relatively fast computer. With a database structure, saves can easily be made incremental. Only objects that are changed are saved. In fact, for many SQL-based accounting programs saves are almost instantaneous and automatic. I just think the reasons to go to a database file management system are inexorably compelling. I'm not sure how ArchiCAD is structured (anyone know?), but in a typical database system the file or files are accessed by the "master" process, and can have inscrutable and irrelevant actual filenames. The master process catalogs all objects, and handles save and other management requests from workstations on an object-by-object basis (in the case of accounting and other typical database systems, these objects are records).

Say what you will, I find that Petri is both entertaining and informative. That he manages to insult almost everyone in the process - well, it's the other side of the coin. I would welcome, though, a return to substance on his part. When he's correct in his analysis, the humor is devastatingly funny. On the other hand, hurling an insult in the process of missing the mark factually or intellectually falls a bit flat on a tech support board.

Here's the primer on converting 3d views to elevation drawings: Create elevations by Peter Cipes

We were discussing this issue recently in the context of what ArchiCAD does. I talked to a friend of my who is an SQL programmer, and he verified that the file structure of such a database is actually hidden behind the scenes, and that the user typically interacts with software running on the server to coordinate changes to records so that users don't write over each other. So while this is possible to do, it requires another software level and changes the nature of the file format and structure. I don't think VW will make it to the future in the big leagues if they don't bite the bullet and work towards this capability.

Given the uncertainty about exactly what brand of window and door we will end up with, I always dimension doors and windows to centerline, and provide a schedule that gives the (at least hoped-for) unit dimensions. Here in the US residential / small commercial market, the contractor always has a "better idea" (i.e., more convenient, more familiar, more profitable for the contractor - spoken as a former contractor). However, even if we had certainty about unit sizes, I would still dimension to the center of the unit and refer the contractor to the window / door schedules for the actual frame sizes. Contractors commonly want to control their own shim space tolerances.

Matthew, class setting is beside the point. When the program renders the degree of darkening differently between one transparent 3d surface and multiple surfaces, this problem will arise because the number of transparent surfaces in different PIO instances varies.

I use styles to define the basic geometry of the wall type, and classes to distinguish between new and existing. Duplicate an existing style in the resources browser to create something new, and edit the components.

I'd like the resource browser to work more like a normal file browser - i.e., beside having the long-ago requested "Back" and "Up one level" buttons, and collapsible folders (including the main file folder), I'd like to be able to drag a resource from one folder to another, and to copy and paste using and . As it is now, I have to make my destination file active in the VW draw window, go into the resource file's folder, "import" the desired resource, then go back to my destination file's resource browser, find the imported resource, and move it to the folder I want it to be in. The navigation overhead could be considerably streamlined! And is this a good time to repeat again what a pain it is that every time I switch from one .mcd file to another, find a resource and click on it, the resource browser jumps back to the top of the list instead of highlighting the selected file?

What is the advantage of a hybrid group? As opposed to a symbol.

Check your Task Manager, and you will see that except for RenderWorks rendering VW uses only about 25% of the processor (if you have a quad core or quad emulation). 64 bit technology has a 64 channel bus, so you have the potential for greater computing speed. But it's up to programmers to find ways of using that potential. I don't think that "64 bit precision" is going to have the kind of traction that "32 bit precision" had a few years back, so the question is, can they find a way of using the greater bandwidth? I suspect they are on top of it, but I don't know enough to know what or how.

Actually, the best thing about the suggestion is enabling all the processors to work at once. 64 bit opens twice as many data channels for each calculation, so theoretically it should perform faster. I believe there are ways of using that potential for things other than increased precision. But a lot of code has to be written before that could happen, so in the short term I'm not sure we're going to see any tangible results from 64 bit.

Pete, I haven't run into that problem, and it sounds like something is wacky. With the new window settings you can assign a class to each of the parts. I'd try that, and give each a texture. Window Settings -> View -> Special Classes. Or it could be that you need to give the window a fill - although a window without a fill usually causes OpenGL to render it as a wireframe. Be forewarned that WinDoor uses a single 3d poly for glazing, and VW has multiple surfaces, so darkening with a smoked glass, etc., will be different.

I'd like to see the "Update all Viewports" command fixed. Mine fails every time: "aborted due to lack of memory." The command should sequentially go through all viewports, update each one and FREE ALL MEMORY associated with the update before moving on to the next viewport. I can update my viewports one at a time, but doing so is quite time consuming. I'd like to issue a command and walk away to do something else, and come back an hour later to have everything completed.