Jump to content

Francois Levy

Member
  • Posts

    283
  • Joined

  • Last visited

Posts posted by Francois Levy

  1. I've noticed that from time to time textures which had been applied at a 90? rotation to extrusions will flip back to 0?. Is anyone else experiencing this? Is this a known bug? Anyone know what triggers this behavior?

    Unfortunately this is one of those that's hard to predict or reproduce ...

  2. Hi Pete,

    I don't entirely agree. Individual objects need not be selectable in the VP window; there could just be a toggle in the classes column (next to visibility) for "VP overrides object attributes". Another approach would be to make objects selectable within the Annotations Space itself (that's a taller order of course).

    I don't know how much engineering effort is required. We can already override graphic attributes by class; it seems a small thing to allow them by object. But of course seemingly trivial features can actually involve daunting coding.

    As to your larger point: I think these kinds of requests actually have everything to do with making VPs "work". In private conversations with NNA, I like many others I am sure have pointed out that there exist in VPs graphically conflicted interests, borne out of the fact that an object may be required to appear one way in plan, another in elevation, yet another in section, and be represented in yet another way in a rendering. Overriding attributes in VPs in effect allows me to assign multiple attributes to the same class.

    I suppose another way to go about it would be to give every class multiple (user-defined) attribute panes. Each class could have a plan appearance, elevation appearance, section characteristics, etc. In essence that already exists to some degree with classes assigned both RenderWorks textures and 2D graphic attributes. I think your caution is valid, though, that such systems could collapse under their own weight and be either buggy or unusable.

    Ultimately, I'd like to see "smart" elevations and sections (i.e., VPs) that "know" to lighten line weights as elements recede in the background (preferable controlled by a simple slider by the user).

  3. 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?

  4. 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 ...

  5. 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.

  6. 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.

  7. 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?

  8. 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?

  9. 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!

  10. 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?

  11. 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?

  12. 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?

  13. 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.

  14. 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...

  15. 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?

  16. 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?

  17. 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.

×
×
  • Create New...