Jump to content

P Retondo

Member
  • Content Count

    1,806
  • Joined

  • Last visited

Everything posted by P Retondo

  1. Pete, true, but for ease of modeling I agree that showing the top riser would save a bunch of time.
  2. Lucy, I use a 3d polygon - just make a rectangle, convert it to a 3d poly, set it at the height you want, and use the "fit walls to roof" command as you would normally. This is faster than editing a bunch of walls individually, as Pete has suggested. For one or two walls, his way is faster.
  3. Hear hear! I believe the video processor is used in rendering images. Also it's not just Macs that have multiple processors and suffer from sub-optimal resource management.
  4. DB, I wasn't aware that selecting an object confined smart cursor cues and dragging to that object. It's actually a pretty good idea, and should be added to the wish list. As far as stretching is concerned, yes, the selected object is the one affected when using the resize cursor. But with dragging the object, no - the foreground object is the one affected. There may be some issue associated with confining resizing and dragging both to a selected object, but I can't think of one right now. For consistency, the program should behave as DB suggests. Subtle changes like this in the way VW operates can make a huge difference in everyday workflow.
  5. That line is a zero-thickness jamb. Use Robert's advice by going to the "Settings" window - you will get good results. If you convert the PIO to a group, you will lose the 3d information.
  6. Jim, edit the "Section style" class to a lesser lineweight.
  7. Gideon, there's a column tool.
  8. Ray, thanks, I'll keep an eye out for that one!
  9. Try using the method Peter Cipes describes, which I basically use as well: Cipes elevation method This takes advantage of textures and shadows to convey a lot of information, and one generally gets faster more informative results than using the traditional lines-only method.
  10. Janis, I use the Section Viewport tool to create interior elevations. Create a polygon using the polygon fill tool to define the boundary of the rooms, and use that to clip the viewport. I'm not sure how a dedicated interior elevation tool could be faster and more efficient. What is needed right now is a series of refinements to the Section Viewport tool. One of the biggest problems with this method is common to all Viewports - the additional filesize overhead associated with the Viewport cache.
  11. I'd like to have the option to cache a screen-resolution version of viewports, with full print-resolution versions automatically updated when printing. Right now we have the choice between 1) caching viewports (normally set to at least 300 dpi for good output), which results in enormous file sizes, or 2) not, which makes it difficult to work with viewports as they have to be regenerated frequently. Both are time-consuming situations. Large filesize makes saving your work, which I tend to do every 100 operations, a lengthy process. Updating viewports whenever a file is closed and opened is also very time consuming, but I tend to chose not to cache viewports because on balance this option takes slightly less out of my day. I believe that a screen resolution cache (72 dpi?) would solve these problems, and I think it should be implemented on a viewport-by-viewport basis.
  12. Olly, for now to make parameter changes on more than one window at a time the workaround is to use a 3rd party utility, "Info Editor," available from SofwareCustomizationServices.com at a very reasonable cost. I finally broke down and purchased Info Editor after being given the same advice over and over, and I've saved literally hours of time.
  13. Christiaan, I agree for the most part, but I wouldn't call it a "McMansion" phenomenon. It's more like simple standardization. I think the basic solution in that regard is to go beyond US manufacturers and get more kinds of window types into the library, and to integrate those with the PIOs. I've used windows from Sweden and Italy, as well as a fair representation of US manufacturers, and I don't think it would be far-fetched to bring more types into the fold. Plus, the PIOs could make it much easier to customize things. Regarding the stairs PIO, to my mind it's not a matter of two stories versus many - it's anything beyond a single story. The stairs PIO needs to be able to handle displaying information on more than one floor using a single object. I'm hoping we'll be able to put ideas out in the context of a focused wish-list thread pretty soon. We could probably write a small book outlining how we think intelligent parametric objects would work. Fortunately for us, it seems the engineers at NNA basically agree that the current tools are a work in progress, and are making efforts to institute some fundamental improvements.
  14. Christiaan, I note your recent accusations regarding the "McMansion market," and without suggesting I have evidence against that and without for a second disagreeing with the need to revamp the window and door PIOs, I wonder what the basis of this McMansion thing is? It's a fact that there are McMansion architects and drafting services out there, and that at least some of them use VW - nothing wrong there (I'd rather have them support VW than some other software), though I'm not particularly impressed by the architecture that results nor interested in the fast-food equivalent of design. But where is the evidence that VW is tailoring the program to that market? Frankly, I don't think there are that many "seats" in that sector. And what part does BIM play in that market? Very little to none, I would say. BIM is a creature of institutional clients.
  15. Carl, I've submitted a bug report about this. This is particularly a problem when the door threshold is lower than the wall, which occurs typically in a garage man-door, and other situations. This problem is also responsible for those false thresholds that show up in interior renderings. Robert A. has recommended raising floors by a fraction of an inch to obscure those, but one hopes that is a temporary workaround as it plays havoc with accuracy in sections. There is a workaround where one needs to drop the door below the wall. Edit the wall using 3d reshape tool to bring a portion of it down to the bottom of the door. See attached image for before-and-after results.
  16. Christiaan, I get your point about Wikis. On the ohter hand, I'd say that it would be a big step to get some focused discussion going, as Katie says she can do with the resources available to her. If it at some point it looks as though the Wiki format is needed to sharpen the focus, maybe NNA would be willing to work on that. What I envision as key (and acknowledging the oligarchy we're dealing with, i.e., Katie and her colleagues run the company!), is that NNA at some point would post what their engineers consider to be the design direction for the next generation Window & Door PIOs. Call it a kind of open engineering experiment in software design where end users could participate BEFORE everything gets locked into millions of lines of code.
  17. Jeffrey, this is excellent news and your approach is thoughtful and understandable. The bug submittal route is a very useful tool, but I think that an open dialog could be incredibly helpful as well. Christiaan, by a Wiki do you mean an online document that can be edited by anyone? So that your ideas could be modified or deleted by someone else, and no trace would be left of them? I'd rather see a series of threads, and, if NNA has the resources, a software design guide that incorporates what are perceived as the best ideas and directions, that would evolve and provoke additional thoughts and comments. For starters, I'd suggest that Windows & Doors, Worksheets, and Section Viewports would be interesting topics.
  18. Resistance is futile! Has any thought been given to the idea of nomenclature tables? In this concept each part of VW would have variables assigned to the key words that show up in dialog boxes, etc. These variables would each map to a member of a nomenclature table, and a variety of tables could be made available for various markets and standards: Germany, IFC, Australia, etc., including a user-built custom table. Thus, for the US market "Department" would be part of the US institutional nomenclature, where "Bureau" or whatever is appropriate would be the equivalent term for the UK nomenclature table. It's the verbal equivalent of a color (colour) palette. Yes, we are growing towards a more interactive/interoperative environment, but with the power of intelligent programming we can still have flexibility and customization. I know that some have complained lately about incorrect terminology in the Window PIOs. I'd be willing to bet that many of the terms are standard in one market and inappropriate in others. The nomenclature table concept gives the user the power to work around what are perceived to be inappropriate terms, while still allowing VW to promulgate its best compilation of terms appropriate to multiple markets and standards. It also makes it possible to ship VW with different options selected for different markets, making it easier for users to get up and running without fussing with arcane settings, while at the same time allowing the opportunity for fussy customization when the user is ready to pay attention to such issues.
  19. Christiaan, "Department" is one of those north american MacMansion concepts. I like your idea, particularly as it might be extended to a variety of other PIOs, like the oft-maligned "Stlye-1" . . . class names.
  20. Katie, I know everyone at NNA is super busy, and you're probably at the limit - but to implement your idea, I wonder if it would be possible to dedicate a couple of forums (fora?) on this board to specific issues, so that you could accumulate the wisdom of a variety of users and so that we could all benefit from the dialog and refinement that would generate?
  21. 256 MB RAM is going to cause you big problems. Most of that is taken up just running the system and storing the program and your document. 800 MHz is going to be frustrating as well, unless you're doing strictly 2d work with no images.
  22. The problem is that those loci (even if they are locked!) are going to disappear if changes are made in the contributor WGR file. Then VW completely rewrites the WGR layers. To get your loci to stick, you will need to create a layer link to the WRG layer in another layer resident in the container file, put the loci there, and use that layer containing the link in the VP.
  23. Bring the 4 files into a single container file via WGR, make layer links of the referenced layers that need to be rotated, and after unlocking the links move and rotate them appropriately. The referenced layers will update, and the layer links will update and maintain their rotation. Be sure to have unique layer, class and resource (including symbol) names in the four separate building files. Some of your common resources, such as textures and stock symbols, can have common names, as long as you maintain discipline so that when VW asks to update one of those you aren't writing over something you don't want changed.
  24. If you want to create a hole in a roof object, first create a rectangle or polygon that outlines the hole you want. Copy it. Then "edit" the roof object with the "Edit Group" by keying , paste your polygon in, and "Exit Group." Use a similar process to edit a roof face.
  25. My dual core uses ~100% processor for final RenderWorks. I have hyperthreading enabled.

 

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