Jump to content

P Retondo

Member
  • Content Count

    1,735
  • Joined

  • Last visited

Posts posted by P Retondo


  1. Assign a class to the label in your window or door PIO dialog box (ID Class field). With Info Editor (an inexpesive 3rd party plugin) you can do this en masse in one operation. Make that class not visible where you want the display suppressed.


  2. Christiaan, thanks for that link. Though it addresses mainly Mac issues, by generalization the same applies to Windows. What comes through to me is the "clean break" notion. In rewriting programs to conform to 64 bit, all software will be able to part ways with a bunch of accumulated crud. It means some transition headaches, but we've been around long enough to know that we can deal with it. I don't think any of us would like to go back to the 16 bit days of MiniCAD.

    Also, it's good news for 64 bit advocates that new Macs by default will be on a 64-bit capable OS.

    Katie: I think it is true that 32 bit emulation on Windows x64 systems is slightly faster than execution on a 32 bit OS. The driver problem you talk about has been my most negative experience - plus, there is the problem in the case of older 32 bit software, that would otherwise be able to run on a 64 bit OS, if they have a 16 bit INSTALLER, they can't be installed.


  3. Mike, I agree. If we can just get the conversion from legacy files to work properly (i.e., multiple links can now be consolidated into one VP with multiple-layer visibility, but the converter won't do that).

    We asked for better management tools for layer links some while back, and though the 2008 literature doesn't seem to trumpet it, this is just what we got with Design Layer Viewports.

    I'll be really interested to see how Stack Layer Views stacks up against Design Layer VP's as a way to explore and work with a 3d model.


  4. Christiaan, if you batch convert, I'd recommend not converting layer links to Design Layer Viewports. I've discovered what I think is a bug in the saved-view treatment of class visibilities when that option is selected.

    I'm sure you're going to test this on a couple of projects first, no?


  5. Mike, Chris, et al., let's step back and look at the issues raised here and ask what it's worth asking NNA to spend engineering priorities on. Frankly, the improvements to 3d smart objects Mike's been asking for have to be way higher on the list.

    I think the important things to think about are: 1) how to more easily and powerfully set defaults, including rethinking what things should have default settings, and 2) how to make the use of classes as a way to set graphic styles more powerful and easier. And, along the way, how to make all the concepts involved here clearer and more intuitive for the new user.

    I really don't think that the AP is an "annoying little palette with no rational reason for existence," to roughly paraphrase the opening post. It does, in its imperfect way, embody graphic characteristics common to most objects (rational reason 1), and it does act to set defaults (rational reason 2). Perhaps there is good reason to rethink and rearrange things, but not in the simplistic terms proposed.


  6. I'd like to see a button, which could live on the OIP or the Attributes Palette (could even be a drop-down command) that would convert the graphic attributes of all selected objects to "by class" (including rendering texture). As it is now, we have to make those settings in two places, and we have to complete several operations to do it. I'd like this not to be a preference, but something to automate changing over all the settings. That way, we could change one or more back so that only some settings would be controlled by class designation.

    This would make it easier for folks to operate in a setup whereby some or all graphic attributes are controlled by class, and make it easier to convert things to that way of using VW.


  7. The SIMPLE solution is to dock the Attributes Palette right above the OIP on your screen. This may not satisfy purists who want everything in the OIP, but having it right there would do the job.

    This is a fine debate on the virtues of using Classes as a way to assign attributes, but doing away the AP is a quite separate issue.

    What to my mind would be much more useful for power users of Classes is a check box, either in the OIP or the AP or both, called "assign attributes by class" that would automatically convert all graphic attributes (including texture) to "by class," a setting that would be reflected in the AP where it could be tweaked if you wanted an object to retain an override with respect to line color or any other attribute.

    The problem with putting everything in the OIP is twofold. One, the OIP is already too long to fit on my screen for certain kinds of objects. Two, the OIP does not set defaults, where the AP does. And speaking of that, defaults are now set in more than one place (the AP, the active class, to name two). I think default settings deserves its own window, so that these can be edited in one place, and the whole set of defaults, including for the various PIOs, should be importable from one document to another.


  8. Yes, the process can seem complicated. But if you have your first and second floor done, the method I gave you will work very easily. Jonathan is very knowledgeable, and has great experience conveying how to work with VW. The VW manual tells you how things work, but doesn't necessarily give you step-by-step methods for doing things in a practical way.

    Just be aware of the "layer z" setting. It adjusts the layer links so that the second floor will be higher than the 1st floor. Or, alternatively, you can create your second floor with layer z = 0 and just elevate the walls to the desired height. That's the way I work. Either way, when you assemble the model on a single layer using Layer Links, everything will come in at the correct height.

    PS, didn't mention this, and it should be obvious, but it never hurts to be explicit: if your lighting is on a separate layer, you need to "layer link" that in as well if you want to view the lighted model via its design layer. Set the general lighting for the model layer to get an overall lighting effect, the "sun" should give you shadows and greater light on surfaces facing the sun.


  9. Create your layer links in a single Design Layer, not in a viewport. You actually can't create a layer link anywhere else. This is your model layer. Add lighting (in a separate layer is okay) using View -> Lighting -> Set Layer lighting and sun. Create a ground plane (usually in a "ground" layer and again linked into the model layer). Pick a point of view in one of several ways (use the numeric keypad to get standard isometric viewpoints). Pick a rendering mode. Done. If you want this in a viewport on a sheet layer, View -> Create Viewport.

    You skipped a few steps. I don't know where you are getting your training, but I would suggest taking a look at the manual.


  10. Try running just VW, and you will see that your graphs will differ and that one will be working much harder than the other. That's because VW doesn't use more than one processor at a time (except, as I noted, for RenderWorks rendering). Since computing power is now moving to multiple processors, we won't be able to boost our performance with CPU upgrades until VW is optimized to use multiple processors.

    I don't know if it's possible to get your P4 to run without the dual processor emulation. You might ask the company that sold you the computer, but I've never looked into it - I doubt it, but it's probably worth a phone call. Right now, only 50% of your P4 can be applied to a VW task.


  11. Thom, your P4 is probably emulating 2 processors. You can confirm that by looking at Windows Task Manager / Performance, and see if there are two separate graphs for the CPU. So most VW operations, except for RenderWorks, will use only 1 of those "processors" = 50% CPU capacity.

    Can you compare your experience with 2008 to VW 12.5? What are your video card specs? Forum users have noted a lot of problems with certain setups affecting the speed of 2008.


  12. Once you hit a bug or limitation that requires you to destroy the parametric nature of the object there becomes no point in using it, apart from as a design tool. . . I think a lot of these problems stem from these PIOs starting their lives designed for the McMansion market. If NNA came at it from a different perspective (i.e. a global market of diverse architecture) I don't think we'd have all these limitations.

    Christiaan, while I agree in the main with your comments, I think it's time we put the McMansion notion off to the side. I think it's a bit of a red herring, and doesn't serve our interest in getting NNA to focus on the real problems - fixing the flaws, such as those you point out, and expanding the power of the PIOs.

    The window sill has been a frustrating one, and one that I can't understand. It has nothing to do with conventional window detailing in any market, McMansion or otherwise. It just doesn't represent a sill properly for any window ever manufactured. Similarly with the stairs tool, most "McMansion" designs in my neck of the woods would never settle for the limited stair designs that tool can generate.

    With all respect to those who use VW purely as a 2d drafting program, that is not the future. If NNA focused solely on that, there would not be a VectorWorks in the future. In fact, if NNA doesn't come up to speed on some of these 3d tools, they are going to lose market share to software companies that can. I think the engineers at NNA are working on these things, per Jeff O.'s comments in a different thread on this board, and many of us are hoping they will get it right in the next release.

    In the meantime, while I acknowledge the flaws that Christiaan points out, in my practice 3d PIOs are still usable for many if not most situations. I would hope that the users who read these comments take Christiaan's remarks and his well-earned and credible opinions in balance with the experience of others.


  13. I just turned off my NVIDIA nview desktop manager, and it made a big improvement in the top bar flickering I had noticed with VW 12.5.2. Unfortunately, it hasn't made the same dramatic improvement for VW 2008, although it seems to have speeded things up somewhat.


  14. To Joe Average, such a pulldown list would read WHAT. That's why I suggested the advanced mode, e.g. SQL.

    Petri, love that WHAT.

    But I was thinking of that pull-down menu as an advanced, or at least intermediate, utility. Just out of curiosity, what would a SQL-based mode be like? I don't have any experience with SQL, but isn't it like most other languages when it comes to logical statements?

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...