Class Types

[Kizza]

We need to be able to group classes by type.

And we need to be able to control the visibility of the class types.

And the visibilities of classes and class types needs to be saveable so they can be applied and reused.

Fiddling endlessly with classes is tiresome.... there must be a better way.

maybe on creation of the class you can assign a "Type" to it, such as, Landscape, Annotations, Furniture, Structure etc.

Edited June 24, 2014 by Kizza

[PVA - Admin]

Is the key here the ability to control the visibility of multiple classes as one?

For instance, you would be able to select a number of classes in the navigation palette or organization dialogue, then right click > "Link Visibility" Or "Group Classes", then any time you selected one of those classes, you would see a UI element showing what classes it was linked to/grouped with, maybe an option for right click > Selected linked/grouped classes to make changing all of their visibilities at once easier?

Maybe two levels of this, one just for organization as described above, but a second grouping level where changing the visibility of one of the classes in the group immediately forced the change of the other classes in the group to that same visibility?

[VincentCuclair]

I think the thought behind this is strongly related to Standard Naming and Auto-classing. I have 250+ classes ie a lot to be scrolling through each and everytime i need to choose or view them (even with the new hierarchy setup it's still a long list in alfabetical order nothing more.....).

An example: When I create a wall i only want to see relevant classes, in my case not more than 20-30 eg a standard or autoclass + 19-29 relevant classes to choose from if the autoclass is not what i want.

In Revit EVERYTHING is automatically classed in a hierarchy down to the smallest element this is the extreme opposite to what we have and personally not to my taste however a usable but flexibly intelligent middle way would be nice.

Sections to be taken into consideration if a good system is to be developed is the interaction/integration of:

1: different building areas eg structural, architectural, landscape, etc

2: 2D vs 3D (vs Hybrid)

3: Phases (in the future)

4: IFC

5: Drafting vs modelling/visualization

Edited June 25, 2014 by Vincent C

[Kizza]

Is the key here the ability to control the visibility of multiple classes as one?

Yes, and to increase my productivity by not having to scroll through and manipulate lists of classes.

I think Grouping of Classes should be a distinct feature (i.e. not linked but grouped) although you could perhaps include the ability to right click a class and add to group.

One of the possibilities the grouping of classes will achieve:

You can assign classes to a group - Existing, Proposed, Demolished etc and turn them on or off at will.

And of course, to be able to assign a view and a class group to a Design Layer would be a big thumbs up in my book.

Class Group and View assignable to Design Layer

Edited June 25, 2014 by Kizza

[Kizza]

I think the thought behind this is strongly related to Standard Naming and Auto-classing.

You've hit the nail on the head Vincent, I'm sure Archicad handles it similarly as well.

For group classing to work, autoclassing of ALL objects (including all annotation objects!) within VW must be achievable.

I tinkered again with standard naming and autoclassing the other day. I made limited progress. They appear to be half-baked.

[Benson Shaw]

I don't see Revit much, but I am usually appalled by the classing in dwg files. Seems that the word "and" get's it's own class, along with all the other words and boxes and lines. Vectorworks' double sorting system (layers & classes) with all the visibility controls is great. If a super detailed auto class system is advantageous, go for it. But I really do not want to have auto classing in such detail as those dwgs that port into my projects.

Be sure to keep the option to make my own system and avoid the auto classes.

-B

[Kizza]

My wish in this thread is for class types or "sets"

But implementing class types in VW requires that all objects be automatically assignable to a class. Some objects in VW cannot presently be automatically assigned to a class e.g. drawing labels and viewports. Why not?

Hence, the two go hand in hand, class types and complete autoclassing.

My proposed implementation allows you to have as many or few (or none) class types as you desire. I could have all my door classes in a door class type and all my windows in a window class type. I can turn all these classes on/off with two clicks instead of 20.

Add to this the capacity to save class visibilities to class types and apply them to design layers, viewports etc and you really start to leverage the power of layers and classes in VW.

Revit is not the only program that handles objects in this way. I believe Archicad does as well.

And BTW, if autoclassing of all VW objects was user controllable, your class list can be as broad or compact as you wish...

P.S. I spent two years on Autocad - I think it's scarred me..

[AndiACD]

While i agree that managing, organising Classes is a problem, still, for far too long, please remember that there are 4 or 5 versions of VW, so any "Improvements" must be adaptable to the other iterations, practical and customisable.

Having said that, probably anything would be a step in the right direction . . . . . .

[grant_PD]

Pardon my ignorance, but isn't this accomplished by nesting classes? I don't nest classes that often, but I thought that was the point...you put all of your doors in a door subset, and then you can turn off the root at will? Am I wrong about that?

I completely agree with you that the problem with vw classes is that you can't set defaults for everything, it's half baked. I see absolutely no reason why a viewport should be in anything other than a viewport class. And it is because of that discrepancy that I believe many people turn away from classes altogether. One lost afternoon trying to find the thing that you inadvertently miss classed will do that to you.

[VincentCuclair]

...you put all of your doors in a door subset, and then you can turn off the root at will?

Sure, it's a step in the right direction but in essence all you're doing is making the (alphabetical) list a little shorter to view and turning them on and off) we want a far higher level of 'organization and integration' i.e. grouping, applying, saving, editing, overriding etc. etc. at the moment you create an object and apply a class from a huge list of classes in alphabetical order......nothing more nothing less.

