Jump to content

P Retondo

  • Content Count

  • Joined

  • Last visited

Everything posted by P Retondo

  1. Hi Katie, that was a great piece of research, but unfortunately it doesn't apply to my situation. I have no ipoint.exe process. I also notice that during the flickering associated with selection of an object, the OIP does not register any object data until the flickering has ceased. The above applies to both v12.5.2 and v2008. The flickering is worse in 2008. Pete, thanks also for your input. I don't think I'll be cracking the case on my Dell 960 anytime soon, much less tinkering with the wires inside! But next time I'm there I'lll look around for that, and if I find something I'll call Dell tech support.
  2. I don't have an Intellipoint mouse or Intellipoint driver. I have a version of the screen flicker where just the top blue bar of my application window flickers at about 4 cps. This occurs on the final click of creating an object, or when I select an object. The duration of flickering seems to depend on whether the object or type of object has been recently created or selected. It can be as little as one blink (or none), or as many as 20 or 30 blinks. I'm curious - how would you describe the flicker you have been experiencing?
  3. I use Petri's method to remove voids in the poly, very efficient. I wouldn't care to have each modified 2d poly carry with it it's history of clipping, adding, etc. I think it would add too much overhead to the file size. Besides that, if you notice, 3d boolean objects are no longer extrudes, they are a different object type (a necessary complication, if you think about it). So if your idea were implemented, once you clipped a 2d poly it would then become a different object type and couldn't be clipped or otherwise modified with 2d reshape, etc. With Petri's method and with multiple-vertex reshaping, I think there are sufficient methods to deal with the issue. And a solid subtraction isn't a bad way to go, by the way. Just extrude all your holes or cutting shapes at once to make a single subtraction solid. Then you can add to, subtract from, or edit the set of 2d objects to make changes in your hole pattern. I do it all the time, and no complaints!
  4. We've asked for this before, but once again can only help move this along! It is long past due that VW accommodate this common condition.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. Jonathan, do you find that the design layer "viewports" navigate in 3d in the way layer links did? I take it that these viewports are really modified layer links.
  10. Peter, are you talking about version 12 or 2008?
  11. Stack layers doesn't eliminate the need for layer links because you can't use 2d tools except in plan view, and you can't save a stack layers view (in VW 2008 you can save as a view, but still can't use 2d tools).
  12. I've been running VW 12.5.2 and VW 2008 on Win XP x64 for over a year.
  13. 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.
  14. Chris, right, I expect that would be reasonably easy to script. Unfortunately for me (or fortunately, depending on your perspective), I haven't had the inclination to get into yet another programming language! All the same, I think that things people would find useful would best be built into the program.
  15. 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.
  16. 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.
  17. 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.
  18. I think what you are saying is that we need to be able to adjust origin, rotation (and scale?) of the associative hatch. Already wish-listed a while back, let's hope NNA is working on this, as well as the ability to create user-generated hatches from drawing elements.
  19. 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.
  20. Chris, there are 2 ways in VW to create a hatch. To create an associative hatch use the attributes palette and apply a hatch fill.
  21. Christiaan, that is the update build number, different from the build that was shipped initially.
  22. Ray, it sounds like Pete still has an issue. What do you mean by "particular workflow?"
  23. 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.
  24. 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.
  25. Petri, just to clarify, are you saying that you don't use window or door PIOs?


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