Rob Books

Design Summit 2017 - Classing panel - Format Styles discussion

41 posts in this topic

21 minutes ago, Rob Books said:

 

The symbols would still insert by class, I am looking at changing up the 3D geometry to match our other content and be on the None Class.  and this would only be the 3D geometry, and probably only the Lighting instruments and Audio Speakers.  I think Truss should stay on the Rigging-Truss-Truss class.

 

Going back to our DS discussion...

 

You're addressing Classing on 2 levels:  "macro" and "micro."  Inserting by-Class is "macro."  Parts' Classing is "micro."  Symbols and PIOs (using your examples of Lighting Instruments and Truss) should NOT, by-default, insert by-Class (macro).  Suggesting /optional "parts"-level/"micro" Classing is very appropriate, though - with a very intentional emphasis on "suggesting."

 

As to "Rigging-Truss-Truss," no...not a good place for truss to stay as truss is not rigging...

1

Share this post


Link to post
Share on other sites

As Andy Dunning sys, Truss isn't always rigging.

 

As. a user/designer, I want control over Classing, and I especially want control over the appearance of the 3D Geometry.

 

For example, in my template file, I have set all of the classing preferences in the settings dialog of the "Door Tool (for example' so when I insert a door, it looks, by default how I expect to want it to look.  This generally means all black all around. I'm typically going to use the architectural toolset create a venue. If I want a special door (in a ballroom for example), I modify the initial insertion and see it as a symbol. Thus I control it's appearance.

 

I need to be able to do the same with SLDs.

 

I generally want any SLD to insert in my own' LX-SLD' class.  Similarly, I want any Vectorworks Light Object to insert in my 'LX-VLO' class.

 

I want control over 2D and 3D appearance by class. If I modify a stock symbol, when the library updates, I lose that work. Just as I recently lost the work using the PIO Manager to assign objects to specific classes, those preferences do not survive any update to the application.

 

For me, I don't care to class by light source. The rental shop may need that. In my opinion, it would be up to the shop to take the plot, and find/modify to make those changes.

 

I am concerned with he appearance of the document in both a 2D drafting and in renderings. 

 

1

Share this post


Link to post
Share on other sites
On 9/27/2017 at 8:07 PM, Rob Books said:

 

Just to ensure that I have your request correct for this:

1) If the parent name is changed, then that part of the Child name will also be Changed.  Ex: change from "Cable" to "06 Cable" would cause all Children to now be "06 Cable-"

2) Class attributes to include a "Use Parent" setting so that all settings could start at the Parent settings or be changed to them on a case by case basis.

3) if you create a Child Class, a default Parent class would be created. Ex: Create "Cable-Data" would also cause "Cable" to be created with default settings.

A few comments, this is almost what I have been asking for, but with some slight modifications.

Regarding point 1: This should also apply to a sub-class that is a parent to a sub-sub-class without having to change the parent class.

E.g. have a set of boxes at the top of the classes panel, one box for each level and when you select a set of classes then typing the new class or sub-class name in one of the boxes would replace the name of that level. i.e. First box would be parent, second box would be sub-class and third box would be sub-sub-class etc. That way you could rename one or more levels of classes across a whole series or parent-subclass combinations in one go. (i.e. when a sub-class name is used across different parent classes, see example at the bottom)

 

Regarding point 2: it might be better to have an option to either use the parent class settings or to use the settings of the active/selected class when creating a new (sub)class. e.g. in AutoCAD creating a new layer will use the settings of the active layer. This way you can set up another class with the same settings more easily.
 

Regarding item 3: Is that not already the case?

 

The name changes should apply to all selected classes instead of just the topmost of the selected list.

 

It would also be nice if I could duplicate a class with all it's subclasses in one go and to have a dialog asking to set a new parent name for the duplicates. Or use the boxes suggestion for renaming that I mentioned above while the duplicated classes are still selected.

Sometimes things are constructed in multiple phases and I need the same set up subclasses for each phase with perhaps a different fill colour to differentiate the phases.

Then it would nice if I only would have to create a phase 1 set of parent- and sub-classes, copy the whole set and then get a dialog asking to change the parent class name (e.g. from phase1- to phase2-) and presto there is the complete set for phase 2.

Edited by Art V
0

Share this post


Link to post
Share on other sites

