Custom Classes - What is your system?

[E|FA]

My understanding is that 'Site-DTM-Modifier' is not changeable (similar to None and Dimension classes).  It is extremely useful in that placing  3d polygon (and other?) objects into this class turns them into site modifiers.  This is not well documented in the help system

 

https://app-help.vectorworks.net/2021/eng/index.htm#t=VW2021_Guide%2FSiteModel1%2FSite_model_modification_overview.htm

[Rossford]

I think you have to use that class exactly as VW labels it, at least that has been my experience as well.

[hollister design Studio]

@E|FA and  @Rossford  Got it.

 

Unfortunate

 

...although I have no issue renaming 'Dimension' to '00-DIM' and 'None' to 'NONE" them staying renamed.

[Christian Fekete]

@Taproot do you create a text file and then a .sta file uploaded in VW or is there a prefered process ?

great post, thanks for starting this

 

[Taproot]

On 12/5/2020 at 6:32 AM, Christian Fekete said:

@Taproot do you create a text file and then a .sta file uploaded in VW or is there a prefered process ?

great post, thanks for starting this

 

 

Christian,

 

I'm not sure exactly what you're asking.... as far as creating an office template, we did that in VW directly (no text file). 

Our plan was to use the template as a beta for active projects and weave back in refinements to the master standard.

 

Instead, what we've found is that the "template" is constantly being upgraded with minor tweaks and refinements.  We have a small office, so this is feasible... a larger office would likely not have this level of flexibility.

 

[Mark Aceto]

I would definitely be interested in a master template CSV file that I could maintain without having to open VW and enter dialogs. I find myself doing some version of that with many things in life (outside of VW). Very quick to edit, and then import. Would kill for that with workspaces too. I just get overwhelmed by all of the tinkering and fiddling with settings buried and scattered all over the place.

 

Edited December 7, 2020 by Mark Aceto

[PLENZEN]

I also like the 9 class limit. Clutter is driving me crazy.

 

Does anyone know if you can have callouts by default to an ANNO class for example? Dimensions do this out of the box, but I really need callouts to do it for simplicity

[Boh]

For me more classes = more control not clutter. It does require more consideration in how it is set up however. We use hundreds of classes but with a hierarchical setup they collapse down to a list of just 14 lines.

 

To my knowledge you can’t have callouts go straight to a particular class on creation unless that class is the active class.

 

You might be able to create a script using the custom visibility tool that would select the callout tool and place the callout on a particular class. Downside is that after creating a callout it would revert back to your previous tool selection. So to make multiple callouts you would have to select the script multiple times.

[PLENZEN]

I will have to look into making a script - pros and con, but it may work for me.

 

The problem I am having with having a lot of classes (for me clutter) is that even with hierarchy I have to wade through especially since VW does not automatically put some objects on a class and I miss selecting the class when creating the item since some and some do not. I am totally with you on the control and flexibility of classes.

[E|FA]

2 hours ago, PLENZEN said:

Does anyone know if you can have callouts by default to an ANNO class

Try using the "Custom Tools/Attributes" command, and check the Tool and Class boxes while the Callout tool and ANNO class are selected.  I believe the downside is that you lose the option of using key commands for the tool, and have to double-click in the script palette to activate.

[Pat Stanford]

Since Custom Tools/Attributes just creates a script, you could relatively easily make a Plug-in Tool from the script and then add that to the workspace and give it a keyboard shortcut. I think you could even remove the original Callout Tool from your workspace and just replace it with your Custom Tool script. But I would recommend keeping the original as a secondary function of the Tool icon.

[Boh]

1 hour ago, E|FA said:

Try using the "Custom Tools/Attributes"

Yeah this is the one. I mistakenly called it the custom visibility tool in my last post. It produces a basic script. An actual scripter (I.e. not me ) could no doubt produce something more like what you want.

Maybe another workaround option is to make a callout a green symbol set to be assigned to the ANNO class on insertion?

A blue symbol is set to convert to a plugin object or group on insertion rather than stay as a symbol. Might be worth a try.

 

Edit: Yes I just tried this and it does work as a simple workaround. (Should have said a green symbol not a blue symbol tho...)

 

 

Edited December 16, 2020 by Boh

[PLENZEN]

Thanks for all the responses. I'm green to VW but things are starting to all make sense once you ignore the Revit and AutoCad mindset. And VW is very adaptable and allows for a lot of flexibility. Again thanks for the assistance.

