Francois Levy

It would be useful to be able to assign a pattern to hatch lines.

While class attributes of objects can be overridden at the Viewport, Viewports cannot override any "forced" attributes of objects. That should be an option in Viewports/Classes...

The subject line says it all: a readily-accessible button in the Object Info palette that converts selected object(s) to polygons (saves going to the menu). Maybe also Compose and Decompose?

Personally I like white and have for years. My colleague seems to think black is easier on her eyes, and that a soft grey or Borco mint might be even better. To each her own I suppose.

A user in our office has requested a background color other than black or white. Does anyone know of a plug-in or script that allows customization of the BG color? I am not, of course, referring to RenderWorks layer backgrounds. One sloppy workaround would be to have a huge rectangle of a desired color on a dedicated layer, with a Saved View that would activate that layer. Not perfect though ... Should I x-post this to Wish List?

Class overrides only work in viewports if the original object was drawn by class. If you have a wall class and set it to a .30 mm line weight, but manually assign a .50 mm line to a given instance, then the viewport will be unable to override the manually-assigned line weight. That might be what you are experiencing. Until viewports intelligently recognize depth, I simply force nearly all objects in the viewport to a light line, then trace over objects I want to "pop" with heavier lines, generally in the annotations space. Still requires manual fiddling, but still faster than the old Cut 2D/3D Sections in most cases. Now if only viewports would update faster ...

Well, I'm only asking for the same ones you already have in the 2D tool to be available in the 3D joist. It struck me that they are in one place, and not the other. Obviously those are different tools, but ... W, angle, channel, tube pretty much captures it for me.

Sorry, not LGMF. I meant the same standard steel channels that are in the menu of choices for the 2D steel channel PIO.

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.