Gilbert Osmond

Hmm. For some reason, "Options" doesn't show in my list of available items, thus I have no way to select "Delete" Perhaps it's something to do with my access "level" on the VW support forums?

It looks like the vision panel you had defined was too wide for the leaf width, when taking into account the 120mm offset from the strike. By making some changes to the panel dimensions I was able to get a panel to show as-expected. You might also want to un-check "Show leaf as solid slab" in 3D detail levels, although by default this only occurs if the overall view level is set to "Low" detail. (Note: I made these changes on a door which I had converted to Unstyled.)

---- deleted content, irrelevant, see better answer below. It's annoying that VW doesn't allow posts to be deleted from the VW forums.---

Update: This issue is solved by going to Vectorworks --> Preferences --> Display, changing the setting from: "Best Performance" to "Good Performance and Compatibility." Hopefully the root cause will be fixed in a future Service Pack update so that it's possible to go back to using "Best Performance."

Query: What is the source of new, long, straight line display artifacts that are affecting on-screen display (not PDFs or print-outs) of drawings which have a certain Class visible, said Class using a custom Line Type resource? Is this a user error on my part due to known changes in handling of custom Line Types in VW2020 vs previous versions? Or have I come across a genuine bug? Background: The file is a native VW 3D model (built natively within VW2016 and then brought forward year by year, importing/updating the file to VW2017, 2018, 2019, and 2020 in successive years) All sheet layers / viewports with annotation elements which contain are set to a specific, isolated Class have developed an annoying and reproducible display artifact. Characteristics: See attached screen capture of a Sheet Layer with 2 separate viewports on it, both set to Top Plan view. I've marked many (but not all) of the artifact lines with red dots to distinguish them from items that are supposed to be in the drawing. (Some of the shorter artifact lines I left un-marked to avoid visual clutter. The short artifact lines generally follow the direction of one or more of the large artifact lines.) These artifact lines zoom in & zoom out normally with the rest of the drawing, but they disappear temporarily during dynamic movement / zooming. (They only show up again after zooming or panning in Top/Plan view has stopped.) The artifact lines cannot be selected or force-selected independently. They only appear in on-screen display within VW, they do not export to PDF files or print out on hard copies. Changing VW's live rendering modes (wireframe, hidden line, OpenGL, Polygon) etc. does not affect the artifacts, nor does changing any of the many display-related settings within each viewport itself. Reproducibility: By process of trial & error I isolated the artifacting to a single item Class, for which the "Line Type" is set to a custom-made Line Type resource. When I turn off the visibility of that Class in the viewport, the artifacting disappears. (Along with the objects in the Class, of course.) When I change this Class's line type to a default / built-in VW line type (dashed, short dashed, etc.) the artifacts also disappear. They come back when I re-apply my custom line type. This persists even after creating a duplicate of the custom Line Type. Changing the Line Type's settings from Page Based to World Based (and back) makes no difference in the artifacting. The shapes to which the Class is applied that has the custom line-types were added back when the file was still in VW2019 format, as was the custom line type resource itself. The artifacting only appeared sometime after converting the file to VW2020. Further details: Here are the details of the Class and the custom Line Type: Please advise whether I am overlooking something obvious, or if this is a legitimate bug in VW2020 SP2. If the latter I'm happy to assist Nemetschek/VW in further characterizing it or testing fixes if appropriate.

I had a very interesting / concerning episode with annotations in a viewport. System: Mac OS X Mojave 10.14.5, MacBook Pro 15" 2017, internal display only. (No eGPU.) VW Designer 2019 SP4. Summary: Seemingly random/strange crash, followed by weird SBOD (beachball hangs), eventually seemed to be fixed by temporarily disabling network /WiFi while running VW. Unfortunately cannot reproduce or thoroughly document; sequence of events / attempted fixes too long & complex. Details: While moving a normal 2D object (just a simple overlay) in the Annotation layer in Top/Plan in a viewport, VW 2019 SP4 abruptly quit (entire app crashed out & disappeared, no hanging or delay.) This object had been added earlier in the day (a few hours) and was working as expected up to that point. (Move / adjust size / opacity / etc.) Upon re-opening the same doc, the app crashed in the same way. I figured the file itself had been corrupted. So, I opened a recent auto-created backup of the same file (~15 mins earlier) and got the same behavior. A hard crash. I tried rebooting and chucking out VW cache folders but that made no difference. I downloaded & reinstalled VW2019 from VW Service Select. That fixed the hard-crashing problem, but curiously, now these same files worked fine in all of the many (40 or so) sheet layers & viewports in them, but on the "problem" viewport, when I attempted to edit annotations, instead of a hard crash I would get a seeming SBOD (spinning beachball of death) hang. After poking around on the forums here I tried doing the "Refresh Library" command in the Resource Manager, along with turning off Wifi for a bit, and this seems to have completely fixed the problem. The viewport annotations in question now work as they ought to & there is no more "hanging."