[PLENZEN]

Thanks for the video... you guys/gals rock!

[blanger]

On 7/13/2020 at 10:29 AM, Taproot said:

@Boh Yes, I've come around to using page based hatches for different scaled viewports.  That most commonly applies to sections and details.  Formerly, I had two copies of each hatch, so that details displayed an enlarged version.  Now that we're using class attributes for everything, I've found a single (compromise) hatch works pretty well.  It's not quite as good (aesthetically) as it was, but it's fast, consistent and still reads well.

 

Have you found a better method?

 

I've been enjoying your posts as it seems we're at similar places in our skill development and you're often tackling the same issues I am.  Your solutions are often excellent and save me loads of time in the process.

 

Hey @Taproot 2 years later have you found a better method? I use the compromise approach. A bit more spaced out hatches when viewed in 1/4" yields bearable FSDs. This drives me crazy and Ive wishlisted hatch scaling for viewports, which would be great once they release the ability to save a Viewport style. You can see the wish up top popular wishes for the last month... 

 

Edited June 7, 2022 by blanger

[Peter W Flint]

These templates are super helpful. Thanks.

 

Curious about how folks set up saved views and use filters/tags in these custom classing systems to draw efficiently...I created a custom system by virtue of having no clue what I was doing (and therefore not coherent enough to share here), but it has now evolved into a hot mess of redundant tags, records, data views, etc. that is slowing down workflows as my projects have grown more complex. I've explored filters and these seem limited in their ability to combine class visibilities, for instance if I want to see irrigation classes but also be able to manipulate objects in site classes, currently I have to switch filters, which grows cumbersome after a while.

 

It looks like more functionality with filters is in the list of feature requests, but in the interim it seems like a combination of filters and tags would help limit the amount of visible data in the nav pane while moving through various phases of design. Just wondering how y'all are managing visibilities with these tools.

 

PWF

[line-weight]

I like to have my classes in a kind of tree structure, just using hyphens in the class name (this allows up to 4 layers of subcategories).

 

So for example here is where I find *materials-timber-ply-structural:

 

 

What certainly gets cumbersome is selecting a class within this tree structure. To get at that particular class, for example, I have to open the dropdown dialogue and unless subcategories happen to be unfurled in the right places from my previous visit, I have to click on 3 of those little arrows. If other subcategories are unfurled I might click on several of those to hide them again to reduce clutter. This is not a good way to do things.

 

I'd much prefer that when you open that drop-down, only the top-level categories were visible, and I could open any of them by hovering over them - and then the same for each level below that. No multiple clicks.

 

Something changed about how this worked, within the last few releases. I can't now remember exactly what it changed from, but I think it was previously better.

 

I don't really use the filters or tags because I don't see how they speed up selection. I don't really want to have to reach for my keyboard all the time to find a class. Apart from anything else it means I have to remember the class already exists and what I called it. If I want to class something as a particular timber type for example, I will go into the tree structure as described above, look what I've got in there already and either choose the best fit or realise I need to create a new class specific to that project.

[Tom W.]

Class filters definitely speed up selection for me. They are right there in the Navigation palette so are where your cursor is anyway + just mean you can get to the particular classes you're concerned with very quickly rather than scrolling through a really long list. So I have 'Wall', 'Roof', 'Slab', 'Proposed', 'Demolished', 'Structural', etc filters. Tags are useful in that they allow you greater control over the classes a filter selects (i.e. rather than just the class name) should you need it.

 

But there is definitely room for improvement:

 

I think I kind of agree with you about the hierarchical display. I use it extensively, often maxing out the number of sub-classes you can have, and it can be difficult on the eye to distinguish between the different groups of classes in a long list. But that's why I like filters because with two clicks I can isolate the list to just the Slab classes for example + not be concerned that I'm confusing one class with another similarly named one nearby (like when you have to sometimes have to scroll up + down to confirm what the parent class is).

[Peter W Flint]

32 minutes ago, line-weight said:

I don't really use the filters or tags because I don't see how they speed up selection.

