Francois Levy

I for one would like to see EPS vector import as a built-in function of VW, especially given the new strategic alliance between Nemetschek AG and Adobe. I imagine lots of architectural graphics people (and other industries) would love clean vector importing of EPS, PDF, etc. Also, one might get a background file and not have Illustrator, so copy and paste isn't always an option. Likewise, if given an EPS file, it may not be possible to convert to PDF prior to importing. And thanks for the heads-up on the plug-in; I had missed that one.

I apologize if this has been covered in previously. I've noticed that I have the option of choosing from a menu of standard W-section profiles for steel joists, but that option is greyed out when I specify the joist is a C-section. Robert, should I post that to BugTrack, or is that simply an incomplete feature not worthy of a BT?

In producing a DD set for a 17-unit multifamily project, I (like many other users) have a bit of a conundrum with respect to scheduling doors and windows. As many are doubtless aware, there are the following options, (among others): A) Attach data to the PIOs from the data pane of the settings dialogue box, and use the ID Label tool on the drawing B) Use a custom key symbol with all door and window data attached to it (old school); C) "Hand-build" a schedule as a worksheet with no dynamic relation to the actual doors and windows We could debate the merits of the above all day. My particular issue is with labeling under options A or B, with respect to Viewports. If I go with B then I can just plop my key outside the annotation space right in the sheet layer, or in the annotation space. I should probably also mention that many of the doors and windows are embedded within symbols representing the individual apartment units, further complicating matters. That might be a strong argument for option A. Either way, I have to tunnel down to the design layer and click on the PIO to get its information (width, height, head height, etc.), assuming I don't have it committed to memory. So it would seem that in the case of ID Labels (tool-based or homebrew symbols) it's best to label the door or window ON THE DESIGN LAYER, which violates the logic of Viewports. There is a similar issue with associative dimensions. So, are users annotating on the design layer? Is there an aspect of Viewport annotation space that I am missing?

Well sure. I like the blue background and slow spin on the first one.

No trouble at all--it's fun to figure things out. It's little tricks like this (and 2d polygon clipping in DTMs, to name another) that make the program sing in the right hands; if these functions are documented then everybody benefits. And thanks for monitoring!

Ah I think I go it. By making the 3d circle somewhat SMALLER than the model, and selecting the 3d circle ONLY (two important details), I've managed to export a view of the model with little white space. My guess is that as with static exports, VW adds white space automatically. Thanks Islandmon for leading me to this. Dave, may I request better documentation on this procedure in future manuals? Shall I cross-post to Wish List?

Thanks for the effort! I do feel a little dizzy spinning around in that cube. Can yo let me out now? The extruded circle you use does in effect define the boundaries of the model, but that cuts both ways. In the sample file you included, removing the 3d circle enlarges the model. I thought my particular problem might have been in having objects (both 2D and 3D) in invisible classes, but even after removing everything the model still renders with heaps of white space. Dave, if you are monitoring this, may I send you the file?

I've tried adjusting the model to be centered (0,0,0) on the page, selected a circular 3D poly, changed the active layer scale, changed page size. None of these measures make any difference whatsoever; all QTVRs (not VRMLs BTW) come out the same: small model, lots of white space. Any other suggestions?