It's a bit of a round-about path to get to my real underlying goal & wish here, but the reason I've inquired about this is that when I use a linked field (in the new 2018/2019-style "Title Block Border Settings --> Edit Style --> Title Block Layout" editing area,) I want to be able to link the text parameter "Title Block Border.Sheet Size Name" to a field in my Title Block and have that field display correctly when I select a non-standard paper size. For example, I do a lot of small US LETTER and US LEGAL-size drawings and details and I would like the "Sheet Size: " to appear as "US LETTER" in my Title Block, rather than having it default to displaying the actual measurements 8.5" x 11", which is what it does now if there is no named preset paper size corresponding to the actual measurements. So I was hoping to add a "US LETTER" and "US LEGAL" sheet size definition to the overall VW default paper sizes and thereby fix this problem. --- As a work-around I've been manually entering the sheet sizes in a custom-added field in the Title Block Manager on a per-instance (not per-style) basis but this is getting unwieldy.

Thank you, that does allow me to add page sizes in the Title Block Border Settings dialog box. What puzzles me, though, is that the new sizes I created do not show up in the regular Page Setup dialog box. Is there a way to edit this list of paper sizes as well? I already went in to Printer Setup... and selected "Any Printer," then returned to this screen & hoped to see the full list of paper sizes, but it only shows a truncated list. (Screenshot from Vectorworks "Page Setup")

Where can I add/edit/delete VW's default Sheet Sizes? For example, if I want to add MySheet X, MySheet Y, MySheet Z to the drop-down list in the screen shot below, how do I do that? I've spent 45 minutes reading VW Help, searching this forum, & digging through the VW system folders looking for defaults. Thanks in advance.

Bumping this feature-request. Trying to do a section viewport including a DTM and it's a complete fail. DTM portion is opaque & shows no sub-surface details, e.g. footings & posts for a fence in this case. Need option in SVP to control how objects appear when a DTM is included -- totally hidden (as they are now,) or totally exposed (showing only the ground surface line of the DTM,) or dashed-hidden-line render below the DTM surface.

Now that VW supports multiple views / windows / open files at once it would be nice to have a way to force referenced design-layer view ports to update in real- or near-real-time. As it is now, when I make a change in referenced file (say, moving the height of a fence panel,) in order to see the change in the other file with the DLVP in it, in the main file I have to do: Tools --> Organization..., then select the "References" tab, then select the referenced file, then click "Update", after which the changes propagate from the master file to the DLVP. It'd be nice to have a check-box in a DLVP for "Auto-update this viewport whenever the referenced design layer changes." Is there any work around for this? Editing the workspace doesn't work as it doesn't allow for auto-navigation within the "Organization..." modal dialog box, nor for assigning a shortcut to the "Update" button in that dialog box. EDIT: this should be posted in General -- moderators, please consider moving it. Thanks.

I've delved further into this issue. It appears to be an oversight in VW's development process, i.e. someone simply forgot to include the "Existing/Proposed" toggle in the parametric Hardscape object. - I called VW support & a tech reproduced the issue. - We tried to work-around by attempting to right-click and Edit the internal properties of the Hardscape object, but to no avail -- there's no way to display or edit the Site Modifier object that is presumably hiding somewhere inside the Hardscape Object. - He said he'd double-check with other support staff, then submit this as a feature request / functionality fix for a future update. Attached are screen shots: The Site Modifier object can be set to apply to the Existing, or Proposed site model. But the Hardscape object cannot. (!) The work-around is clumsy: Set the hardscape object to be a Slab (which does not modify the site,) then copy the hardscape object shape, paste it elsewhere, Ungroup it & remove any slope tags, then use Create Objects From Shapes... to create a Site Modifier object from that hardscape object shape, then configure the Site Modifier object slope(s), & apply to Existing/Proposed site model setting, then move the Site Modifier object onto (aligned with) the Hardscape slab object & group the two together. When dealing with 10 or 15 slabs across a model this is time-consuming & a nightmare, esp. if any of the Hardscape Object slab + Site Modifier groups need editing. Requires temporarily Ungrouping the group, editing the Site Modifier object only, regrouping, etc. Attached screen shot shows where the "Existing / Proposed" exists in the Site Modifier OIP, but not in the Hardscape OIP. I can't believe more people haven't complained about this. How does anyone sanely model an as-built site without being able to use Hardscape objects and have them apply to the existing site?

I am bumping this topic -- I'm running into the same problem, in a different project, 1+ year later. What am I misunderstanding here? Is there some reason why Hardscape objects can only apply to Proposed site model, rather than Existing site model?

SOLVED -- yes, somehow just that facet of the roof had lost its fill color in Top/Plan. Fixed as follows: - Go to Top/Plan - Select the entire roof (1 click) - Use Attributes panel to set fill to None. - Then set the fill to a solid color. - Then set the fill to a hatch. After that, the Class *tile* fill becomes properly visible again in 3D OpenGL view.

The dormer is "part of" the roof, i.e. it was added there automatically using VW's built-in dormer-creation feature. It is not a separate 3D object. Strangely, when I select the whole roof, change the fill to a solid color, then try to change the fill back to the proper tiled fill (i.e. what it looked like before,) I now get a *reversal* of the effect. The whole roof becomes transparent, while the dormer is properly tiled (!). ?? Still lost here.