Markus Barrera-Kolb

@rowbear97 I've so far not been able to reference worksheets from other files, only import, which of course doesn't bring the data over. When I reference a file and then right-click a worksheet in the referenced file, there's no option for referencing (like there is with other resources). Do you have a solution that works for this? Thanks!

Thanks for all the pointers, @Diamond, and for confirming that others are successfully using Vectorworks for larger projects encompassing multiple buildings. A couple of follow-up questions, if you have a moment: Makes sense that you model each building in its own file; do you then create the corresponding drawing sheets in those respective files as well? If you do generate sheets within multiple files, do you create your drawing index manually, or is there a way to pull information for sheet layers from multiple files into one index? Do you repeat identical interior layouts for dwelling units as multiple copies of design-layer viewports or do you create a symbol for each of these? It makes sense that these would only comprise the interior walls and that the shell would be modeled separately. Having one dedicated library file also makes a lot of sense; this would take the guesswork out of where to find shared resources... Thanks again!

Thanks @DBrown — one thing that makes me think VW is intended to accommodate drawings sets spanning multiple files is that when you open the Title Block Manager while more than one file is open, it'll ask you whether you want to load the currently open files along with the active one. This would only make sense if all of those files belonged to the same project. If that's indeed the case, presumably the VW developers have also thought of a way to do a drawing index that includes the sheets from multiple files. Does anyone have any experience with this?

...still hoping for some feedback on this topic if anyone has any insights / recommendations on the above points. Thanks in advance, and hope everyone is well!

Looking to pick this thread back up, as we're about to start on a multifamily project comprised of five separate buildings with a total of 52 dwelling units on 4.8 acres. I've got lots of experience using VW for single-family projects modeled in 3D, always in just one file, but in a multi-user environment with a project of this size I assume it's a given that we'll need to split the project up into several files. Similar projects in our office were previously only drawn in 2D, but we'd like to take a BIM approach here. So here are some questions in no particular order: If we draw sheets in more than one file, is there a way to pull all the sheet layer / title block information into one drawing index? Also if sheets are distributed across multiple files, what's the best way to have the title block graphics & data fields synchronized between all the files? Our office used to just reference a separate title block file and display the graphics in a sheet layer viewport, but that approach didn't take advantage of sheet border & title block functionality. Is there a file size / computing load advantage to making repeated unit layouts into symbols rather than multiple (cropped) design layer viewports? In a separated core / shell & repeated unit approach, is there an effective way to deal with fenestration? That is, door and window objects would need to be inserted in the shell, but the fenestration locations probably want to be determined by the unit layouts. If each building is modeled in a separate file, what's the best way to share / coordinate window & door styles for consistency across the project? Suggestions on the above and any other pointers are greatly appreciated! Hope everyone is well and healthy during this crazy pandemic...

...I've got the exact same question! Also wondering whether there's any way to control the format, e.g. number of decimal points, of a function such as the area of a polygon used to delineate an occupancy space, other than the global setting for area quantities. In other words, I may wish to have my standard area units to be square feet with two decimal points, but wish to have my occupancy tag only display whole square feet (no decimal points).

I did look and see that the shortcut assignment for the Fit to Objects command was correct, so likely something else in the workspace is indeed corrupt. I've customized a lot, so I definitely don't cherish the thought of re-creating it. Do you know if there's a way to print out a summary of the customizations? Thanks!

...just brought over my old workspace and now it's not working again. When I switch back to one of the default workspaces it works—I'll have to see if I mistakenly added a conflicting shortcut; otherwise perhaps the workspace is somehow corrupt?

Marissa—with a fresh VW user folder it does now work. Thanks! Now to copy over my workspace, plugins, and re-configure my preferences and palettes...

Yeah, unfortunately it's not working at all on my end. No matter what the view, render mode, or Navigation Graphics settings...

I'd hoped that SP3 would remedy this, but for me Zoom > Fit to Objects is still not working (running VW Arch 2019 under Windows 10). Anyone else encountering this? I'd spoken with a tech a while back who confirmed that it was a known issue under SP2. Basic functionality whose absence definitely impacts my workflow negatively!

Thanks, Julian – don't quite know how I've used VW for over 10 years without knowing that! Now I can forget all about that silly script... Cheers, Markus

I've been using a simple script for years now to de-select all objects, which is particularly useful when I'm zoomed in or working in 3D with no empty space to click on in order to de-select objects (works nicely with a <shift><cmd><A> keyboard shortcut). However, this script no longer works for me in 2019. I've tried re-compiling it, double-checked that the DselectAll VS function still exists, and re-assigned it in my workspace, but it still doesn't work. Any pointers? Thanks... Cheers, Markus PROCEDURE DeselectAll; BEGIN DSelectAll; END; RUN (DeselectAll); Deselect All.vsm