[Kevin McAllister]

Pardon my ignorance, but isn't this accomplished by nesting classes? I don't nest classes that often, but I thought that was the point...you put all of your doors in a door subset, and then you can turn off the root at will? Am I wrong about that?

I thought that too but its not true. If you change the visibility of the top "container" class of a nest it physically changes the visibility state of all of the objects under it instead of turning the group on and off while maintaining their individual states. I'd like to see this fixed.

I'd also like an option to have nested items inherit the characteristics of its parent. That way you could set the line type and line weight of an entire group and customize one or two classes in the group.

Kevin

[Benson Shaw]

Yes, please, groups/sets and ability to work with them globally.

It is kind of surprising that the parent of nested classes does not operate as the entry point for overall edits of the offspring.

Some things can be edited as a group eg visibility of a selection of classes can be changed via the organization palette. But current workflow requires selection of the sub classes in the Org palette, rather than selection of the parent. Maybe that's another wish.

Other functions require class by class edits, eg editing the names of the offspring cannot be accomplished by selecting the parent in the class list. Or duplicating the parent (and all the offspring) to create similar group with a new parent name.

Turn up the heat on class functionality.

-B

[Kizza]

What about this?

Class Group/Set = A selection of classes grouped together. They can be turned on, off and greyed as a group.

Layer Group/Set = A selection of layers grouped together. They can be turned on, off and greyed as a group.

Visibility template = A saveable, user defineable collection of visibility settings of individual classes, layers, and class and layer groups that can be applied and attached to a design layer. A visibility template should also be able to set the view and render style.

A user could:

- Use classes and layers as they are now (no change to present workflow)

- They could use class and layer grouping to control groups of classes and layers

- They could use the visibility template for complete control of classes and layers.

[VincentCuclair]

At the very least make it visually easier for us when working with our classes, I would like to have the option to assign a (custom) color to my class names. This way it will be easier for me to find important classes and groups of classes when navigating the list. You know this could potentially remove the need for the hyphens in the class names if we could sort and group by color.

The same goes for layers.

Edited July 9, 2014 by Vincent C

[Kevin McAllister]

I like this idea....

KM

[PVA - Admin]

I see at least 4 separate, solid wishlist items in this thread. I will come back to this and submit them all ASAP.

[Tim Harland]

+1 to the visibility templates, they should also be able to be applied to SLVP's. This would make creating and managing office standards much easier. ArchiCAD manages classes in this way. You can used saved views to approximate this currently for design layers.

[Kizza]

+1 to the visibility templates, they should also be able to be applied to SLVP's.

Maybe to allow those that are used to the existing class management scheme to continue in their workflow.

But my opinion is that if a class visibility template is applied to the design layer then there would be less need to tweak classes in the SLVP.

After all, the goal is total WYSIWYG in the design layer...

[Tom Klaber]

Saved views do a lot of this, but +1 on the class binding. That would be really useful for demo, construction, RCP, finish, presentation, etcetera. The issue I see is that you are going to find quickly that you want certain classes to be in more than one group.