Creating Multiple Configurations for a Theaters Inventory

[SineDining]

Hey Everyone,

 

I have built a 3D model of the theater I work at. I am trying to create a file where I can extract some paperwork for advancing shows with the production manager of touring acts. I also want to pass on my VW file to touring set designers and lighting directors. 

 

First, I would like to make multiple viewports that show different configurations we commonly use our inventory in. For instance, I would like to show our comedy look, where we drop the half black, tie the soft legs in a certain position, and deploy our ground lighting package. Then I would like to show our "rock and roll" configuration, where we drop the 3/4 black and tie the soft goods farther back, and our lighting pipes on stage hang at certain heights. I'd also like to show the configuration we use for plays, where we deploy our upright booms between the soft legs.... so on and so forth. 

 

However, not only do I want to create different view ports, I want touring acts to be able to open the VW file and easily switch between these configurations. As if they could open up the file and choose "Rock and Roll" or "Theater Play" and our existing inventory will snap into place. 

 

I have thought about doing this by just creating new layers or classes that have the different configurations of the soft goods, lighting positions, and scenic elements. But 1. I would like to keep my layers/classes to a minimum so it doesn't get complicated and 2. When creating reports I'm thinking its going to count my theater's inventory 3 or 4 different time or however many configurations I set up. But, without doing the different layers or classes, I can't think of a way to make my viewports work.

 

I was thinking maybe I could create, or someone has already created, a macro that can change the positions, ect of the inventory? But again even if I had a way to press a button and change the deployment of my inventory, how could I create multiple viewports that showed the different configurations if I don't have them assigned to different layers of classes that I can turn on or off. 

 

I would love to hear how others might have accomplished something similar to any or all of the above. Any advice is much appreciated.

 

Thanks

 

[Jesse Cogswell]

I think having different layers would be the ticket.  I don't think you would need multiples of the classes, after all a lighting fixture is a lighting fixture.  The way I typically think of layers vs classes is that layers are used for organization, classes are used for visual attributes like color and lineweight.  Unless you wanted to be able to show the configurations in the same viewport in different colors, you should be able to have one set of classes (you could probably even do the multiple colors with data visualization anyway).

 

One way to simplify everything would be to add tags to your layers so that they are easy to filter and then set up saved views to toggle the layers on and off so that you can change the configuration with a couple of clicks.  In terms of reports, you can set the criteria to count things on specific layers, so it wouldn't necessarily be counting your inventory multiple times, though syncing with Lightwright would be tricky.  You could try using the System drop-down in the OIP to make a way to easily sort the different systems out using Lightwright Limits.

 

You could theoretically write a macro to physically move all of the assets around to each configuration, but it would be pretty intense as each object would need a command to place it in XYZ space and set its orientation, let alone attaching the fixtures to hanging positions.  On top of that, it would lock you pretty hard in terms of flexibility within that system, as those values would have to be hard-coded in with the object names/UUID.

 

You could make up a worksheet for each configuration which would list the UUID, X, Y, Z, and Rotation of each object and have a script run through the worksheet and move the object to the given spot and set rotation, but if I were in your shoes, I would do it with a set of layers, layer tags, and saved views.

[TomWhiteLight]

Jesse is correct, The other solution is to reference the layers and get the client to delete the ones they don't want.

[SineDining]

Thanks, Jesse. Thanks Tom.

 

I like the idea of having different saved views. Data tags keeps coming across the table everywhere I have been researching for a solution but I haven't implemented them yet. 

 

Reference layers is a neat idea because I could delete the referenced layer that doesn't apply before I send the file, keeping the overall file size efficient. I would think this would also help simplify things with lightwright integration?

 

Originally, the idea of a script or a macro came to mind for me so that I could just have a click and play option to bring certain soft goods in and out without having to go to top/plan, click on the lighting pipe and then manually enter the values. Something where I could say, 2 legs in, half black in, screen out, ect. I would still like to explore something like that. Those values are binary for the most part (z of 60' or z of 28'). 

 

I suppose, however, if I am going to create layers for each configuration, then the convenience of having a script to move the soft goods in and out is negligible. 

 

Ya'll have given me a lot to think about. Thank you for your time and consideration!

[Jesse Cogswell]

To clarify, Data Tags and the Layer Tags I was referring to are two entirely different concepts.  Data Tags have been pushed really hard in the last two releases and are mostly annotation objects like drawing labels and such.  Layer Tags were introduced in VW2019 (or was it VW2018?) and is a way to simplify the Class and Layer drop down menus so that they don't show every possible layer.

 

