P Retondo

Dave, my core duo processor has two cores, but emulates a quad core. So having multiple physical cores may not necessarily eliminate the value of hyperthreading. carpalmer, I believe that hyperthreading is enabled/disabled in the BIOS setup, assuming that you are on a PC. Don't know about the Mac.

Brian, select the Section VP object, and look in the OIP for the button called "Section line instances." Click on that, and you can choose where you want the section line to be displayed.

Katie's method is what I would ordinarily use. Two other possibilities: 1) create a custom symbol composed of 3d polygons. That way you can control the textures applied to the the cutting surfaces. 2) Reshape the wall, adding vertices to create the door-like opening (works only if the opening is bounded on 3 sides, not 4).

Very sensitive and insightful comments throughout. One thing to bear in mind is that in our competitive world, NNA cannot always keep everyone abreast of what they are developing. I would say that over a period of years their record speaks for itself - they do take into account user feedback, through this board and other sources, and have incorporated many features and fixed many bugs that have been aired on this board. I would hazard the guess that many of the "half-baked" features, such as framing member objects, were developed so that other programs would not have sole bragging rights. But, caught up in budgeting realities, they couldn't do the job that we, and most likely NNA as well, would be happier with. I think it is correct to observe that too much of this kind of thing can tip a delicate balance and start turning users off. One of the things we can do for ourselves in these forums (that NNA would not be able to do for marketing reasons) is identify those new features that don't particularly work well. We can save each other a lot of trial-and-error time that way.

For typical wood construction, I agree with the details of digital's comments. This would make the display of a stairs object much easier to handle. Pete A. is technically correct about how wood stairs are typically constructed. I think Pete would agree, though, with digital's description of top step detailing. But often the whole top tread and stringer are actually built so that the top tread is co-planar with a floor, typical with many steel-framed stairs in concrete slab construction. So construction detailing is not necessarily consistent across building types. In this case, where the top tread of a stairs is often actually prefabricated as part of the unit, the current system in VW would be more apropos. Islandmon, is this what you are thinking?

drawwhat, you should also think about using the viewport annotation space as a kind of layer. This is a bit confusing to a new user, as the viewport capabilities were added on top of a system that had already evolved. The result is that there are now several ways to accomplish the same thing, but I find that putting dimensions in a viewport is a way of keeping clutter out of the design space. Others find that the lack of dimension association (which only works if the dimensions are in the same layer as the objects) is reason to avoid this method. But, like I say, there are a multitude of different ways of working with VW, each with its own pros and cons. The earlier comment about using layers as a way of having objects with different "scales" simultaneously visible on the screen is evidence of the way we used to use layers to compose a sheet of drawings. Nowadays, depending on how up-to-date your version is, most users employ viewports and "Sheet Layers" to compose sheets of drawings, and the scale attribute of a layer is no longer so centrally important.

Petri, so keeping the Basenjis in line isn't keeping you busy enough. Glad to see your name back on the board! As is evident from the variety of replies, Layers and Classes are somewhat flexible and can be used within a variety of organization systems. At root, they are two very similar organizing concepts - technically, they are object attributes attached to each object in your file, and you can assign both a layer and a class to every object. (Actually, you must assign both layer and class to every object - there are defaults that automatically assign them to every object created, and you can reassign these attributes at will). If you visualize all objects with the "layer-1" attribute bounded as in a Venn diagram, you can see how the layer can be called a "container," but I think that particular term should be reserved for things like the "group," which is actually an object (in that it can be cut and pasted, unlike a layer or class). Layers have special capabilities that make them different from classes (i.e., things like z value and +/- z). The designers of VW have conceptualized them as a way to organize a building into stories, as Petri points out. I commonly use several layers to define one story, as I probably don't want to see furnishings in my final drawing but would during design work. But I could equally well assign a class to furnishings, and turn off that class (like freezing a layer) in my viewport. One of the particularly useful properties of a layer is that a symbol on a layer different from your walls cannot "enter" the wall. So, if you place a toilet symbol next to a wall in your main walls layer, it will get "sucked" into the wall and create an opening in it - as though it were a window or door. But create a layer for equipment, put it there, and you won't have that problem. Layers also have the property that you can change an object's layer assignment by cutting it and pasting it into a different layer. You can't do that with a class. (Classes must be reassigned via the OIP, and you can reassign layers by that method also if you want to.) This special property of layers is related to the way in which layers interact with your current screen. The current view can be defined through layer visibility control, but beyond that, the active layer is the one in which every object is placed when pasted (and, by default, every created object is placed).

Create a polygon that engulfs the vertices to be deleted, and add that to your original shape. Not to dismiss the requested functionality - I think it would be great to be able to select multiple vertices and delete. In addition, I'd like to be able to thin the number of vertices in a poly- object. For example, surveyor's contours often come in to VW with hundreds of vertices where tens would do the job. So my request is that we have a utility that will cull vertices - for example, select an object and cut out 4 of every 5 vertices, and also, select a set of vertices within an object and do the same.

Pete, true, but for ease of modeling I agree that showing the top riser would save a bunch of time.

Lucy, I use a 3d polygon - just make a rectangle, convert it to a 3d poly, set it at the height you want, and use the "fit walls to roof" command as you would normally. This is faster than editing a bunch of walls individually, as Pete has suggested. For one or two walls, his way is faster.

Hear hear! I believe the video processor is used in rendering images. Also it's not just Macs that have multiple processors and suffer from sub-optimal resource management.