Thanks Raymond - looks like a restart did it! Odd enough, given that I'd already restarted it prior, but I guess you never know... Cheers, Markus

I'd been using a script with VW2017 and VW2018 that set the view to normal perspective and the render mode to OpenGL, in part because I'd found that if you activated the flyover tool while inside a group, the default view and render mode were ignored, and also because there's a small lag before you can use the SpaceNavigator 3D mouse after activating the flyover tool. The script worked great in '17 and '18, but now I'm getting this error with it in VW2019: Error on line=3: PERSPECTIVEOPENGL DOMENUTEXTBYNAME – Menu cannot be found. Projection. Here's the script: PROCEDURE PerspectiveOpenGL; BEGIN DoMenuTextByName('Projection',5); DoMenuTextByName('OpenGL Render Chunk',1); SetPref (1320,False); SetPrefReal (127,6.0); END; RUN (PerspectiveOpenGL); Any help is appreciated – thanks! Cheers, Markus Perspective+OpenGL.vsm

It looks like collinear (colinear?) constraints only act on the centerline of wall objects. Given that one of Vectorworks' weak points, IMHO, is the difficulty in keeping multi-story building envelopes aligned – who here hasn't spent way too much time chasing down those horizontal lines between walls that somehow just won't stack perfectly? – it would be great to be able to apply the collinear constraint to walls based on specific wall components, rather than just the wall centerline. If all exterior wall types were exactly the same this wouldn't be an issue, but the fact is that almost every project has at least a foundation wall type and an above-grade wall type, if not more, and these are usually different thicknesses. This feature would allow you to make sure that, for example, the exterior face of the concrete foundation wall would always align with the face of stud above...

Tom – totally agree with you. Without being able to have a single overview of the issue data where one can also edit & amend it, the system is just too unwieldy and cumbersome. And this should be completely separate from the title block and data field setup. Again, we're now using our own sheet-specific record fields for our issue data so we can manage it all using a worksheet – see attached. Works well for us, but it's regrettable that we don't get something like this 'out of the box'. Cheers, Markus

I've encountered this as well, with the added gem of, on several occasions, having VW suddenly undo multiple drawings steps without the ability to redo them. Each time after this has happened I then noticed that the information displayed in the OIP referred to the other open project. Cheers, Markus

We're still using the Data Stamp (Dims/Notes tool set) within the title block definition (Layout) for this – seems to work OK. Cheers, Markus

...I can't imagine that the intent is for surface hatches to only align with their respective textures when in Top/Plan view rather than in a 3D view, or am I misunderstanding? Here's the file with an extrude I just created in Top/Plan view, with no H or V offset, and the hatch still doesn't align with the texture, regardless of the map type. I think this whole feature is either buggy as all get-out or insanely difficult to use correctly. Wish it'd get fixed! surface hatch alignment 2.vwx

Thanks Alan, I've done that, and I often get misaligned surface hatches regardless of whether the mapping is set to auto or not. In the attached file, for example, it's set to Auto-Align Plane, but the Texture and Surface Hatch still don't align when you switch between OpenGL and Hidden Line rendering (let me know if you get a different result with it)...

Is anyone else regularly having trouble getting Surface Hatches to align with the Renderworks Textures they're assigned to, in spite of them aligning perfectly within the definition? I'm getting all sorts of different results based on the object type (parametric, e.g. walls, generic solids, extrusions, etc.) and the Map Type (Plane, Auto-Align Plane, etc.). Only rarely do the geometries coincide as expected when switching between, say OpenGL and Hidden Line render modes. See the attached example with an extrusion – here the pattern jumps horizontally for me when switching between the render modes. This is really frustrating our efforts to go fully 3D and get both our 3D and 2D views from the same model, as one uses OpenGL or Renderworks, and the other Hidden Line... Cheers, Markus surface hatch alignment.vwx

...weird, the workspaces are essentially identical – certainly both have these commands in their original menu positions – but I just loaded my home laptop's workspace on my work machine, and now the script works on both. Go figure! Thanks for your help & feedback everyone! Cheers, Markus

Kevin, et al, I'm confused – I was working on my laptop at home yesterday when I got the script to work with DoMenuTextByName (see below). Today I installed the identical script on my machine at work, also running VW2018 SP2 with the same workspace, and it refuses to run, giving an error message saying that the menu cannot be found. I have no clue what's amiss... Any ideas? Thanks! Cheers, Markus PROCEDURE PerspectiveOpenGL;BEGINDoMenuTextByName('Projection',5);DoMenuTextByName('OpenGL Render Chunk',1);END;RUN (PerspectiveOpenGL);

Thanks Kevin, your syntax for DoMenuTextByName did the trick! Now I can reliably switch from Top/Plan into my preferred 3D view even while inside a group! Cheers, Markus