Jump to content
James McConkey

Lighting subclasses

Recommended Posts

Posted (edited)

Hello,

 

I am having trouble finding the answer to this one. 

Lighting instruments are in a designated class but also in the lighting class with a subclass (e.g. lighting-incandescent). Where are these subclasses configurable? 

I deleted one of these subclasses putting them on the none class and now the none class needs to be visible.  I cannot find a way to put it back or adjust it.

Any help?

 

Thank you. 

Edited by James McConkey

Share this post


Link to post

Lighting instruments, like many other symbols, included embedded classes for control purposes. The easiest way to wrap one’s head around this is to drop in a lighting symbol in a blank document. You will see the specific classes created. The symbol itself can be placed on a class of your choosing. To view it, your custom class must be visible, however, some or all elements of the embedded classes must also be visible. By using this method, you can decide if you want to see the movement radius, the “whip” location, etc. it’s actually pretty useful but I would add that the existing class scheme is dated and a bit of a mess. It’s the kind of thing that starts out as a simple idea and then gets added to, and mucked about with over time so it is what it is. It would take quite a lot for the VW team to change it at this point. 
 

One solution would be to create a library file of every fixture you might ever intend to use and, once all the symbols are imported, you can change the embedded class names. I believe there may be some class mapping options now available for this purpose, but if they exist, I’ve not used them. 

  • Like 1

Share this post


Link to post

Class Mapping should be available in Spotlight,  you can use it to map classes in an existing file to new classes, but it will not change classes if you add symbols with those classes in.  

as to your deleted class issue, you can re-import the symbol in and then refresh instruments should fix it for you easily.

  • Like 1

Share this post


Link to post
Posted (edited)

@James McConkey Rob answered the question of how to restore the class but to echo what Scott is addressing (pardon the pun), those subclasses are generated in the same way that adding a door or window will auto-generate the Ceiling-Main class. Same with furniture and a bunch of other symbols in what is affectionately known as turning on the "class parade". While device/instrument type is useful in Lightwright paperwork, I don't know any designers or electricians that organize their classes that way (vs the myriad other ways). Those sub-classes are artifacts that are about as useful as the vestigial arms on a T Rex, so most people just nuke 'em. Add to that the west coast vs east coast vs film nomenclature, and you've either got an incandescent or a conventional or a practical fixture... but a Mac is always a Martin, so purge away!

 

Edited by Mark Aceto
  • Like 1

Share this post


Link to post

