Gilbert Osmond

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.

M1Max has 10 CPU cores, 32 GPU cores. I went for the 64GB RAM option. 2021 MB Pro 16". Looking forward to seeing how some of my more complex models run on this, compared to my 2019 MB Pro 2.6Ghz core i7 / 16GB RAM.

Is anyone else getting a "Product update check failed.." error when manually selecting Vectorworks --> Check for Updates in VW 2021 SP4.1? I know my internet connection is working fine. I'm thinking maybe it's a temporary server glitch on Nemets / Vectorworks side because other updates (for example Resource updates) are working fine, and my recent update to SP4.1 a couple of weeks ago also worked fine. I did already try rebooting my MacBook Pro & the problem persists.