Chad McNeely

Those didn't go straight up. The tread is 3", the rise 15" (so about 21" front to back needed), open riser setting, stringers on the side, I think 1 1/2" wide by 11" high (VW seems to measure stringers in a vertical rather than perpendicular dimension). The stair tool won't do vertical (I don't think, unless you can set the treads to 0" and the nosing overhang to the full tread depth, but the risers wouldn't work per above?). For vertical, you'd need two rails/stringers extruded in plan view, and a tread extruded between them. Duplicate (or duplicate array) the tread to get a distribution that works. Group it all/add solids/make it a symbol as suits you.

Sounds like you're working through the 2d versus 3d aspects of VW. What you draw in 2d stays on the screen plane. So, from a view that looks straight at the window, draw your window part outlines and extrude them. (I reserve extruding along path for times when it's really needed). Things extrude perpendicular to the plane of the screen at the time the command is invoked (try it a few times in different views to get familiar). "Cleaning up" would be drawing polygons from the side or top, extruding them, (verifying their placement from another view), and subtracting them from the main geometry. I don't do instruction for hire (I know some here do!), but feel free to post what you have and somebody will help you out, I'm sure. This isn't very tough stuff- I think you just have a few conceptual hurdles to plow through.

What is the question/ which post are you referring to?

Here's a quick version, just to verify that it can work with the fillet all the way around the roof surface intersections. (warts include no fascia, non-plumb fascia, left over geometry on the inside, no roof surface cutout, no window, etc.) The steps here are to extrude an arc-shaped surface, tilt it, create a planar thin surface over your actual roof surface (use 3d poly tool in an isometric view, snap to roof corners, then tapered extrude, say 1/2", taper=0; or any of several other methods), add roof surface and dormer geometry using Model>Add Solids, select the fillet tool in the 3d modelling pallett, select the parobolic valley line, choose radius, press check mark. Next clean up with various solid subtractions to get rid of the warts.

In a plan view, trace the surface to be dimensioned with an arc (red in attched example), copy the arc length from the OIP, convert the arc to a dimension (use the line style that looks like "---XX---"), move the radial dimension off the object as appropriate, uncheck "Show Dimension Value", paste into the "Leader" field the arc length copied previously, add witness lines, done.

Two extrudes, multiplied and placed as needed? Or monkeying with the stair tool, gets this:

This is one done in VW10 or so, although with the fillet/blend to the adjacent roof surface only at the front, not up around the valley/intersection. I have my copies of both 2008 and 2009 locked up with renders for a while, so can't check how the fillet tool might work from this shape to the planar roof portion, but I suspect it could be made to work. Getting the roof texture to map correctly would likely be the hardest part. This was done with an "omega"-shaped extrude (see wireframe pic, of the step just before solid subtracting), rotated to the desired slope, and then an extrude is made to match the roof slope and provide the plumb face, and the one solid subtracted from the other.

OK, it seems whenever I create a schedule, it asks what record-based objects I want to point to. I'll dig a little harder to figure out the non-record criteria bit. I used CriteriaArea in the first post question, and was getting either the area or double the area for different floors. I've since rebuilt the floors, and am getting consistent double area, so adding /2 has given me a workable solution for now. Thanks.

and to further clarify, I'm looking for area to outside of walls, as would be reported on a site plan. Not individual room areas. I don't see a way of accomplishing that with the automatic updating version of the space tool. I have converted a copy of the floor poly into a space object (classed invisible), which then needs editing (and remembering!) with each change.

...which I had done previously. I thought it would be cleaner, and especially more error-proof, to use the actual floors. I *have* to move them as my plan progresses, and it's tedious and easy to forget to move the space objects as well. Now that I don't have to inset my floors to allow for an additional textured bit on the edges, the floors seem even more useful for this. Is that unreasonable?

As far as I can tell, there isn't a pre-made floor area worksheet. I created a floor area record and attached it to my floor objects. The worksheet reports area correctly on some, but double on others. Any ideas why?

Hmm, on second thought, if this is how fascia hangs on the roof object, maybe I really should stick to building my own. On the bright side, the fascia just disappears if I move the roof in the z direction, saving me the trouble I guess.

I was just a bit miffed when I let the computer grind all night on a revised set of renders, only to learn that the new texture didn't take on the portions of the roof that were roof faces, rather than roof objects. That they would un-assign the roof tab to no longer include roof faces is just frustrating. I've long asked that the features (fascia, etc.) that apply to roof objects be available for the more flexible roof faces, as well. This seems to signal a move in quite the opposite direction...

Here's one.

To set a roof to texture by class, I set the class "roof" tab to the desired texture. New for 2009, "roof faces" are no longer controlled this way and will take on the texture assigned to the "Other" tab. But "roofs" do use the "roof" tab...

