Chad McNeely

Oooh, and one other 'amusing' feature: I often use symbols for complex door or window assemblies, things that can't be done with a simple door or window object. When multiple door objects are within a symbol - say a a cased opening to report the overall size of the door to the schedule and inside the cased opening maybe a couple of sliders stacked to show a multi-slide effect, with maybe a lintel and some 3d loci at the corners, the contents of the symbol can self-replicate many times - sometimes 8 or 90 copies of each individual component. Why?

I've been VW-ing for over 20 years. A couple things have gotten steadily more annoying recently. Maybe it's me, not keeping up with the latest methods? --I notice that roof surfaces often disappear in wireframe modes (i.e., other than Top/Plan). Sometimes zooming in or out will make them briefly appear, sometimes not. I can select them and they highlight, but disappear as soon as I try to do something else, like draw. --Roof surfaces won't accept class line weights or viewport overrides in line-rendered modes. --While editing roof surfaces or floor objects, the 2D drawing environment often glitches into a different working plane, making snapping to other geometry impossible, and objects that are drawn are shifted many feet from the cursor location. --Cursor-then-paste doesn't place 3D objects at the cursor point, but often some off-the-page location. I thought these were graphic issues due to driving an old MacPro 2009, but having gotten one of Apple's latest with a VW-compatible graphics card, etc., I'm guessing it's something else! -Chad VWA2022 2019 iMac, OS13.4.1 Radeon Pro Vega 48 8 G

bump? Still the same in 2021?

This has been happening to me for a couple years - I at 1st assumed it was a graphics issue with an older computer ('09 Mac Pro), and was hugely disappointed when it persisted after buying a new iMac. This is with any renderworks-based render; OpenGL and line render modes are fine. It's definitely not a class issue - the same viewports will render properly, then later in the day the walls will not render. It's not very fun when re-rendering an entire file's worth of viewports overnight, only to find them worthless in the morning! When I remember to, I'll test just one VP, and if they fail one sometimes-fix is to go to the wall's design layer, zoom in somewhere to limit render time, and use "fast renderworks" to try to get VW to re-remember ("bump" the software, as said above) to treat the wall textures with more respect. Otherwise, sometimes a VW restart works, and sometimes a computer restart is needed. Wall-less.pdf

Hi, my use of VW has been a little lighter than in years past, so I thought some of these might be my being a little rusty, or no longer a mega user. These are things I've seen across multiple generations of VW, and persisted from an upgrade from an old Mac Pro to a new iMac. I've skimmed through "known issues" and not seen these raised. With roof surfaces, the geometry/linework disappears in a non-plan wireframe view. I can only get it to consistently show if the roof layer is greyed while another layer is fully visible or active. Even if the roof layer is active, the surfaces disappear unless selected. I've seen this through multiple VW versions and across a computer/graphic card update. (I thought it was my old Mac Pro and its old graphic cards, and was hugely disappointed to see it wasn't!) If I use a wall cavity for the exterior finish -siding, stucco, whatever- it will frequently not render in pictorial renders. It's as if the 1" cavity is "flattened" against the internal cavity. Other non-wall shapes then appear to sit proud of the non-rendered wall cavity. Sometimes I can go to the design layer and fast-render the walls, then return to the viewport and it'll work, but it seems more often to require VW restarts or computer restarts, and that is also iffy. Again, I hoped it was an old graphics card issue, but it persists. Using a renderworks texture with a surface hatch, the hidden line and rendered versions often conflict. An extrude's sides will have brick/stone/whatever running vertically, while the rendered version is horizontal, for instance. VW has changed its 3d interface a lot over the years, and I'll lodge my vote here to revert to earlier modes. Some troublesome examples include: --For hybrid objects, when editing the underlying 2d source object, VW somewhat arbitrarily switches to a special 3d view that makes snapping to other items impossible, or places newly drawn items some place other than where the cursor is on the screen. If I'm drawing/editing a 2d shape, I can't fathom the logic of VW doing this. A similar thing happens when editing symbols, where the view switches to one that prevents external snapping to reference geometry. --I find that top view is often significantly displaced from plan view. --When pasting geometry -created outside of a symbol- inside a symbol, using a click of the cursor to indicate the (general) intended paste location, VW instead pastes the items way outside the current view. Any ideas? Simple examples of the disappearing vs. selected roof faces, and the flat-rendered outer wall cavity are attached. Screen Shot 2021-02-17 at 4.31.44 PM.pdf Screen Shot 2021-02-17 at 4.29.23 PM.pdf Screen Shot 2021-02-17 at 4.32.27 PM.pdf Screen Shot 2021-02-17 at 4.28.20 PM.pdf

Hi All, It's been a while since I was on these forums, and I've done a couple of searches to see if this is a common problem, so please forgive me if it's been discussed recently and just eluded me! For the last few versions of VW, since the Attribute palette took on the form it now has, the line type previews are not at all helpful. Here's a screen shot of what I mean: Screen Shot 2017-11-14 at 1.15.27 PM.pdf There are three versions of the line shown here, and the two "previews" in the palette are nothing like what is shown on the drawing. Basically, the palette is of no help in selecting a line type -I need to just pick one, exit, see what it looks like on the drawing, and repeat until by luck I find the one I need. (Yes, most lines are drawn by class so this is only done occasionally, but it still feels like a big potentially useful palette and its preview windows are completely wasted when I do need to choose a line type.) Thanks for any help! -Chad