Yes, I use a similar tree structure to yours and some other examples described. Where I've found filtering useful is in the phases of the modeling process, ie in site modelling I set a filter for each class using a site- prefix and I only have to deal with those classes in the nav pallet or org menu. But that is the extent of its use, and it limits the visibility of classes that may have adjacent relationships, such as planting or irrigation in the case of site modeling. I've had a bit more success with setting up saved views and using the activate class/layer command in the r click context menu, which helps with all the search & click behavior in the relevant menus. Even in a 1 acre residential drawing I can wind up with 150+ classes to manage, so wondering what strategies everyone's coming up to manage working inside the drawing once the organization is set up.

 

PWF

[Peter W Flint]

Just now, Tom W. said:

it can be difficult on the eye to distinguish between the different groups of classes in a long list

It's also taxing on the cognitive load once you're deep in Imagination Land

[Mark Aceto]

2 hours ago, Peter W Flint said:

These templates are super helpful. Thanks.

 

Curious about how folks set up saved views and use filters/tags in these custom classing systems to draw efficiently...I created a custom system by virtue of having no clue what I was doing (and therefore not coherent enough to share here), but it has now evolved into a hot mess of redundant tags, records, data views, etc. that is slowing down workflows as my projects have grown more complex. I've explored filters and these seem limited in their ability to combine class visibilities, for instance if I want to see irrigation classes but also be able to manipulate objects in site classes, currently I have to switch filters, which grows cumbersome after a while.

 

It looks like more functionality with filters is in the list of feature requests, but in the interim it seems like a combination of filters and tags would help limit the amount of visible data in the nav pane while moving through various phases of design. Just wondering how y'all are managing visibilities with these tools.

 

PWF

 

Might be helpful to think of a Saved View as a "Filter View" (that's filtering all manner of criteria; not just classes or layers). The actual view itself could be arbitrary depending what you need.

[Mark Aceto]

Also, custom records are a great way of managing phases: existing, demo, new... 

 

Attributes can be controlled with data vis, and they can also be managed with worksheets (change the phase / attributes of objects from the worksheet).

 

And there are styles too... 

 

I love class and layer filters but tags are "not my tempo."

 

I'm a class minimalist, especially as more and more plug-ins and add-ons (Braceworks, ConnectCAD) are generating their own classes, so less is more. All of the recent Data* advancements have helped me eliminate a lot of the incessant clicking, fiddling, class overrides, etc.

 

On that note, turning off Hierarchical display is one of the first things I do with each VW install. Talk about incessant clicking... 

 

I'm about to build a new template file based on the ConnectCAD template, so I'll be following this thread closely.

[Tom W.]

23 minutes ago, Mark Aceto said:

I'm a class minimalist, especially as more and more plug-ins and add-ons (Braceworks, ConnectCAD) are generating their own classes, so less is more. All of the recent Data* advancements have helped me eliminate a lot of the incessant clicking, fiddling, class overrides, etc.

 

Are you controlling visibility of objects using Data Viz? (by setting all attributes to None)

[Mark Aceto]

33 minutes ago, Tom W. said:

Are you controlling visibility of objects using Data Viz? (by setting all attributes to None)

 

In a nutshell, I'm saying that I use Data Vis to control attributes of objects that use records (for example: existing, new, truss length, truss color, even line weight of all objects in a viewport) vs using class attributes or class overrides. I mean I still use class attributes but have prob replaced 20% of what I was doing up until 2020 with a data-driven workflow.

 

To make an analogy, before I used conditional formatting in Excel, I would manually change the color of cell fills, borders, fonts... 

 

But to keep it on topic, my point is that there's a law of diminishing returns with any of these workflows. Where the classing rules start to fall apart, another workflow might take the frustration out of the classing workflow (for that last 20% of head-scratching).

[zoomer]

With too many Classes I also always thought I need some hierarchy.

But left Class hierarchical display again as soon as it arrived.

 

Because it is just so much more tedious to target the arrows to expand

these hierarchies for Class access than it is to scroll through the list.

 

Also did the "-" separator did not fit my upper case Naming with "_" if

needed - Which I find much more legible. In general and it makes still

the full Class List Scrolling more legible.

 

The only advantage I could see for the Hierarchy option, in it is current state,

is when you have really large amounts of Classes like 300+,

because VW does not really intelligently remember the last Class scrolling

Position when you do the same task over and over again.

VW arbitrarily opens the new Class chooser at any strange position and you

always have to read in again to find the scroll direction way up or down

to your current interesting Class "group".

(Say you need to rename 5-7 of your Material_Wood Classes or choose

3 of them to create a RW "Texture" (Material !)