To add a degree of difficulty here, what if I create/admin a project sharing file. If I share with the shop or the venue, they may want to use their own classing system, it should then be possible to decide what changes they make are committed to the project file.

 

Same is true of instrumentation. Shop may suggest a substitute. Different shops may suggest different subs, the admin ought to be able to choose which changes to commmit.

0

Share this post


Link to post
Share on other sites
2 hours ago, C. Andrew Dunning said:

 

Going back to our DS discussion...

 

You're addressing Classing on 2 levels:  "macro" and "micro."  Inserting by-Class is "macro."  Parts' Classing is "micro."  Symbols and PIOs (using your examples of Lighting Instruments and Truss) should NOT, by-default, insert by-Class (macro).  Suggesting /optional "parts"-level/"micro" Classing is very appropriate, though - with a very intentional emphasis on "suggesting."

 

As to "Rigging-Truss-Truss," no...not a good place for truss to stay as truss is not rigging...

 

The Insert By class can be overwritten thanks to tools we put in place for spotlight users, so even though I set the symbol up to insert in the Lighting-LED, say; you can override that and have it placed in the active class that you want.

 

1 hour ago, Kevin Allen said:

I generally want any SLD to insert in my own' LX-SLD' class.  Similarly, I want any Vectorworks Light Object to insert in my 'LX-VLO' class.

 

I want control over 2D and 3D appearance by class. If I modify a stock symbol, when the library updates, I lose that work. Just as I recently lost the work using the PIO Manager to assign objects to specific classes, those preferences do not survive any update to the application.

 

For me, I don't care to class by light source. The rental shop may need that. In my opinion, it would be up to the shop to take the plot, and find/modify to make those changes.

 

I am concerned with he appearance of the document in both a 2D drafting and in renderings. 

 

 

By having the 3D in the None class, and only special classes used in the 2D (Lighting-Types, Movement Radius)  you could place in any class you wanted rather than now where no matter what class you place it in, the geometry is classed to our classing and you would need to control both to get the appearance you want.

0

Share this post


Link to post
Share on other sites
1 hour ago, Art V said:

 

Regarding item 3: Is that not already the case?

Nope.  if I create a class Truss-Webbing, then only that class is created.  no Parent class "Truss" is created.  In the tree view, it might look like there is a class Truss, but there is not.  

0

Share this post


Link to post
Share on other sites
1 hour ago, Kevin Allen said:

Rob, my point is that I want full control, and I want that control to survive updates. 

 

That is what we were discussing about back in the beginning with the Class Management tool that would run and merge/rename classes every time you imported from a known set.  can kinda do that with the current tool, just have to manually run it each time you import something.  it would be better if it was running in the background and did it automatically when something is brought in to the document.

0

Share this post


Link to post
Share on other sites
2 hours ago, Rob Books said:

 

That is what we were discussing about back in the beginning with the Class Management tool that would run and merge/rename classes every time you imported from a known set.  can kinda do that with the current tool, just have to manually run it each time you import something.  it would be better if it was running in the background and did it automatically when something is brought in to the document.

While this would be nice, I'd also like to have the flexibility of manually renaming parents and subclasses on a per level basis or through search/replace (preferably both) as I often have to bring in drawings from various sources with different layer setups (dwg/dgn files)  (and sometimes classes/layers in case it is a VWX file) . Sometimes the layer names are the same but the content type could be different so I would have to assign it to different classes than the previous drawing.

 

So while I do see the benefit of automatic renaming for known sets that get reimported over time, a fully manual option to rename multiple classes at once remains a necessity imho. Also because existing (sub-)class setups may get reworked during a project due to changes of plans, other requirements etc.  When there are only a few subclasses it is not a big deal, but if there are  2-3 dozen (or more) subclasses for several parent classes then it becomes a nightmare at the moment.

0

Share this post


Link to post
Share on other sites
4 hours ago, Rob Books said:

Nope.  if I create a class Truss-Webbing, then only that class is created.  no Parent class "Truss" is created.  In the tree view, it might look like there is a class Truss, but there is not.  

Yes, that is correct, but once you add another class it becomes a parent though this "parent" part of the class name is not a class by itself.
So if I understand you correctly based on your reply, you are considering to make that  a class with attribute properties that also interacts with the parent-subclass system where the parent is the same as the class, so then it would be something like..?

 

