Hugh Chapman

Both of these apply with our current set up. I'd be interested to understand more about why this set up is liable to cause issues with backups if you or anyone else are able to provide a bit more technical insight? Many thanks

An issue we have with this option is that because multiple people will work on a project file, backing up locally would mean that not everyone would be able to access the backup files if required... It could become quite messy trying to track down a particular backup if/when needed. So it sounds like backing up to the cloud may be our best option to explore..? Many thanks

Hi @shorter thanks for replying. Any idea why..? I'm not sure we experienced it with VW2025 (although I might have forgotten/not want to remember!), certainly not as often as these recent two incidents with VW2026 suggest in terms of frequency... We're backing up to a physical server. Potentially something we can change, although we don't understand why this would be more problematic than backing up to the cloud or local desktop..? This feels like something that VW devs should be looking into? I'm not content to simply accept that this is something that just happens from time to time! There will always be times when the backup folder is an essential - well - backup! In the meantime we will user-save more often and look into changing the location of our backup.

We've experienced this issue on at least two occasions now: VW2026 crashes and the most recent autosave in the VW Backup folder is more recent that the last time the file was actively saved. But when we open the most recent autosave in the VW Backup folder the file isn't as up to date as it should be. I.e. the autosave backup file doesn't include changes that were made in the file before the time of the autosave. This is not good! Has anyone else experienced this issue? We're runnnig 2026 Update 4.0.1 build 854846

We have an issue with one of our VW2026 model files. The issue is that every time anyone tries to activate the Curb tool, this instantly causes the file to crash-close. This happens across multiple machines, so the issue seems to be something in the file itself. In trying to diagnose the issue I've so far tried: 1) turning off all classes in Apply Send to Surface by Class for each Curb Style in the model. This has sorted out the 3D curb paths which weren't looking too healthy 2) Editing Curbs so there aren't any curbs crossing in the model. This means leaving odd gaps where curbs don't meet at 90 degrees - (Not being able to cut curbs at an angle is less than ideal - I and others have raised this as a feature request for some time now. I'm not sure if/when this functionality will be added but this is another issue!) I don't know if (1) or (2) could be the cause of the crash-close issue when activating the curb tool but they felt like reasonable fixes to try. However the issue persists. Has anyone else encountered this kind of issue? Does anyone have a fix or ideas for other things I can try to resolve the issue? Many thanks

many thanks for the explanations @HebHeb & @Katarina Ollikainen - problem solved!

We regularly encounter the following issue when importing topos - Spot heights in 3D topo surveys we recieve are generally represented by block instances. These are generally simple crosses made from two lines - We can open 3D topo surveys in Autocad/Rhino and confirm that these spot heights have the correct z-value (15.75m for the example above). But when we import the 3D topo dwg into Vectorworks, VW converts these blocks into symbols which are all at z=0. i.e. VW unhelpfully loses the z-values of all the spot heights when importing 3D topos. I can't find any import setting to avoid this 'flattening' of the spot elevations. Our workaround for this is to open 3D topos in Autocad/Rhino, update the spot height block instances to contain only points, then explode the blocks. Then when we import into VW we can tell VW to convert these points to 3D Loci, thus retaining the z-values of the spot heights. We want these spot heights to generate a site model. Am I missing something with this? Is there a better workaround for this in VW itself..? Thanks

Thanks for this explanation @Katarina Ollikainen. I for one have been conflating "it has the correct cartesian coordinates" with "it's georeferenced". Very good to know to check whether a file has a Coordinate Reference System when importing. I still haven't fully got my head around the reason for and uses of VW's multiple origins, but this helps.

Possibly not much help but - Is this issue consistent? I.e. do you experience this issue 100% of the time when importing georeferenced dwgs or just some of the time? I ask because I have occasionally experienced exactly this bizarre and exasperating behaviour in VW2025...

Many thanks for this @HebHeb I still haven't had a chance to test the VW2026 Grade updates, but it sounds like the workflow issues I'm highlighting remain..? I'm considering making a feature request that would be something like "Grades only link to grades/grade networks *on the same layer*". To me this seems like a better default behaviour for Grades but if there are advantages to the current behaviour then I will request this to be enabled as an option. Would you and any others interested support such a feature request?

Hi @Jonk, Yes I can set the mode to "Use Grade Object Heights" but the issues I'm asking about/highlighting remain: New grades attach to existing grade networks by default, even when the existing grade network is on a layer that's turned off. If there's a way to adjust to this behaviour I'd be very glad to know of it! If the new grade attaches to the existing grade network not at a node it creates a break point in an existing grade. Not the end of the world but not ideal. If I want to change the elevation values of the new grade without adjusting the existing grade network I need to 'detach from grade network' before changing elevation values. Again this is not the end of the world but things quickly become messy if I want to create a new 'sketch' grade network in order to test out new levels across an area. I think the simplest way to resolve these issues might be to enable a way to set up Grades to only attach to grades/grade networks on the same layer. Possibly this could/should be the default setting for Grades..? If I'm missing something please let me know. I know the Grade tool has had upgrades in VW2026 - any changes in terms of the functionality I'm asking about here? Thanks

A site modelling workflow question - A lot of hacking around and leanrning through trial and error has led me to conclude that grade networks with grades in site modifier mode are generally a reliable approach to site modelling. But there are some workflow wrinkles I'd like to iron out in relation to making changes/updates to levels in a model - Q1: If I need to rework levels in a particular area of a model, Grades are an invaluable analysis tool to figure out what is possible. But if I've already used Grades as site modifiers, the new 'sketch' Grades I'm using to figure out adjusting the levels seem to connect with the existing 'site modifier' grade network, even when this 'site modifier' grade network is on a different layer and turned off. Can anyone recommend a way to avoid this? Is there a way to stop Grades linking across layers/ even when layers are turned off? Q2: On levels plans I generally want to display some but not all of the 'site modifier' grade network as slope annotations. My approach currently is to copy Grade annotations onto a new layer, set the Grades to 'Grade Levels Only' mode and adjust other display settings to suit (generally turning off 'show elevation' and 'show line' etc). This works ok but means I need to update two sets of grades when making changes to levels... Can anyone recommend a better approach..? Thanks as always

I'm pulling quantities out of a model. For Hardscapes and Landscape Areas I can use the Select Similar tool with class and object type to select all instances of any particular Hardscape/Landscape Area type and the OIP gives me a total area - handy. But for Curbs the OIP will only show me the length of a single curb instance. No combined length if I select more than one curb... Would it be useful to add this functionality as a quick way to add up curb lengths? Update - Adapting a Fence Schedule didn't take long and means I have a fast way to update quants if there are design changes -

Ah! Many thanks - I had looked there but hadn't checked the Fields Visibility list! I look forward to exploring planting design workflows in VW2026 at some point soon

Many thanks for this @Tom W. It's odd this is where I would expect to find it but I can't see it! - Any idea why this field isn't showing up and how I can get it to show up..? Many thanks