Jump to content

SamIWas

Member
  • Posts

    303
  • Joined

  • Last visited

Posts posted by SamIWas

  1. On 9/18/2017 at 1:18 AM, Gabriel Chan said:

    Interesting how we set up our lighting plots. Always so much to learn on the forum :) I usually set up my plot with layers for the venue, scenic (one layer per act/scene), and for lighting, I tend to split them into overheads, floor/booms, Front of House. They get more complicated with the DLVP for vertical positions, but that's generally the gist of it.

     

    I guess it's a matter of preference as to how MA layers are setup. I usually patch by position, which granted is definitely a more laborious way of patching as opposed to "genre". I do that because its easier for chief electricians to trace patch IDs on the console and sometimes, technicians (not the chiefs of course) get rotated on shifts, so that makes things somewhat easier. So exporting layers to MA via Position came naturally in my option.

     

    So let's say if we do patch by "genre", would the new class options by VWX Spotlight help? Those new classes such as "Lighting-Moving Lights", "Lighting-Conventionals" that are automatically, and somewhat annoyingly added. Just thinking out loud.

     

    Gabriel

     

    Sure. Then that goes back to designing my VW plot layer or class structure  around the grandMA patch: Having to build classes solely for patch. Then I have to make sure all those classes are turned on or off in whatever viewports and saved views. That is a LOT more work then just being able to specify a patch layer in a user field. 

  2. 6 hours ago, Gabriel Chan said:

    I wouldn't actually say that the VW drawing needs to be designed specifically around the export. In fact, with the way I already draft lighting plots, the plugin sort of works intuitively; you get a few options as to how you want to approach the export, so there might be one that suits others better.

    As for deriving from user fields, of course that's a nice thing to have, but then that means entering data twice, once in your patch and then in the user fields. Seems like more work and room for error. The point of the plugin is to streamline workflow so having another user field data entry sounds counterintuitive?

     

    Not sure I follow.  The plugin gives you four options for exporting layers from Vectorworks to MA: Design Layers, Classes, Fixture Type, or Position.  Now, I don't know how you draft your plots, or how you do your layers on MA.  But I know that my plots have layers for scenic, rigging, fixtures, cable, racks, etc.  And I have classes for lots of things, but I do not class fixtures based on layer.  In no way would I design my Design Layer and Class structure around exporting to MA, so those two are out.  Fixture Type and Position remain.  On MA, I have layers separated by "genre"...so "Conventional", "Movers", "LED", "Worklights", "FixtureMart".  Since those don't jive with anything I would do in Vectorworks, those are out.  

     

    I'm not sure how having a user field for layer is entering data twice.  Where am I entering the layer info in the patch and a user field?

  3. 7 hours ago, jah011 said:

    @SamIWas

     

    Symbol you included has no record fields etc... or it doesent work with my VW? just checking. it  looks like standard symbol with text.

     

    Ill try Help files for adding record fields, first time i hear about it.

     

    thx

     

     

    Did you go into the data tab of the Object Info Palette?  If you don't see the fields there, then you definitely have an issue.

     

    If you want the data fields on the shape tab, then you have to create a custom plug in object, which is a whole different animal.

  4. I have a PIO that I've created which has some text elements and those text elements must have a background fill to be readable.  My VW preferences are always set to create text without background fill, and unfortunately, this appears to affect PIOs regardless of PIO code.  

     

    This is a snippet of the code:

    FillPat(1);
    FillFore(65535,65535,65535);
    FillBack(65535,65535,65535);
    PenPat(2);
    PenFore(objcolor);
    PenBack(objcolor);
    			
    TextJust(2);
    TextVerticalAlign(3);
    TextFont(GetFontID('Avenir Next Bold'));
    TextSize(18);
    
    TextOrigin(0,0);
    CreateText(concat(distbase,CHR(39)));

    No matter what I set FillPat two, it doesn't seem to make the text have a fill color.  I'm not finding something to set the fill color attribute to "solid" without using FillPat.  Am I missing something?

     

  5. This could be done as a plugin object, which would give you more control, or as a simple symbol with a record attached, which would be easy and could be made in minutes with no scripting involved.

     

    For the simple symbol, do the following steps (not detailed with every step):

    • Draw your symbol as it will be needed, with the text formatted in place
    • Select all objects involved, and create the symbol, being careful to select the right insertion point
    • Create a record format with the fields you need to change in the symbol such as height and depth (in this case, it will only change the visible text labels).
    • Add fields to the record format of the number type, and format them as a dimension.
    • Edit the symbol
    • Make sure nothing is selected in the edit symbol window and attach your new record format in the OIP.
    • Select each text field then use the "Link Text To Record" command to assign a record field to a text object.

    The attached file has an example.

    Data Symbol.vwx

    • Like 1
  6. I feel your pain.

     

    If you were scripting it, you wouldn't have to even go as far as adding the locus and whatnot.  The script would simply get a handle to the object, get the coordinates of the object (which would be the insertion point), then use HRotate(90) to rotate the object 90˚ counter-clockwise about that point.


     

    PROCEDURE RotateObject;
    
    h : HANDLE;
    sx,sy : REAL;
    
    BEGIN;
       h:= FSActLayer;
       GetSymLoc(h,sx,sy);
       HRotate(h,sx,sy,90);
    END;
    Run(RotateObject);

    At one point, when keyboard commands actually worked reliably, i had mapped a version of this script with 5˚  increments to my scroll wheel, so I could select a fixture and rotate it using the scroll wheel.  

  7. On 8/22/2017 at 2:32 PM, Kevin McAllister said:

    I believe the math for geometry is still handled by a single core of the main processor which is why you can't break out of that part of the process.

    The same is true for Sheet Layer Viewports. The math/geometry part is still single core. Once it switches to Renderworks you can stop the process because its multicore and it sees your input.

     

     

    If you'd like me to have a look and see if there's a specific issue with the file you're welcome to PM me.

     

    Have you turned off graphics switching in the System Preferences under Energy Saver? Other things I've seen slow things down on my MacBook Pro are Dropbox syncing, Time Machine backing up or if the computer is very hot (the system will throttle back the processors automatically to cool the system down).

     

    Kevin

     

    On 8/22/2017 at 2:49 PM, barkest said:

    Did you import the objects in to VW?

     

    Thanks guys.  I think I got it worked out.  I delved into what I assumed was the offending symbol, and did some work on it.  Turns out that the guy who built it modeled everything down to each pin on each fluorescent tube in the fixture.  And those pins were mesh rounded cylinders.  Two pins each end of each tube, times 8 tubes per fixture, times 120 fixtures = 3840 high-poly little pins that aren't even visible, but still being processed.  Also found some geometry which was rounded but could get away with a low-angle chamfer instead.  Once i did that, I went from several minute per setup to maybe 8-10 seconds each time.

     

    I'm working in someone else's template on this production, so I'm working with what I'm given.  

    • Like 1
  8. 11 minutes ago, Kevin McAllister said:

    Is the model rendering each time you switch into a 3d view? I suspect its related to your preference for 3d views. Click on Vectorworks>Preferences and then the 3d tab. What's the setting for "Render mode when changing from Top/Plan to a 3D View"? If you set it to "wireframe" it will stop this geometry regeneration.

     

    It sounds like there's a lot of 3d geometry in the file. Does your MacBook Pro use a proper graphics card or is it using an integrated graphics chip? I understand the integrated graphics chips have a hard time with a lot of 3d geometry.

     

    Kevin

     

     

    I fixed it automatically going into OpenGL, which has helped somewhat.  I guess that was my main issue.  Still...it shouldn't take over and not let you stop it.  But even when starting a render on a viewport on a sheet layer...sweet jesus...can't do anything else.  Which is odd, as I thought that worked in the background.

     

    I'm definitely going to go through this symbol library I was given and clean it up.  There's no reason it should take almost 10 minutes to process the geometry for about 100 Image 80s.  

     

    The MacBook is the highest-level one made, so it does have a real graphics card.

  9. I'm working on a file using symbols from someone else.  It's his template for him, so I'm not looking to change all his symbols....yet.

     

    But seriously....every time I click into a 3D view, a process bar at the bottom-right corner of the green pops up labeled "geometry".  It takes literally 5-10 minutes on a high-spec MacBook Pro each and every time.  And there does not appear to be a way to stop it.  Once it starts, Vectorworks is useless for that period of time.

     

    Is there some way to kill this process?  I'm sure i can search the forum of a while, but I'm trying to complete these plans.

  10. On 8/16/2017 at 0:45 PM, olallapro said:

    So Sam, are you sayin if I patch my console with fixtures then I should build my layers by fixtures and if I patch my console by areas or trusses then I should build my layers in the drawing by areas? 

    Currently, yes. That is how the plugin works. That's one feature I do not like, and one reason I don't use it. The VW drawing should not have to be designed specifically around export. The layers should be able to be derived from a user field. 

  11. On 8/12/2017 at 1:45 AM, Gabriel Chan said:

     

    Indeed multi patched fixtures do have to exist on the same layer on the MA console. But let's cite an example channel (71) which is a pirouette with a scroller attached, rigged on truss C - it fulfils the criteria of it being a multi-patched fixture but it belongs to the truss C layer, both fixture and scroller, so it's not like the fixture is going onto one layer and the scroller a different one.

     

    I'll find time to explore this same file but without all the scrollers attached just to see if your theory holds, but thanks for suggesting this as a possible problem.

     

    Gabriel

     

    Yeah, multi patched fixtures on the same layer shouldn't create an error.

  12. On 8/12/2017 at 11:20 AM, Gabriel Chan said:

    I've had pretty satisfactory results from the MA plugin. Drafted in Vectorworks in 3D and everything ported nicely into MA3D, including all patch information. Saved a lot of time as opposed to manually entering patch data. The one tip I might suggest is to carefully plan how you want your patch layers on the MA console. Having patch layers on MA console by position or by fixture type drastically changes the way you should set up your design layers in Vectorworks.

     

    I really wish the official version would allow patch layers by a user field or something.  I really don't like having to design my VW document's classes or layers around the patch.

  13. Thanks guys,

     

    Apparently, it was a current-launch bug.  Today, the problem is no longer happening.  What's also weird is that all of my other PIOs use the same text-scaling procedure, but it didn't work in this one. So I corrected it without the scaling.  Today, when I opened up the work file, the text was massive.  I changed it to match my other PIOs and now it works correctly.  So, it looks like all of that was related to the same thing.  It's all working now.

     

    Alas...I didn't think to turn it off and back on again. :/

  14. I have a tool I created for placing exhibit graphics.  It's just a simple box and two pieces of text, controlled in the OIP.  All of them react to a "Top" or "Bottom" setting in the OIP as well.  When I select "Bottom", everything lines up as expected.  When I select "Top", the text flies off into space, even though the correct dimension is being calculated.

     

    Here is a sample of the script:

    ---------------------------------------------------------------------

    {---------------CREATE RECTANGLE-------------}
            rectwidth := PWIDTH; 
            rectheight := PDEPTH;

     

            IF PDIRECTION='Bottom' THEN BEGIN
                TextOrigin(0,(-.5-RectHeight));
                TextVerticalAlign(1);
                END;
            
            IF PDIRECTION='Top' THEN BEGIN
                TextOrigin(0,(.5+RectHeight));
                TextVerticalAlign(5);
                END;
            
            TextJust(2);
            BeginText;
                concat(PNAME)
            EndText;

     

            IF PDIRECTION='Bottom' THEN BEGIN
                TextOrigin(0,(-5-RectHeight));
                TextVerticalAlign(1);
                END;
            
            IF PDIRECTION='Top' THEN BEGIN
                TextOrigin(0,(5+RectHeight));
                TextVerticalAlign(5);
                END;
            
            TextJust(2);
            BeginText;
                dimtext
            EndText;

    ---------------------------------------------------------------------

     

    If RectHight is set to 1.5", as is default, and I select "Bottom",  the PNAME text is at -2" and the dimtext text is at -6.5", as expected by the calculations.  If I select "Top", PNAME should be at 2", but the text ends up at 21' 6.56".  dim text should be at 6.5", but it ends up at 14' 9.54".  

     

    Am I missing something, or have I encountered a bug?  I don't recall having this issue previously on other scripts.  Could it have anything to do with the source number being a dimension instead of a number?  Oddly enough, if I put the calculation for one of the top locations in one of the text fields, it shows the correct number, while putting the text off in some weird location.  If I need to include the entire script, I will.

     

    EDIT:  I forgot to mention...if I change the TextVerticalAlign to 1 from 5, the text jumps to the correct coordinates, but is below instead of above that coordinate.

  15. Yep. Most likely the internals of the symbol are in the "None" class. This is very normal. "None" is the default class in every document (along with "dimension"). 

     

    Your lighting symbol might be in the "Lighting" class, but the lines and polygons that make up that symbol are probably in "None". 

  16. On 7/19/2017 at 4:53 PM, Sam Jones said:

    I used to think it was a bug that I had to work around, but it turns out that it is left over from the standard definition of Pascal.  Once the data handling routine is written, it is pretty easy to incorporate it in all the file handling that needs it, but it is not a great way to pass stuff back and forth;  good for collecting data.  

    As I understand it Python has a lot of very cool file handling and processing techniques, but I'm an old dog and used to Pascal, in fact enjoy it.  Josh has been very politely beating me over the head to make Python call for a while now, I just don't have the energy.

    The problem with comma delimited files is that a lot of data has commas in it; european numbers being one of the first to come to mind.

     

    Yeah, that's a bummer.  When I have some time, I guess I'll have to learn python scripting.  

     

    I also can't use comma-delimited.  Almost all of my data has commas in it.  " Edison 12/3, 50' ".  And I'd rather deal with working around it than changing all of the data to something uglier.

  17. When importing a tab-delimited .txt data file from Filemaker, some fields may be empty.  I've noticed that when a field is left black, Vectorworks ignores it and imports the next field in its place.  

     

    So I have this test data:

    R1   1ABC    1DEF    1GHI
    R2           2DEF    2GHI
    R3   3ABC            3GHI
    R4   3ABC    4DEF    
    R5           5DEF    5GHI

    And this simple script to test it:

     

    PROCEDURE ImportInfo;

    VAR
          filename,recnum,field1, field2, field3: STRING;
         
    BEGIN;
        Getfile(filename);
        Open(filename);
        
        WHILE NOT EOF(filename) DO BEGIN
            Read(recnum,field1, field2, field3);
            AlrtDialog(concat('Record: ',recnum,'.  Field1: ',field1,'.  Field2: ',field2,'.  Field3: ',field3,'.'));
        END;  {while}

    END;
    Run(ImportInfo);
                          

     

    So, when I run that script, the first dialog says:

    • Record: R1. Field1: 1ABC. Field 2: 1DEF. Field3: 1GHI

    as expected.

     

    But, the second run of it says:

    • Record: R2. Field1: 2DEF. Field 2: 2GHI. Field3: R3

     

    So, it has skipped the blank area in the first field of the second record.  I have been dealing with this for ten years by putting a dash in empty fields.  But, I really want to move past that, as that is error-prone.   Since it seems to ignore the field, I don't know how to check for the field being empty.  I can't move to comma delimited, and would really rather not move to colon-delimited.

     

    You guys are geniuses, so I'll throw this one at you!

  18. Yep...the way mine is currently set up is that is uses IsNewCustomObject() to generate an ID upon creation, looking at existing IDs and adding 1.  Then when duplicated, it checks the ID against the object name, which changes no matter what.  If those two are different, it changes the ID number.  But, this will only happen upon regeneration, which requires changing a field.  SO, for now, that's what I do.  I'll have to look up how to deal with kObjectCreated/13.  

  19. When I drop some of my symbols into a drawing, they appear to automatically assume a mode from the drop-down menu.  I do not want this, as I have my symbols drawn with the correct information, and Spotlight appears to always put the other mode.  For instance, when I drop in a Viper Performance, it assumes standard mode, while I am using extended.  My symbol's Light Info Record uses the extended number of channels.

     

    This explains why my paperwork was all messed up last show!  At some point, I did a replace of the symbols on the drawing, and the number of channels changed to the wrong mode.

     

    I do not want Spotlight to assume a mode. Yet I cannot find whatever setting may control this.  It does not appear to be in the LIR.  Any way to turn this off, or just something I need to change in my workflow?  Is it something I set when I made the symbol?

  20. Whoa. That all sounds way above my head!  But I'll look it up...don't know anything about the SDK or kObj type stuff. 

     

    That's a shame. Was hoping for something more elegant than having to assign them upon export. 

  21. Expanding functionality of some of my tools a bit further.  I need each object created by the tool to have a unique identifier so that data can be imported and exported between Filemaker.  I have created an ID field in one of my tools in which I create this unique ID upon creation of each object.   This works perfectly currently.  However, any time I duplicate an object, the ID field will not regenerate until I change another field, which kind of negates the purpose.  I've been trying to use the workarounds shown in the IsNewCustomObject page of the Language Guide, but I can't seem to get them to work either until I specifically modify a field in the OIP.

     

    Has anyone figured out a secret to a PIO updating upon duplication?   The Lighting Device tool does it, so it must be possible.

     

    And, while we're at it:  I know how to make a field in the OIP not editable.  But, how can I make the object name also not editable?  Can't seem to find the right procedure.

×
×
  • Create New...