Truss

Truss-Webbing

Truss-Whatever

 

A change to Truss would also affect Truss-Webbinb etc.?  E.g. rename Truss to XYZ and the other two would become XYZ-Webbing and XYZ-Whatever?

 

0

Share this post


Link to post
Share on other sites
8 hours ago, Rob Books said:

The Insert By class can be overwritten thanks to tools we put in place for spotlight users, so even though I set the symbol up to insert in the Lighting-LED, say; you can override that and have it placed in the active class that you want.

 

Yes...but...

- Placing a Source 4 still drags in "Lighting-Architectural" and "Lighting-Incandescent."

- Placing a PAR 2 still drags in "Lighting-LED," "Lighting-Input-2D," "Lighting-Input-3D," and "Lighting-LED."

 

I can see the point of the "...Input..." Classes (as they are parts) but, the setting seems to be only partially implemented as the "macro" Classes are still dragged in...especially, when the Source 4 drags in 2 that seem (to me) to be in-conflict.

 

8 hours ago, Rob Books said:

By having the 3D in the None class, and only special classes used in the 2D (Lighting-Types, Movement Radius)  you could place in any class you wanted rather than now where no matter what class you place it in, the geometry is classed to our classing and you would need to control both to get the appearance you want.

 

But...by partially implementing a Classing scheme - with no flexibility regarding options, power users (like KLA) get frustrated because they need Class-level attribute control both both 2D AND 3D.  Frustration that is amplified by inconsistent implementation.

 

Which takes us back to the real need for Class mapping functionality as part of the Resource import process...

 

2

Share this post


Link to post
Share on other sites
13 hours ago, Rob Books said:

I think Truss should stay on the Rigging-Truss-Truss class.

 

Dear Rob,

Slightly off topic sorry, but while we're at it it is a real drag when placing a hoist into a drawing that you get a load of unwanted classes. This goes against all other Spotlight PIO's where the user can choose to add classes and/or have them automatically fill with standard classes which is great. Please can there be an option so it behaves like all the other PIO's in this regard?

 

Thanks,

Peter

Hoist classes go away.jpg

0

Share this post


Link to post
Share on other sites

ooohhh ooohhh, pick me Mr. Kotter.

Peter's image reminds me of a question. Why is it that the Hoist Colors are removed from the rest of the hoist classes? And, how do I get the colors to come in under "Rigging-Hoist-Color-Unspecified"?

Drives me nuts to have to scroll past everything between H & R to travel between Hoist Color and the stuff listed under Rigging.

0

Share this post


Link to post
Share on other sites
18 hours ago, Peter Neufeld said:

 

Dear Rob,

Slightly off topic sorry, but while we're at it it is a real drag when placing a hoist into a drawing that you get a load of unwanted classes. This goes against all other Spotlight PIO's where the user can choose to add classes and/or have them automatically fill with standard classes which is great. Please can there be an option so it behaves like all the other PIO's in this regard?

 

Thanks,

Peter

Hoist classes go away.jpg

 

That is a Good Question.  Just checked with Kevin, and it looks like the 2D has that class in it.  Please put in a bug on it, assign to me.  we will fix.

Edited by Rob Books
0

Share this post


Link to post
Share on other sites
12 hours ago, C. Andrew Dunning said:

 

Yes...but...

- Placing a Source 4 still drags in "Lighting-Architectural" and "Lighting-Incandescent."

- Placing a PAR 2 still drags in "Lighting-LED," "Lighting-Input-2D," "Lighting-Input-3D," and "Lighting-LED."

 

I can see the point of the "...Input..." Classes (as they are parts) but, the setting seems to be only partially implemented as the "macro" Classes are still dragged in...especially, when the Source 4 drags in 2 that seem (to me) to be in-conflict.

 

 

But...by partially implementing a Classing scheme - with no flexibility regarding options, power users (like KLA) get frustrated because they need Class-level attribute control both both 2D AND 3D.  Frustration that is amplified by inconsistent implementation.

 

Which takes us back to the real need for Class mapping functionality as part of the Resource import process...

 

 

This was just a thought, I am perfectly happy to not have to touch the 3000+ symbols yet again.  I will gladly leave them as is for now.

 

and Yes, we need a more robust mapping function like the German or Australian tools.

 

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now