Piling on to the "bring back the custom stair tool" bandwagon. I lost a bunch of nicely working custom stairs with the 2016 upgrade, and now have no real way to build them. Frustrated.

Another easy way to do standing seams is to duplicate your roof faces (ungroup your "roof" if you used that tool successfully), change the roof thickness to something like 2", raise the roof surface so it sits on top, then edit the roof surface. With the source polygon in front of you, draw the space between two ribs, say 15 1/2" wide for a 1/2" rib spaced 16"o.c., draw it much longer than the roof, duplicate array at your rib spacing, arrange the array over the source polygon, select all, and subtract surface. Delete (or better, cut, for future roof surfaces), and your roof source polygon should just be a bunch of 1/2" stripes that start/stop at the roof edge. Exit the roof edit, and assign the roof top texture to the roof sides, and it should look just about perfect.

Yes then no: use the end points of the smaller roof hidden line render as snaps to create the subtracting polygons. So, 1st ungroup the roof object(s?) to get roof faces. Do the convert copy to lines / hidden line render. Draw a polygon that will be subtracted from the continuous roof faces, using the end points of the HL render as snap points. Subtract this poly from the continuous roof face. Draw a polygon using the same same points that represents the shape to be subtracted from the smaller roof faces, and subtract from those faces.

The work-around for the OP without Windoor is to make a symbol of the door and sidelites and add a bit of 3d geometry (simple extrude, class = same as door or sashes) at the bottom of the sidelite. I have to do this regularly just make the bottom rail match the door's bottom rail height...

Yes, I just like the ability to choose where and how to reduce the vertex count. I don't delegate well, apparently!

I'll say that I generally disagree with this method, since polyline to polygon conversion creates huge vertex counts, and I've never had any luck with the 2d polys to 3d polys (contours) saving me any time. I'd further avoid any conversion attempt of dwg imported geometry for the same "control my vertex count" reason, as well as the likelihood that there are overlaps and other faults that could be tough to troubleshoot. Instead, I trace my survey info with 2d polygons so that I can control my vertex count. Only I know where I need tight spacing, or not. Vertex reduction has always been very important for DTM/Site Models. I generally throw in some 3d loci as well where I have point elevations that I need. Next, select all the 2d polygons and convert to 3d polygons, ungroup to get individuals, set fill to none, and then select and enter each z-height in the OIP. Check the look of the 3d poly and loci 'cloud' from an isometric view or two, rotate the view with the flyover tool to make sure nothing is missed or whacky (zero, or 100" high instead of 100', etc.), then run the create Site Model command. Next, check the look of the Site Model in the format you need. It will likely look great in 2d (w/ 2009), but if you use any 3d format beside extruded contours, you'll likely have some dirt spilling over (or have some dirt washed out from under) your contours. After copying this into a fresh file and sending it to NNA as a bugsubmit, a few tricks to try to massage the result that sometimes work are to add additional (or trace existing) contours and convert them to site modifier "pads" (with a fence), adding some 3d loci, adding some 3d polygons, moving the existing 3d polygons just a smidge (check them in a iso view to make sure they didn't get moved to z=0), etc. Note site modifier "pads" do not need to be enclosed shapes- a line can be used even. The DTM/Site Model tool has always been an almost great tool- they keep chipping away at the edges, but can't seem to get it to "just work".

Yes, this old chestnut helps (me) in a few percent of cases. Except when the initial geometry chokes the command. And, if you figure out how to adjust your initial geometry to suit the command such that "create roof" succeeds, the only useful bit left from ungrouping this roof object is (usually) the roof faces. The fascia and soffits are a mess of (#+*^&$) nurbs surfaces that defy rational stretching. So in the end I delete the fascia and soffits and redraw my own with editable shapes (walls or extrude along paths), after readjusting the roof faces to undo the changes I made to get the create roof command to "succeed" in the first place. Around the block to get next door? My point in posting the examples was to show the OP that the create roof command isn't just technically deficient or buggy, but that it is also conceptually very weak. It's too easy to believe that NNA would only provide a tool if it was in fact useful, and thus spend lots of time pounding it to fit. NNA doesn't (for obvious marketing reasons) go out of their way to disclose weaknesses. Several years ago, one of the program's paradigms (it was in a Flaherty interview, I seem to recall) was to be "self-discoverable" by a reasonable user with a manual. Now the mantra is "get training". I think a big part of this change is the roll out of ever more complex features that have very narrow applications, with serious, undisclosed, and unknowable pitfalls outside of their target range. I'd say the create roof command currently falls squarely in this category.

Using either bcd or Peter's methods, it's best to start with a white siding texture and then use the filtered image setting. With white as a background, the filter color will be very close to the final color.

The create roof command is fine when it works but that is all too rare, still. It often hiccups on co-linear bearing lines. The "middle bits" can't be adjusted except through their relationship to the bearing lines. For example, there's no way to set up a roof to have parallel ridges with a cricket between. Or, after subtracting out a hole in the roof for a smaller upper story, there's no way to adjust the upper roof lines to reflect the rational adjustments to the roof that "keeping water out" would require. (see example "Hip2Wall") There's often odd and irrational no-go areas for bearing lines. (see example "NoGo") The good news is you can still draw any (planar) roof shape you want with the roof face command.