DB, I wasn't aware that selecting an object confined smart cursor cues and dragging to that object. It's actually a pretty good idea, and should be added to the wish list. As far as stretching is concerned, yes, the selected object is the one affected when using the resize cursor. But with dragging the object, no - the foreground object is the one affected. There may be some issue associated with confining resizing and dragging both to a selected object, but I can't think of one right now. For consistency, the program should behave as DB suggests. Subtle changes like this in the way VW operates can make a huge difference in everyday workflow.

That line is a zero-thickness jamb. Use Robert's advice by going to the "Settings" window - you will get good results. If you convert the PIO to a group, you will lose the 3d information.

Jim, edit the "Section style" class to a lesser lineweight.

Gideon, there's a column tool.

Ray, thanks, I'll keep an eye out for that one!

Try using the method Peter Cipes describes, which I basically use as well: Cipes elevation method This takes advantage of textures and shadows to convey a lot of information, and one generally gets faster more informative results than using the traditional lines-only method.

Janis, I use the Section Viewport tool to create interior elevations. Create a polygon using the polygon fill tool to define the boundary of the rooms, and use that to clip the viewport. I'm not sure how a dedicated interior elevation tool could be faster and more efficient. What is needed right now is a series of refinements to the Section Viewport tool. One of the biggest problems with this method is common to all Viewports - the additional filesize overhead associated with the Viewport cache.

I'd like to have the option to cache a screen-resolution version of viewports, with full print-resolution versions automatically updated when printing. Right now we have the choice between 1) caching viewports (normally set to at least 300 dpi for good output), which results in enormous file sizes, or 2) not, which makes it difficult to work with viewports as they have to be regenerated frequently. Both are time-consuming situations. Large filesize makes saving your work, which I tend to do every 100 operations, a lengthy process. Updating viewports whenever a file is closed and opened is also very time consuming, but I tend to chose not to cache viewports because on balance this option takes slightly less out of my day. I believe that a screen resolution cache (72 dpi?) would solve these problems, and I think it should be implemented on a viewport-by-viewport basis.

Olly, for now to make parameter changes on more than one window at a time the workaround is to use a 3rd party utility, "Info Editor," available from SofwareCustomizationServices.com at a very reasonable cost. I finally broke down and purchased Info Editor after being given the same advice over and over, and I've saved literally hours of time.

Christiaan, I agree for the most part, but I wouldn't call it a "McMansion" phenomenon. It's more like simple standardization. I think the basic solution in that regard is to go beyond US manufacturers and get more kinds of window types into the library, and to integrate those with the PIOs. I've used windows from Sweden and Italy, as well as a fair representation of US manufacturers, and I don't think it would be far-fetched to bring more types into the fold. Plus, the PIOs could make it much easier to customize things. Regarding the stairs PIO, to my mind it's not a matter of two stories versus many - it's anything beyond a single story. The stairs PIO needs to be able to handle displaying information on more than one floor using a single object. I'm hoping we'll be able to put ideas out in the context of a focused wish-list thread pretty soon. We could probably write a small book outlining how we think intelligent parametric objects would work. Fortunately for us, it seems the engineers at NNA basically agree that the current tools are a work in progress, and are making efforts to institute some fundamental improvements.

Christiaan, I note your recent accusations regarding the "McMansion market," and without suggesting I have evidence against that and without for a second disagreeing with the need to revamp the window and door PIOs, I wonder what the basis of this McMansion thing is? It's a fact that there are McMansion architects and drafting services out there, and that at least some of them use VW - nothing wrong there (I'd rather have them support VW than some other software), though I'm not particularly impressed by the architecture that results nor interested in the fast-food equivalent of design. But where is the evidence that VW is tailoring the program to that market? Frankly, I don't think there are that many "seats" in that sector. And what part does BIM play in that market? Very little to none, I would say. BIM is a creature of institutional clients.

Carl, I've submitted a bug report about this. This is particularly a problem when the door threshold is lower than the wall, which occurs typically in a garage man-door, and other situations. This problem is also responsible for those false thresholds that show up in interior renderings. Robert A. has recommended raising floors by a fraction of an inch to obscure those, but one hopes that is a temporary workaround as it plays havoc with accuracy in sections. There is a workaround where one needs to drop the door below the wall. Edit the wall using 3d reshape tool to bring a portion of it down to the bottom of the door. See attached image for before-and-after results.

Christiaan, I get your point about Wikis. On the ohter hand, I'd say that it would be a big step to get some focused discussion going, as Katie says she can do with the resources available to her. If it at some point it looks as though the Wiki format is needed to sharpen the focus, maybe NNA would be willing to work on that. What I envision as key (and acknowledging the oligarchy we're dealing with, i.e., Katie and her colleagues run the company!), is that NNA at some point would post what their engineers consider to be the design direction for the next generation Window & Door PIOs. Call it a kind of open engineering experiment in software design where end users could participate BEFORE everything gets locked into millions of lines of code.

Jeffrey, this is excellent news and your approach is thoughtful and understandable. The bug submittal route is a very useful tool, but I think that an open dialog could be incredibly helpful as well. Christiaan, by a Wiki do you mean an online document that can be edited by anyone? So that your ideas could be modified or deleted by someone else, and no trace would be left of them? I'd rather see a series of threads, and, if NNA has the resources, a software design guide that incorporates what are perceived as the best ideas and directions, that would evolve and provoke additional thoughts and comments. For starters, I'd suggest that Windows & Doors, Worksheets, and Section Viewports would be interesting topics.