I understand the logic of layer links in general; was wondering whether layers of the specific names you provided and layer links were required in this particular application. I also tried the 3D poly and it seems to have made no difference. It may be that my model elevation (about 450' above z=0) may be contributing to the problem.

Great, thanks Islandmon very much for the help. I'll give it a shot. Not sure I follow the logic of using layer links in this case, but I'll play around with it. BTW, Dave, is the 3D poly a documented tip? I don't notice it in the manual...

As I said, not so useful if the rest of one's file requires feet and inches.

I can't seem to control the relative size of my model with respect to the overall window size when exporting a QuickTime VR object movie. No matter what I select or what page size I designate, I get a relatively small model with a lot of white space. As a result even if I zoom whilst in the QT player, the model is fairly low-res, but the QTVR movie is still pretty large. I'm paying a lot of file size overhead just for white pixels. Any ideas how I can control this?

Of course! I should have thought of that. Thanks!

We're a small firm and we keep files on a LAN server. AS VW files have gotten bigger and bigger (50 MB are not uncommon these days for us), autosaves are really slowing us down. Does anyone have any tips and tricks to speed up autosaves? I suppose caching Viewports is bloating files, and I could turn that off, or autosave less frequently, Any other ideas?

Exactly. In SD or DD, often the "one project, one file" model works well. As a project progresses into CDs, however, more hands are on board, and it become necessary to break the project up into several files (EG: site; plan, model and elevations; building sections; wall sections and details). In CA, ideally a single project file is created reintegrating all the multiple files. At the very least being able to reference sheet layers or ideally clone viewports would make this a far less tedious process.

One cannot currently copy a viewport from one file to another. In order to do so, one would have to copy the design layer from the source file, create a new sheet layer, create a new viewport, then copy annotations from one viewport to another, carefully positioning them in place. Very tedious if one has a sheet with a dozen or more viewports! Workgroup References will not reference sheet layers, unfortunately. I'd like to see either Sheet Layer workgroup references, or a way to copy and paste annotated viewports from one file to another; probably there would be a prompt to ask the user to identify which layers in the source documents would populate the viewport.

Since each sheet layer can have a distinct page setup, it would be great to be able to selectively change those in a single operation, as a complement to Batch Print and Batch PDF Export.

I've recently had a few DTMs where the elevation labels are displaying as decimals (EG, 564'11.978" instead of 565'). This is in spite of the fact that the 3D poly corresponding to that contour has an exact Z of 565' in this case. Moving the 3D polys within the DTM up .022" does not change the display. I could set my display units to round to whole inches, but that obviously would sabotage the dimensioning everywhere else in my project file. I should also mention that I am using a cropping polygon in this DTM; don't know if that would contribute to this error. While I'm at it, there is no way, is there, to control the dislay units for a given DTM (EG displaying elevations as 565' instead of 565'0")?

Right! And I knew about the instances, but I was pretty impressed with how dynamic they were.

I have a project whose model consists of 5 design layers (site, three floors, roof), all correctly registered in X,Y and Z. I have keyed in section viewports from the viewport of my ground floor *sheet* layer, in order to generate elevations, building sections, and wall sections. I then copied and pasted all my section markers from the ground plan annotation space to the annotation spaces of the second, third, and roof plans. I've noticed that VW tracks all the instances of the section markers and "knows" that they are all referring to the same section. If I change the position or keyed number of one, that change reflected in all annotated instances. Pretty dang cool!

How about a database of cities worldwide with lat and long already built in (as a pull-down menu) for the Set Sun Position command (like YouKnowWho?Up) Also, adjusting for a rotated plan north is not user-friendly; it only accepts positive values and could be more graphical.

I often have to manually clip objects and reasssign them to other classes in as-built drawings/models in order to generate demolition plans. Wouldn't it be grand if there were a Demolition Tool? for starters, anything within a drawn poly could be clipped and assigned to (a) user-defined demolition class(es). The tool's Preferences box could list all current file classes and how they would map to demolition class(es), such that a door in a wall would map to a different demolition class (with different graphic attributes) than the wall itself.

Well I feel a little foolish. First, I didn't realize that I was running 12.0 on an Intel machine--I thought it was already upgraded to 12.5! Secondly, I set my 3D resolution to Low (from High). Finally, I traced the building footprint, offset it by 5', and used that polygon to clip the DTM, vastly reducing the number of 3D polys (and elminating many that I did not need anyway for those viewports anyway).

We're working through a large residential project in Design Development, and taking section viewports of a 3D model to generate building sections and elevations. The site is large and complex enough that ther are a fair number of 3D polys, and the building has two main wings set 65? apart, with a shallow barrel roof in one case, and a flat roof in others--in short a fairly demanding model but not (IMHO) hugely so. We have thus far set up 6 sections, and are finding the machine is now very slow (brand new Intel core Duo 2 iMac, 1 GB RAM). Even moving a vewort on the page is painfully slow. Questions: --does anyone have any tips on speeding up hidden-line Section Viewports (other than turning off polygons)? --will more RAM make a substantial difference (we have an aditional 1GB on order)? Any suggestions welcome!

One can crop a DTM by pasting a polygon inside the group of data objects (3D polys or loci). In some cases, though, the cropping polygon causes 2D countours to simply drop out. Are there "rules" for such a polygon (for example, no concavity, maximum number of vertices, no edges on/near 3D data, etc.), or is it hit or miss?