To get to these, open up the Organization window, right click a layer/class and select "Assign Tags."  This leads to an awkward (but still very functional) dialog box allowing you to specify tags for the layer/class.  I'm not sure how many tags you can have assigned to a layer or class, but it's at least more than four.  Once that's done, in the Organization window, click on the "Manage Filters" button in the upper right to construct filters based on those tags.  Once the filter is made, it can be accessed from the bottom of any of the drop-down menus in the main program bar at the top of the screen and the Object Info Palette.  The Navigation palette and Organization window have a separate drop-down to select filters.

 

So in your situation, you might build tags for "Comedy", "Rock and Roll", and "Theatre" and build filters around them so that you can limit the layers shown in dialogs.  I do this when I set up theater drawings so that designers can toggle off the layers that they don't want without deleting them.  I worked on a show last year where the scenic designer deleted all of the lighting layers from the drawing, but the lighting designer started his plot directly off of the scenic plates rather than the venue file, so he had to guess where all of the lighting positions were.  It's much better if the scenic designer could cue up a saved view to turn off the lighting layers and then filter them out so that they don't have to think about them.

 

There are two quick caveats with this.  At the moment, these filters are not able to be integrated in to Saved Views.  So you if you recall a Saved View (like "Comedy"), the filters would still have to be applied separately to each of the locations that Layer can be found (top view drop-downs, Object Info Palette, Organization Window, Navigation Palette).  There also aren't any script commands that I am aware of that can set active filters.  The other caveat is that you can't have a filter looks for two separate tags (as in "Comedy" and "Theater Architecture").  What that means is that any of your common layers, such as Theater Architecture, would have to have all of the other tags applied to it so that any of the filters will keep them visible.

 

In terms of the referenced views, that is an interesting solution.  Lightwright can't pull data through a Referenced Viewport, but if you delete the reference from the References tab of the Organization window, you do have the option of importing the assets into the drawing.  I just don't know if it will respect the layer organization or if it would just dump all of the assets on the layer that the viewport was originally on, so it might take some additional clean up.

[TomWhiteLight]

Just to clarify it is a referenced layer not a view, and providing the reference is cached Lightwright will treat them as if they are actually in the file (I think but untested).

 

Tagging the referenced layers is a great idea and will help with filters. In terms of relabelling your organisation Don't forget to use Tools - Batch Rename to do this don't do it individually!

 

Interestingly maybe Data visualisation could help with this? Not sure how but you might find it interesting that data visualisations can be saved within a saved view. This could be worth exploring! In my past life as head of lighting at a Repertory Opera Festival we would have used data visualisation to show us what light is used in which of the Opera's

 

All the best

 

Tom W

[Jesse Cogswell]

Aha!  I didn't even think about importing the layer in as a referenced layer.  That would indeed do the trick and keep the Lightwright nice and happy.  You could even delete the desired reference but leave "Keep in Current Document" selected to remove the "Lock" and allow editing.  This is probably a good way to achieve this.

 

@SineDining What's important to note about this approach is that it uses methods that are considered "out of date" in terms of how Vectorworks operates.  I think you would still need to have the layers uniquely named for this to work properly (at least to be able to toggle views prior to deleting the references), but the workflow is slightly different to how you might be used to working.  In this case, you would set up the references in the Organization window after clicking on the Settings button and selecting "Layer Import" instead of "Design Layer Viewports."  Once the references are built, you could select the layers that you want by clicking on the references and clicking "Edit" and selecting the layers you want to import.

 

What's important to know about this, is that it appears that the reference method is set for the entire drawing, so if you want to also use Design Layer Viewports for things like scenery files, they will need to be set up using imported layers rather than the most current practice of placing a Design Layer Viewport on the target layer.

 

I had never actually used references in this way, so this might be a game-changer in terms of how I approach drawings.  Having the layers actually imported means that I have easier control of class settings in viewports, as my current practice is to have multiple design layer viewports from the same reference with different visual settings.  The only thing I would need to keep in mind is that it looks like I will have to make sure that the origins are aligned before creating the reference since I won't be able to move the objects around afterward...

[klinzey]

If you also need to control the data in Lightwright you can use layer and class filters in Lightwright to include or exclude the lights when viewing and reporting.