twk

You can do this with class-overrides, per viewport. You can't reassign an obeject's class via viewport, but you can override the graphic attributes of the class via viewport. For your case, just set the glass's class to solid white in the class-settings of the viewport

Yes, we've had issues with project sharing for this. Sometimes user's work would not get committed. Even though they said they did. We also had an aging network cabling system in the office that also needed replacing. So it was hard to determine what was causing the fail-to-commit of these files, as it could be our network, it could be the project sharing implementation. The other headache being, trying to help people understand the concept of a working file, versus a project sharing (master) file, versus a normal vectorworks file. (vwxw, vwxp, vwx). So that route would introduce another new concept (read headache) to get across mindsets. If they are used to 2D symbols etc, this workflow can still be leveraged by having these 2D symbols referenced in, from a vwx symbol file. 'Simple' is a very relative term. It all depends. Sounds like the old guard need to be 'shown' the new workflow. I understand and emphathize with those who have for years have something work trying to understand why things need to change. So you really have to be robust with the reasonings for your changes. For me, 9 times out of 10 the reason would've be the software changes. Somehow I've become accustomed to the saying "the only constant is change". now embracing new things, tried it, broke it, fixed it. rinse, repeat. But I've also had to be very careful implementing change doesn't affect the timeframes, etc.

As others have suggested, this is more or less a HR issue. But your plan is a good start, and take on others' advice on here as well. Also don't change for the sake of changing, if something is working for the timeframes and bottom line, leave it be. Fix and upgrade workflows on a have-to basis. And most of these would also be due to software changes (think the new Data-vis, Viewport Styles, etc features) I have been in a similar position, where implementing new workflows is never applauded. And understandably, you're (we are) basically disrupting existing workflows. What I had done was to take on a project solely, and implement my workflows to show that my way's are faster, more efficient and scalable and transferable. (The last two being the more important aspects). Purge unused classes, hatches, line styles (any and all resource types). Document class structures, resource structures, etc.

As @Jeff Prince mentioned, come up with a 2D/3D Hybrid. I'm curious you mention your experience in delivering 3D projects, is this with Vectorworks? and how has this workflow been for you in the past?

We're currently going through this process at the moment, and I came on here to check if anyone has the same issues. And looks like we're sharing similar problems. Our solution is to have a single file of details that have 2D-Details drawn in the annotation space of the sheet layer viewport. The SLVP's are now using the new Viewport styles feature and all class overrides, data-vis's are on these styles as well. To use these in other projects we just copy and past the SLVP. (You can copy SLVP's across files now!) We use viewports for the SOLE reason of hyper-link drawing reference marker's to viewports. What we wish could happen is that viewport styles, carry annotation objects in them. That would solve alot of copy and pasting between files, and just import via resource manager.

This approach makes sense for this particular setup

Yes our class naming conventions are similar. ie prefixed (.DEMO-class_name, .EXTG-class_name, class_name <- for proposed/new). With regards to new windows in existing walls, this is a common headache. Our workaround is to mark the extent of the existing wall being affected by the new window as demolished on the EXISTING/DEMO design layer, and copy and paste in place that portion onto the PROPOSED design layer, however this pasted wall is classed/tagged as existing. Then we place our new window joinery onto this 'existing' wall on the PROPOSED design layer. Sounds confusing to write out, but super easy in practice, with the correct classes and tags applied. The great thing about data vis as well is that it works in 3D, and if you tag a plugin object you dont have to worry about internal plugin class structures. (Which was the headache we had with using WinDoor). We would approach this with our workaround 🙂

We use stories for new builds only. I can't recall from memory where using a story in an alteration/extension job was necessary. To your question about 8 existing plans. Yikes! Is this an apartment complex or multi story project, that youre doing alterations to each level? Our rationale of using an existing snapshot design layer came about when there were too many instances in the past where we're doing design options, and we have nothing to revert to. I would in your case of 8 existing plans, keep that in a separate file altogether. Then you'd have a 2 Design layers for each altered level (Existing/Demolished, Proposed Works) And then yes, the sheet setup for Proposed Plans would have a viewport with those 2 layers visible and classed/data vis'd for each phase For the sheet for the Existing/Demolished, we would have the viewport only show the existing/demolished design layer visible, again with appropriate data vis/class setups. With the new Viewport Styles, this has dramatically saved time with drawing management.

We use a combination of Design Layers and Record Formats and Data VIs (and a bit of class setup) to manage existing, demolition, and proposed work. Typical setup: Design Layers: EXISTING - This layer contains the as-built plan, which remains untouched and serves as a snapshot of the existing conditions. EXISTING/DEMOLISHED - This is the design layer where we draw the existing conditions and indicate demolished elements during the design process. PROPOSED - This layer is used for all proposed objects. During drafting and design, this layer is always overlaid with the EXISTING/DEMOLISHED layer to maintain context. We also incorporate Record Formats with a 'Construction Phase' field that has three options: Existing, Demolished, and Proposed. This allows us to use Data Visualization for both visibility and graphical overrides, similar to Tom W.'s setup. We find that keeping the EXISTING layer untouched as a snapshot helps us refer back to the original conditions easily.

Not sure about blender, but when I used to work in C4D (back in the early 00's), there was retopo feature, that basically draped the dtm imported, to sort of retopologize the geometry. I wonder if blender has a similar feature?

Hmm, not following, you mean the square edge? Screenshots please Mind posting or DM'ing your model so far?

working fine here, make sure only eave is selected as square cut, leave hole as vertical:

Sure, attached Forum_RoofQuesion.vwx

My attempt below (sped up x2) about 30mins sped up to 12mins. - Started by sketching out overhang widths, then hip lines - Was a bit confused by profile ratios but i think i got it to be as close to yours as I've decipher (rise/run, 18/12, etc). But wasn't sure what the eaves are doing, I believe they're changing pitch to match other roof of differnet pitch - Got stuck at right side where ridge heights differ 😂 If you could send through your model, I could maybe have a better understanding of the roof changes. I'm thinking they 'could' be all achieved by using roof faces, but not holding my breath. - Hopefully you can see in my screengrab that the connect/combine tool is quite apt and easily used once you get the hang of it. video is about 12mins! you can skip through. https://drive.google.com/file/d/1ehIEb3QhnjsxZ01W6gAXnqyebCvZ7rXB/view?usp=sharing

Nice model! FWIW, these would be easily achievable with roof faces. If you're trying to get roof faces with different pitches to match, you could use the connect/combine tool to get the hip angle (in plan), then you'd use that to make up the roof structure. In regards to your initial question with solids modelling, I have also noticed solids going awry after many operations, as I'm guessing theres some sort of limitation to recording the number of operations for solids modelling (add, subtract, intersect, etc). I'll have a crack at your roof structure above when I get some free time, to see if I can replicate that model with roof faces.