Not Acad related, but since this thread is mostly about VW snapping, my (devalued) $.02: After a month or so of 2009'ing, the snap improvements just don't seem to be happening for me. Things I think need improvement: 1. A vertex can not be selected while inside the snap loupe, for instance to begin a non-marquee 2d reshape. 2. Snapping often occurs to invisible-classed objects. If we're going to use walls with finish components, we need to be able to turn them completely off for structural plans (for instance), so that snaps don't still see them. 3. Similarly, when drawing in the annotation space of a rendered viewport, VW seems to prioritize the background information behind the render, and I end up with a dozen "smart points" around (for instance) a window corner of the render that "should" offer a clean snap. 4. There should be a very slight pause or fade-out of the snap loupe, so that I can tell if the desired snap "took" or not. Currently, when a snap is clicked inside the loupe, the loupe instantly closes and the mouse jumps to it's normal-scale location. It doesn't instill confidence that the desired snap was used, and I often go back to check. 5. Holding the shift key while drawing seems to have been de-powered. It used to quite firmly constrain the cursor to the user set angles (i.e. 0, 45, 90), or matching the angle on which the tool began. But now I frequently get constrain lines at odd angles. 6. Shift-selecting sequential (large or complex) objects. If I have a page of several viewports and want to select a few, VW often disconnects the fact that the shift key was selected at the time the cursor was clicked. That is, I have to hold the shift key for as long as it takes for the selection to "take" (often several seconds), rather than only at the instant the item is actually selected with the cursor. Overall, I see 2009 trying harder to obtain snaps, but not being much more effective than 2008. The snapping process is a lot busier on the screen, but it still frequently snaps to phantom objects instead of corners/line ends. It will show me the mid-point between two points separated by a mere few pixels on screen. When hovering around a point to snap, it seems too focused on acquiring nearby alternate snaps rather than finding the obvious one right under the cursor. The longer I hover, the busier the snap choice population becomes. I remember earlier versions of VW (say through v9) having such a more positive feel. I realize more drawing complexity creates more stuff on our drawings, but the continual updating of the object complexity is not being matched by similar quality snapping tools.

Ditto, almost exactly my experience as well. I've turned off most of the cuttlefish-in-heat flashing wiz-bangs, which helped ordinary drawing. But working within and around large-project viewports is quite painful.

Dunno about the resource browser business, but assuming you're using it to fetch a pre-made stair PIO (instead of just clicking on the stair tool), or if this is the first time the tool is called, I think it brings up a RB-like window of choices? Anyway... Place the stair in your drawing. With it still selected, choose "Settings" in the OIP. A big ol window will open with lots of choices. After sifting through the first page, choose the Flights and Platforms tab, and then add and subtract flights and landings until you have what you need. Continue on with the rest of the tabs to see what else you can fiddle with...

What have you already tried, and had trouble with? i.e., is this a design or code question, are you modelling them with solids, can you not find the Stair tool (or the settings button therein), can you not find them when typing "stair" into VW help? Lots of possible answers...

I've found that such a converted nurbs often causes a failure, although that's mostly in 2008 and prior.

AAARGH! I'm NOT saying converting the path to nurbs in and of itself is a bad thing, just the way that I CAN'T substitute a path object identical to the one used to create the object while in the edit mode. This in no way limits our ability to continue to use a nurbs for handrails and other non-planar paths. delete the nurbs, exit, and you'd be done, if VW treated the pasted path "properly".... ...thus eliminating all this: Where this gets tedious is where a complex path gets a bunch of its vertices moved. Say, one exterior wall of a building with lots of relief/indents gets moved, and I've used the same path with various profiles (offset from the profile origin, obviously) for gutter, fascia, and soffit. It's easy to move large groups of vertices with the 2d reshape tool, but we must do them one at a time with the 3d reshaper. Or use Pat's or Wes' "around the block to get next door" workarounds.

I think that should be my issue to deal with. If I have a planar path that was created from a 2d poly, the EAP command should not act as a one-way filter preventing me from using one again upon editing. IF I am using 3d geometry for my path, I certainly wouldn't expect to be able to substitute a 2d path and get the same result, but I don't think VW should then just fail to create a shape.

Uh, yeah, sure. Like I said, it would be nice if it was easier to be able to reshape the path. Most other solid objects can be edited to their primitives, which can be adjusted or have adjusted substitutes put in place, and the solid object will still be valid. Not so with the EAP. If the EAP can take a 2d path object and convert it to a nurbs path at the time of creation, it sure should be able to do so during an edit.

Yes, the path is defined as the geometric center of the profile at creation, and must be modified afterwards. You can enter the EAP after creation and move, modify or even swap out the profile. The path is much more difficult to adjust (one of my long standing gripes). VW turns the path into a nurbs curve, so 2d tools no longer apply. It would be REALLY nice if we could substitute a revised 2d poly for instance (just like we can with the profile), or if we could add a corner vertex in some rational manner, or use the marquee-move of the reshape tool on the nurbs vertices.

I like simple extrudes of closed double line polys, since editing them is so much easier than extrude along path. And then subtracting solids as you suggest for openings and such. I've found grouping walls for this purpose doesn't sufficiently insulate them from interaction with other walls, even when "locking" the group.