Jump to content

Wood

Member
  • Posts

    61
  • Joined

  • Last visited

Reputation

23 Great

2 Followers

Personal Information

  • Occupation
    Rigger
  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Look into data tags, they're very powerful and is the solution you're looking for. I made my own, it's not terribly difficult if you reverse engineer one of the existing ones. They will show any data that is available in the hoist record, or custom records attached to the symbol, depending on how you're set up.
  2. Is there a way to color a specific portion of an object? For example, the stock VW Hoist geometry has a class "rigging-Hoist-Hoist Color-Lodestar" which is the only colored portion of the 2D symbol. I want ONLY those small portions of the hoist symbol to change, not the entire 2D object.
  3. @jcogdelldo you folks have a guide for this that can get us a bit more detail on best practices for importing DWG? I haven't had time to search the University but is there a PDF or coffee break that covers this? Mastering Venue import is a hole in my skill set, and I'd love to learn 'the right way' to keep performance up, and ultimately have useful Classes after dealing with the apparent nonsense of most DWG organization methods. Do exploded blocks (which import as groups if I'm not mistaken) perform better as just straight geometry if we can't dedicated the time to convert them to symbols?
  4. @TomWhiteLight So, I am familiar with this functionality, and unfortunately those colors are far too close to be useful for me even with a wide berth on start and end. By the time you print 4 shades of green on a white page, and use them to label similar looking items (I use them for length on my truss build drawings), they are indiscernible for the average end user. Obviously I can manually select each color, but that's no fun. Being able to instruct the tool to select from the collection of colors in a particular pallet would be great. Not a start and end shade, but a specific pallet entry for each data point. Throw an error if it runs out of pallet colors before it runs out of data points. Does that make sense? For example, the pallet below has a limited number of colors, but they're all pretty far apart (with some exceptions because this wouldn't be my data viz pallet)
  5. I'm sure many of us here work with plenty of strange venue drawings, usually pulled out of a DWG with little attention paid to cleanup. I'd like to start a discussion about the best way to start a fresh show file, beginning with having the venue drawing standardized. So many times the venue is nowhere near the drawing origin, is in a crazy scale, etc. This all adds to workload as we have to move our template viewports around, transpose origins, deal with changing scale as we import other department's layers, etc. Obviously Project files eliminate some of this, but many of us still find it more efficient to work in our own file before interacting with the group master drawing. The venue layer is the foundation of the show file. With that in mind, here's what I like to see. Please add your thoughts! Document and user origin aligned, with all of this being show zero. This point should be based on readily identifiable accurate building architecture. Examples of this for XY would be: Stage lip and center of the proscenium. An intersection of two beams in an arena, or at the center of the bowl or show floor where there is often a permanent mark in the concrete An intersection of an airwall track or a house rigging point in a ballroom. Don't trust soffits or walls, they're often wrong. For Z: Concrete of the arena floor, the stage deck in a theater, or the carpet in a ballroom etc. Ultimately, this point should be readily identifiable both on the venue drawing and when you walk into the venue, WITHOUT NEEDING A TAPE MEASURE. I've seen many shows layout in the wrong spot because somebody decided that show zero should be an arbitrary distance from some arbitrary point like a wall sconce that is not accurate to reality. I like to use things that are made of steel, because the iron holding up the building is generally pretty accurate, whereas things like remodels and new coping or trim can change wall dimensions and not get captured on a new venue drawing. Beams generally don't move. Moving show zero to your temporary stage is not helpful to the layout team. The hoists don't care where your stage is, they care where the beams are. Depending on shape of the venue, Upstage should be Y positive or X Positive. Arenas and stadiums almost always benefit from having the stage area X positive (50 yard or centerfield line runs along the Y axis. Theatres should typically have the stage Y positive, with the lip of the stage (or plaster line) running along the X axis. Ultimately, put it in the orientation that fits the important bits onto a landscape sheet without requiring rotation. If it's important to you to work with Upstage facing up in your design layers no matter what, please use the rotate plan feature so the rest of us don't have to rework all of our sheet templates. If you want to confuse the heck out of people, rotate your sheet viewport so that Y positive isn't up when holding the plan in your hands. (Don't do this). Scale. Again, please make the important bits fit into a standard sheet size, like an ARCH D sheet in landscape. We probably don't need the entire arena to fit in that space, but the show floor and maybe a good amount of the lower bowl (if you plan on hanging truss there) is great. Scale in the design layer DOES MATTER. Having it wrong is annoying when annotating or using zoom shortcuts. For the building geometry itself, please stop grouping everything into class 0, none etc. If the base drawing has classes that allow us to turn off beams, pipes, etc please keep that intact. Turning the venue into a symbol can be useful, but I find that it makes the visibility tool difficult to use, and eliminates the ability to see what components might be, because clicking on a line activates the entire symbol. LOCK the geometry before you start drawing! More than once I've received drawings where key pieces of the architecture like rigging beams have been inadvertently nudged, which can lead to catastrophe during load in if not caught early on. A smart draftsman references in their Venue so that it can't be changed. I prefer old style layer references vs a viewport. Viewports eliminate too much functionality, such as being able to see a light fixture's weight and calculate it in braceworks What may seem like a non-issue to you as a person dropping in lighting fixtures or speakers, can be a huge annoyance and add hours of work for the folks that have to assure that all of this stuff lines up in the building. That isn't a jab at other departments, but the reality is that truss and audio motors are usually already in place when your work begins, so you don't typically see the consequences of drawing bugaboos and inaccuracies. The lights don't care where the truss is(within reason), but the custom scenic surround that builds up from the stage deck to mate with a flown LED wall really does. And in today's high end shows, fractions of inches matter. Sorry for the treatise, but please add your thoughts on best practices, so that we can all make each other's lives easier and more efficient! I very well may be wrong on some of these opinions, and I'd love to know the best way!
  6. Bumping this to continue a discussion that is already in progress. I use some links and values in a data record that are specific to hoist type. This helps me generate paperwork for a couple different purposes, and having to manually enter this data (even if doing it in bulk for each hoist type) after dropping a hoist in each new drawing defeats the purpose of streamlining the operation by pre-filling fields. Is there a way around this? A light fixture will have different values for wattage, DMX channels etc per fixture, just like a hoist symbol will have different body weight, chain weight, chain length, etc. How do I piggy back onto this functionality for other values, without defaulting to the 'notes' field that so many people use for other jobs? I wouldn't need to edit this on a per drawing basis, as this data is directly related to the hoist itself. Thanks!
  7. Thanks Stefan, I'm going to continue this discussion over there.
  8. While we’re chatting, can autocolor choose from a specific pallet? The current autocolor makes the shades far too close to be discernible… Or am I missing a setting? I know you can select the hue range, but I need granular not gradient.
  9. I have a hoist symbol that has a record attached that contains some default values. This record is visible in the Resource Browser above the HoistObjectData record, with the desired data in the fields. When I drop this symbol into a new drawing (the hoist tool is automatically selected), the symbol does not stay attached to the hoist. The record automatically imports into a generated RECORDS folder, which matches where it lives in the favorite VWX. The record is attached to the symbol in the new document, but it does not attach to the symbol on the design layer in the OIP. I have tried both importing the symbol into the document's resource browser before inserting, and also just selecting it from my favorites. The associated record comes along with it What am I missing? Thanks!
  10. Very clever! Anybody with some fresh stream deck profiles willing to share?
  11. @JustinVHSorry I've been away from the forum. Yes, I'd love that documentation. I'm currently building libraries for one of our vendors and they have quite a few items. Thank you!
  12. Having the exact issue right this moment. I even tried locking the fixtures as well as turning off their layer completely, and they all still move. Surely there are more than two of us who need to move truss around without changing the lighting design....
  13. Thanks Justin! I didn't know about the records, so I'll give them a shot. Is there any documentation on this that I can study?
×
×
  • Create New...