Gilbert Osmond

Remarkable that the answer to this question was "No" in 2008 and it's still basically "No" in 2025. It would be very useful to be able to configure the greyed-out level (transparency & perhaps brightness) for each (or all) layers when setting a layer visibility to "greyed." Please consider adding it as a feature in the next major VW release.

Nevermind; I figured it out. I didn't realize that you must have multiple issues defined and then choose to show or hide them on any given Sheet. --------- I'm running VW 2025 Update 4 (Build 802025) under Mac OS X Sequoia 15.4. (Macbook Pro M1, 32 GB RAM.) I am having a problem where I can change the Issue Date, but regardless of whether I do it per Sheet, or if I use the Title Block Manager and try to select just the sheets I want to apply it to, whatever changes I make to Issue Date propagate across all Sheets. Revisions, by contrast, are working as-expected, meaning I can easily & consistently apply different Revision dates to multiple different groups of Sheets within the file. Note: I have tried turning off (unchecking) both "Use Auto Drawing Coordination" and "Activate title block" in the Title Block OIP for each sheet. It makes no difference, the same behavior occurs. Any change I make to Issue date propagates across every sheet in the file.

Bought a license for Ropes + Catenary. Picked up a license for Mouldings while I was shopping around on your web store. Nice work!

Upgraded from VW Designer 2023 SP6 to SP7 without any issues. Macbook Pro 16" (2021) M1, 32GB RAM, OS X "Monterey" 12.6.7.

Upgraded from VW 2023 SP5 to SP6 without any issues. Macbook Pro 16" (2021) M1, 32GB RAM, OS X "Monterey" 12.6.7.

Right... that's why I was hoping there was some way to just do a magic text label that could be applied as a a "wrap" or "send to surface", behaving exactly like a Texture Bed ... but retaining its characteristics as a fully-editable normal text field...

This seems relevant to this topic -- In VW Designer 2023, is there any way to actually wrap editable text labels directly on a 3D surface such as the outside of a pipe? I know this can be simulated using Textures but that's a round-about way which doesn't allow easy, direct editing or arbitrary drag/drop movement of the resulting label. Textures are really optimized for repeating patterns, not single label locations... How do I do a label that looks like this... but is in fact fully wrapped / placed on the 3D outer surface of the pipe, not just "hanging in space" as a planar text label that doesn't show correctly when changing 3D perspective?

Adding my voice to this request. It's illogical for the "Fascia..." option within a Roof PIO to work only on the eaves and not the gable ends. All the gable ended houses in my area have fascia boards that wrap around from eaves up to gables.

This is a massive thread necro, but I'm posting it anyway because this discussion appears close to the top of current (2023) google search results for "vectorworks viewport crop not working." Be sure that what you are trying to crop is in fact on one or more design layers. In my case, for various other reasons I had carefully traced out quite a few 2D design layer objects (building outlines, parcel outlines, etc.) as viewport annotation objects. Viewport crops do not apply to viewport annotation objects! I burned half an hour trying everything else (checking class visibilities, viewport object types, viewport & sheet naming conflicts, etc.) until I finally realized --- DUH! -- that what I was trying to crop out was objects in the Viewport Annotation itself. I just needed to delete the unwanted Viewport Annotation objects (outside my desired Viewport Crop area) to realize that viewport crops had been working fine / properly all along.

Actually, nevermind, I think I figured out my problem. I had attempted to add Record data to the raw object instances within a Viewport Annotation -- so the objects themselves did have Record Data associated. But there was no Record Data attached directly to the original 2D symbols themselves. Since I was using the symbols as the data source for the Graphic Legend, there was no data to pick up. By properly attaching to & editing the field values for the Record Data on the 2D symbols, Graphic Legend now works as-expected.

I am trying to create a graphic legend, using a few simple 2D symbols, to which very simple 2-field Record Formats have been applied. When I go to edit the Cell Layout for the Graphic Legend and create a "dynamic text" item, when I select the symbol's Record Type & Field and try to create a dynamic text component as part of the Graphic Legend cell layout, the Graphic Legend appears to simply ignore the item entirely. It doesn't show up at all in the layout, even as an empty place-holder. When I change the data source for the dynamic text item to be an Object Function (such as "Area"), then everything works fine. Is this a bug, or am I doing something wrong? Note that the Cell Layout is identical in both examples. Here's the PROPERLY WORKING example: And here is the NON-WORKING example:

@Bruce Kieffer, thank you very much for posting the .vwx file for that. It's exactly what I needed, I was able to resize it in one direction by dragging & then just duplicate it along the other axis to get the full dimension of the piece I needed. Then applied a water texture to it which was sufficient to give it a good-enough approximation of the translucency of the sheeting. Regards & thanks

Replying specifically to the "Mac Mini M2 better?" question, based on the MM M2's specs, it's only an incremental performance bump, not a step change. So, only incrementally faster. Not sure whether someone's later reply concerning a Mac Mini M2 possibly throttling (due to heat) on a long render vs. a Studio is on point. Has anyone tested this head-to-head? Seems to me the M2 architecture in general is vastly more efficient than the prior bloated Intel junk, so that heat buildup on long renders may not be an issue? ---- Overall I think that for the majority of VW of users, the current gen. of M1/M2-based hardware is getting close to "good enough," and "fast enough," I.e. there comes a point in photorealistic rendering when the resolution, lighting, level of detail etc. is approaching the max reasonable limits of human perception, beyond which there is no need to go. Dep. of course on size & complexity of the models. Sort of the way smart phone camera tech has ramped exponentially over the past decade, and it's getting to a point at which there are only incremental gains left to be extracted, not massive step-changes in quality / usability.

As it turns out, I cancelled the M1Max 10-core / 32GPU core / 64GB and went for a lesser-spec'ced M1 Pro 16" Macbook with 32GB RAM. It's not due to arrive until mid-late Dec. My reason for going lower-spec was that after reading an Anandtech deep-dive on the M1 Pro vs. Max CPUs , it became clear to me that there's hardly any difference in single-threaded performance between these CPUs. It's only in very intensive multi-threaded and/or GPU-intensive workflows that an M1Max is justifiable. For my needs, the step-up from a core i7 2.6Ghz to an M1 Pro / 32GB ram is likely to fill my needs for at least 3-4 years.

Unfortunately that probably won't ever happen as it would severly undercut Apple's high-end price points on the new M1Pro/Max Macbook Pros while also pushing the Mini in the wrong direction (from Apple's perspective) toward the performance tier(s) of forthcoming MX-powered Mac Pros.