I've taken to building a library of purged symbols that don't have any of those nested classes.  Also with textures and such applied for rendering (ie. the lens is not clear, it's luminant etc).  But I'm a scenic designer so I don't need anything more than the correct body to put in renders and drafting.  

  • Like 1

Share this post


Link to post

Thank you all for your input, I have learned a lot and appreciate the time. I imported the symbols again and was able to fix all but one issue.

The slash symbols designating the degree on the front of the Source 4 26deg or 36deg always seems to be on the "None" layer. I have tried importing the instruments again many times and even replaced with another ETC instrument that I have never used with the same results, even with a refresh. 

This leaves me with having to have 3 different classes visible to render things properly(My class "FOH lights", the hidden class of "lighting-incandescent" and "None").

Classes have often frustrated me. Using the lighting pipe tool to create a batten, then converting to a hanging positions also has the 6 different "hidden" classes (Pipe, tick mark...) but at least I can see and change those. 

  • Like 1

Share this post


Link to post
Posted (edited)
On 5/20/2020 at 1:10 PM, James McConkey said:

This leaves me with having to have 3 different classes visible to render things properly(My class "FOH lights", the hidden class of "lighting-incandescent" and "None").

 

 

Delete each class that you don't want. A dialog window will pop up asking if you'd like to delete the class entirely or move those objects to another class. Select the lighting class you'd like to move them to. I guess we all left out that step but we were all thinking it. That's how you thin the herd (of the class parade). Just to reiterate, there's no advantage to, or best practice of, keeping those autogenerated classes around unless you're an architect.

Edited by Mark Aceto

Share this post


Link to post

I did stumble across a function I never knew existed yesterday : "custom modification."  Which allows you to do a custom selection and then change the attributes of your selected items.  I haven't tried it, but it could be the answer.  You could, in theory, do a custom selection of all lighting instruments, and them modify their class, which hopefully would change all of the nested classes as well.  Which is James' issue: he has objects in his 'FOH lights' class which also have objects in the 'None' class.  Doing a purge as Mark suggests (which I do as well), won't help in that instance.  

  • Like 1

Share this post


Link to post

Those embedded classes do serve very necessary purposes even though my opinion is some of the lighting symbol classes are just not necessary. A good way to wrap your brain around the purposes of embedded classes would be installing a BraceWorks truss. The embedded classes allow the end user to choose between simple and complex truss options and other items. Again, the class naming is a little odd (having a class that uses the word “truss” then a hyphen and then “truss” is kind of like including the word being defined in it’s own definition). 
 

The separate class for a lens would be ideal so that not only could you use a lens with a glow texture, but it could also change color appropriately  simply changing the “color” field in the OIP or edit fixture window. 
 

My personal opinion is that embedded classes should ONLY be used to control the attributes of a symbol selection; what parts are visible, co trolling line weights, pen color, fills, etc. This functionality is spectacular.  It should never have been used as a way to categorize symbols. That is the designer or drafter’s job. Again, in my opinion, the “wash”, “incandescent”, “moving light” etc. classes are completely superfluous and serve no viable purpose, especially now that your profile lights and wash lights might very well utilize LED engines. 
 

rant over. 

  • Like 1

Share this post


Link to post
Posted (edited)
3 hours ago, scottmoore said:

Again, in my opinion, the “wash”, “incandescent”, “moving light” etc. classes are completely superfluous and serve no viable purpose, especially now that your profile lights and wash lights might very well utilize LED engines. 

 

That is specifically what I was referring to because of this issue:

 

21 hours ago, James McConkey said:

This leaves me with having to have 3 different classes visible to render things properly(My class "FOH lights", the hidden class of "lighting-incandescent" and "None").

 

For clarification, never mess with Bracewurst classes.

 

If we want to take the conversation of best practices a step further, I would suggest creating a blank template file, and adding your own classes. This would:

  • Eliminate the classes created by PRG ATL that may be superfluous ("event" seems to mean "site")
  • When importing symbols that add their own embedded classes, you can make a more intelligent choice about whether to keep them or not:
    • Delete the superfluous lighting, ceiling, furniture classes
    • Keep every class that a truss, hoist, rigging symbol auto-generates

Creating your own template file, classes, libraries (of your own favorite custom/edited symbols)... will also help to create Saved Views in that template file. All of those things combined will reduce the incessant clicking, hunting, and pecking required to get the job done.

 

Note: using the Tools > Purge command will allow you delete objects and classes that you definitely want to keep. Chief among them, anything related to rigging—particularly vulnerable are 2D and 3D horz and vert truss objects, hoist parts and classes... Honestly, it's a bug that should be reported to VW engineering.

 

Edited by Mark Aceto

Share this post


Link to post

AMEN MARK!  

 

Your comment on Saved Views is spot on as well.  Arguably the most overlooked powerful asset of VWX.   

 

One other suggestion for those struggling with the class parade:  If you want to keep the existing VWX embedded classes and still create a template file (you should absolutely create a template file), add some class tags to the autogenerated classes and your specific drawing classes (flown, floor, house, booms, whatever you might call your classes) then add a class filter to select that particular tag.  When you select that filter, all you will see in your nav palette are the classes specifically associated with your lighting fixtures.  

 

For me, I've always used my own custom symbols and have a template set-up to accommodate them.  On occasion I have to share my file with other designers and then comes the class parade and none of my saved views, sheet layer viewports, etc. work correctly.  My solution in my updated template was to include all the lighting and BraceWorks classes in my template as well and include all of that information in my saved views and sheet layer viewports.  When I run my LX filter, it brings up all of the associated lighting classes, including my drawing classes, my custom embedded classes and the Spotlight classes.  Now I don't have to be quite as frustrated as I was as it doesn't matter if I amusing my symbols or someone else's inserted symbols from the VWX libraries.  The drawing still works the same.   

  • Like 1

Share this post


Link to post

By the way, I would imagine the reason to have the "types of lights" embedded classes would have been more about adding color coding to those types of lights probably based on the preference of a certain shop.  The real issue with the embedded classes was not having a strict naming convention in place prior to development.  A simple number or letter could have solved a lot of the mess.   

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...