compusam

Well, I just downloaded VW 12.0.1 update in hopes that the Big Border Bug in the window plug-in had been fixed, but it appears not. I am still getting artifacts around windows and wall textures around windows shift slightly so that the coursing of siding materials shifts, for example, in this border area. Also, if the window trim width is different for interior vs. exterior, the texture of the larger trim shows up on the reverse side of the wall. So one might see exterior shingles on the interior of a wall if the exterior trim width is greater than the interior trim width. Converting the plug-in to a symbol does not fix the problem.

Yes, this topic is in ALL-CAPS . I posted a topic in November 2005 about a bug in the VW12 door and windows plug-in. It has not been fixed and there seems to be no schedule to fix it. Am I missing something? or am I the only architect who considers ? uh, doors and windows? to be fundamental elements of CAD software? There is a bug in the way in which doors and windows render in VW 12. They have a big border which appears as a line beyond the trim line in Open GL or translates the wall textures (exterior to interior 90?) in RenderWorks making VW12 essentially useless. The fix is to convert the windows and door plug-in's to symbols, but then one loses the ability to "change" the parameters YES, I am being a squeaky wheel because this is an admitted bug which has not been fixed and there appears to be no schedule to fix it. I purchased VW12 in November 2005, but it is collecting dust on my hard drive awaiting a fix to what I consider to be a fundamental problem.

Thanks for the suggestion to convert window pio elements to symbols to solve the big border bug, however, that will mean duplicate (or triplicate) effort in the future to delete the window symbols and replace them with pio's in the future. In my experience, window sizes, brands, casings, etc. change frequently during the design and construction drawings process. The beauty of the pio is the ability to make changes as the work proceeds. For the time being, it will be easier for me to go back to VW 11.5.1 until there is a bug fix.

Yes, I will continue to "play" with VW12 until a bug fix is posted, but I was hoping to simply continue "working" (ie. earn an income) on my projects while learning VW12. As this is not possible because of the window bug which impacts on elevations and rendered images, I will continue "working" with VW11.5.1.

Glad to hear this is an acknowledged bug, but I want to clear up one detail. Several posters seemed to imply that the big border bug (bbb) occurs with previous version files opened in VW12, which is true, however, I have also had the same problem with new VW12 files. Simply create a new file in VW12, add a wall, add a window, look at it in elevation or iso and the (bbb) is back.

Thanks for the replies and the link to other posts. For the time being, I am simply awaiting a bug fix and have returned to VW 11.5.1. It still works. I think the "potential" of VW 12 is great, but not yet realized. NNA is not alone in releasing buggy software? Apple, Microsoft, Adobe, Macromedia, Quark, etc., for example, have cost me many hundreds of hours trying to work around bugs. Most of the time there is a workable compromise, but this Window Bug goes to the heart of VW 12 and makes it essentially unuseable, for now.

I originally posted this problem in the RenderWorks section because I originally thought it was a rendering problem, but it appears to be a window pio bug (according another poster): I have recently installed VW12 with RenderWorks. When rendering walls with window openings, I am getting strange artifacts around the openings. If there are no textures, there is a strange "halo" around the opening in the wall. If there are textures, the direction of the texture changes 90? in a perimeter of about 4" (real world) around the opening. The problem is visible in Open GL and in Final Quality RenderWorks. In some circumstances, the exterior wall texture will appear around the interior view of the window until the window has been flipped 4 times (sort of refreshes), then the interior texture appears on the wall, but still oriented incorrectly in this "halo" affect. After further experimentation, I discovered in wireframe view in elevation, there is a 4 1/2" (real world) perimeter around my window plug-in elements. This seems to correspond with the shifting textures and "halo" effects. This shows up in 3D as an extra frame around the window (outside the perimeter of the trim)!!! I tried to get around this bug by using the VW 11.5 window pio, but VW12 does not recognize the earlier plug-in. I should know by experience not to buy version x.0 of any software, but the new feature set and the demo videos are very seductive. It would be nice if VW were rock solid (which has never happened), but it seems that core features of VW (doors, windows, walls, etc.) should be rock solid before releasing updates. I have experienced this on both my G4 PowerBook and my G5 dual processor running either Tiger (10.4.3) or Panther (10.3.9). This problem does not occur in VW 11.5.

Thanks for your reply. I tried to get around this bug by using the VW 11.5 window pio, but VW12 does not recognize the earlier plug-in. I should know by experience not to buy version x.0 of any software, but the new feature set and the demo videos are very seductive. It would be nice if VW were rock solid (which has never happened), but it seems that core features of VW (doors, windows, walls, etc.) should be rock solid before releasing updates.

As a further elaboration of my own post, I now realize in wireframe view in elevation, there is a 4 1/2" (real world) perimeter around my window plug-in elements and I have no idea what it is. This seems to correspond with the shifting textures and "halo" effects and maybe it has something to do with the new window plug-in, but I cannot get this extra perimeter linework to disappear. This shows up in 3D as an extra frame around the window???

I have recently installed VW12 with RenderWorks and converted VW 11.5 files to version 12. When rendering walls with door or window openings, I am getting strange artifacts around the openings. If there are no textures, there is a strange "halo" around the opening in the wall. If there are textures, the direction of the texture changes 90? in a perimeter of about 4" (real world) around the opening. The problem is visible in Opeb GL and in Final Quality RenderWorks. In some circumstances, the exterior wall texture will appear around the interior view of the window until the window has been flipped 4 times (sort of refreshes), then the interior texture appears on the wall, but still oriented incorrectly in this "halo" affect. I have experienced this on both my G4 PowerBook and my G5 dual processor running either Tiger (10.4.3) or Panther (10.3.9). This problem does not occur in VW 11.5.

