twk

Icons for Plugins PNGs Need 2 versions, standard and Retina version, and for each a light and dark version (total of 4 files) Normal 26x20 - tool.png // Dark Version = tool_dark.png Doubled 54x40 - tool@2x.png // Dark Version = tool_dark@2x.png Must be 72dpi Icon size must be 26x20 pixels SVGs Need 2 versions, light and dark (total of 2 files only) Normal 26x20 - tool.svg // Dark Version = tool_dark.svg Must be 72dpi Icon size must be 26x20 pixels Online PNG to SVG Converter: https://svgconverter.app/free Online SVG Resize: https://www.iloveimg.com/resize-image 1. Develop or design icon in Vectorworks, to a 26x20 region. (I set a rectangle at this dimension, and set line weight to <None>, and have loci’s at top left and bottom right for easy snapping during export (where you’ll have draw a marquee around region for export). 2. Export png @72dpi. pixel dimensions can be whatever, but higher dimensions are better for svg conversion 3. Upload image to https://svgconverter.app/free. Vectorize, and download 4. Go to https://www.iloveimg.com/resize-image, upload, and resize to 26x20 5. Resize Image then download on next page: 6. You now have your svg file sized to the correct 26x20 dimensions, import now into your plugin via the Vectorworks plugin manager.

Ok, so the solution is to also have a dark version (if you're on windows i believe): So all these must be fullfilled: - icon.png (72 dpi) 26x20(pixel wxh) - icon_dark.png (72 dpi) 26x20(pixel wxh) - icon@2x.png (72 dpi) 52x40(pixel wxh) - icon_dark@2x.png (72 dpi) 52x40(pixel wxh) Works now

This is not working in 2024, when selecting an icon for a custom plugin: Workflow tested: - icon.png (72 dpi) 26x20(pixel wxh) - icon@2x.png (72 dpi) 52x40(pixel wxh) Anyone successfully assigned icons to a custom plugin/tool in Vectorworks 2024?

the dailogHandler should have an init check portion. which is a constant stored in SetupDialogC (SetupDialogC = 12255) if item == SetupDialogC: # do initialisation stuff here pass Search forum for this.

my code for checking if a named object exists is below: test_name = vs.StrDialog("Test Name: ", "") if vs.GetObject(test_name) not in [0, None, vs.Handle(0)]: # do stuff here pass

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?