Thanks for your reply. No I have a huge 250 GB drive. That was a slip in my hunt and peck typing.

I called tech support and received an answer to my question. There is a check box in Line Render Options under the View menu which needs to be checked in order to render Sketch Hidden Line renderings. Thank you Tech Support.

I have recently installed VW 11.5 and have begun experimenting with Sketch. I have also viewed the online tutorial video about sketch. The video illustrates creating a Sketch view in wireframe and with Hidden Line rendering. I can create a wireframe sketch, but as soon as I select Hidden Line rendering, the image loses the sketch look and becomes a standard hidden line image. I can create a hidden line sketch of a viewport, but I cannot create a hidden line sketch of an object on a design layer. I have also tried this on my laptop with no luck. Am I missing something? Dual 2 ghz G5 250mb drive.

With VW 11.0.1, the automatic backup file created by VectorWorks becomes corrupted, crashes VectorWorks and, in 1 case, froze my computer. My computer never freezes w/OS 10.3. This has happened to me 3 times, once on a different computer. The backup file is corrupted and crashes VectorWorks causing me to lose evrything since my previous save. I have relied on the backup file for years to recover all but the last 15 minutes of work. Now, it seems, I can no longer rely on this feature. Fortunately, I have only lost about 2 hours of work due to this problem, but the potential lose of time is enourmous. Is anyone else having this problem with VW 11.0.1?

Grant M Thanks for the tip to save views with a sheet layer as the active sheet. I should have thought of that myself. That method works and will save me some time. As regards the visibility of classes in Viewports, as I mentioned in my original post, select a sheet layer with view ports on it. Turn off all classes and select some class that is not being used so that it becomes the active class. Everything disappears. Now select a class which is used and those elements, but not others, will appear. Since others in this post are experiencing the same, mine is not an isolated case. In any event, your suggestion is a nice work-around.

Viewports are great and I am learning to use them, however, there are some weaknesses. When setting up viewports, each viewport can be assigned layers and classes for each viewport. When setting up "sheets" now called "views" layers and classes can also be set, however, a "view" does not allow for the selection of "sheet" layers where viewports reside. There is no way to control which classes are turned on in viewports. Just be sure to have all classes turned on to be sure that the classes defined in viewports actually display. There is no one step way to guarantee that all classes display in viewports. To test this, turn all classes off, then select a viewport. Only the active class will display. It seems to me that viewports should be smart enough to automatically turn on classes which are defined by each viewport, respective to that viewport.

Thanks for responding. I hope that future updates will allow for finding symbols or other "data" in annotations of viewports because I have also just found that my Room Finish Schedule has lost all of its info because I have moved the "Room Names" to the annotations of Floor Plan viewports. Now, I have to go back and create "sheets" for text and other 2 dimensional symbols and plug-ins which I do not wish to place on 3 dimensional model layers. My layer count has now "increased" by about 33% compared to previous versions of VectorWorks and the "annotation" capability of viewports is essentially worthless because I do not wish to have text for one drawing on 2 different layers.

I use a worksheet to count electrical symbols (light fixtures, receptacles, etc.). If I place these symbols as annotations of a viewport, the worksheet does not track these symbols which makes my Electrical Schedule (worksheet) inaccurate. This means that I have to use a design layer for these symbols when I would rather place them on a sheet layer along with other annotations of a viewport. Is there a way to have worksheets track symbols as annotations of a viewport?

This problem seems to be repaired in 10.5.1 final release.

I forgot to mention a couple of other details about my configurations in which this problem occurred: VW 10.5/OS 10.2.8, Mac G5 VW 10.5.1b/OS 10.3.1, Mac G5 & G4 PowerBook VW 10.5.1b/OS 9.2 (boot up in OS 9.2), G4 PowerBook

I have had this problem before and it seemed to have disappeared, but it is back. To reproduce the problem, do the following: 1. Create a straight wall with the wall tool. 2. Place a window in the wall with the window tool. 3. For frame depth, uncheck "Use Wall Depth" and make the frame depth less than the wall thickness (as would be the case for a brick veneer/wood frame wall, for example). 4. Make the "top shape" of the window "segment" arch. 5. Use the RenderWorks tool to render the wall and window. 6. VectorWorks quits. The problem does not seem to occur with a square top, but It does occur with round or segment top. I am experiencing this problem on a Mac G5/Panther, a Mac G5/OS 10.2.8, and on a G4 PowerBook/Panther.

Thanks again for your help. I was able to convert the postscript fonts to truetype and now the postscript plot files are created properly in OS 10.2.6. Unfortunately, I had to boot into OS9 to create the truetype font conversion since my font utility does not function in Classic mode, however, this was only a minor inconvenience, but this will be more of a problem when my G5 arrives since it will not boot into OS9.

The fonts are postscript fonts.

I am attempting to work exclusively in OSX, but I am having a font substitution problem in worksheets. I am using VW 10.1.2 and VW 10.5. When I create a postscript file for my service bureau, fonts in worksheets revert to a defauult font (Arial or Helvetica) as opposed to the font in the worksheet. Other text in the file (not in worksheets) prints fine. The same file plots correctly in OS 9.2 (including worksheets). I have checked the VW preferences for font substitution and removed all substitutions. I can create VectorWorks pdf files in OSX which appear to be correct, however, my service bureau prefers postscript files.

Thank you for your quick response. I have been working with this file for two days using VW 10.1.2 in OS 10.2.6 without incident. I reinstalled VW 10.5 and the problem seems to have vanished in VW 10.5. I am not sure what happened, but possibly the initial install was corrupted somehow, also, I ran "repair disk permissions" immediately after re-installing VW 10.5.