Jump to content

SamIWas

Member
  • Posts

    409
  • Joined

  • Last visited

Posts posted by SamIWas

  1. On 11/9/2017 at 5:19 PM, Don Seidel said:

    While a Filemaker user for some 20+ years, I enjoyed the fact you could get an awful lot accomplished without fancy scripting/programming. My point about it being year 2017 is that ODBC is supposed to be the magic key to link to different DB's. As long as you have assigned fields in each DB to sync, the process should be just so simple. There's only 3 options for crying' out loud; force data one direction, the opposite, or sync (with most recent entry as conflict resolution).

     

    Yes of course the programming is more involved that that, but why on earth can't the interface be just so simple? For example: I take a Window plug-in and insert it into a wall, with options I choose. It's done. Next task. There's no desire or need for me to learn the programming language to make that happen.

     

    I have been a Vectorworks and Filemaker user since around 2004.  I write complex scripts in Vectorscript and entire multi-table, relational, script-driven databases in Filemaker.  I still, after more than a decade of trying, cannot get VW and FM to talk to each other over ODBC.  Every few months, I get the desire to try again, and every single time, it's an abject failure.  Something that should be fairly simple (especially for someone with a fairly deep understanding of scripting) and would change the way I develop my workflow, but I just can not get it to work.  

     

    If someone has managed to get VW and FM to talk over ODBC on a mac, I would love to hear from you!!  

     

    Obviously, it can work because LightWrite and Vectorworks do it.  

  2. On 9/1/2017 at 1:04 PM, JimW said:


    Right, those are some that (at least primarily) make their own UI rather than using included system elements. C4D for instance has its own version of the menu bar contained within the application window which gives them greater control that I am jealous of.

     

    For me, Cinema4D's UI is the best UI out there. Infinitely customizable and easy on the eyes.  You can arrange your windows however you want, group them, tab them, adjust the font and color or every item. Just great. 

    And FAST. 

    • Like 1
  3. 31 minutes ago, halfcouple said:

     

    Yes, that's exactly the point!

     

    And many thanks to digitalcarbon for the video! This exactly describes my daily pain with VW Hidden Line rendering !

     

    Yes. All I need is what OpenGL does with "show edges", but actually showing all of the edges (or better yet, based on angle)  and no shading. That alone would fix everything I've been looking for. 

  4. On 11/3/2017 at 4:20 PM, zoomer said:

    I, on the Apple side, still hope for a Touch Monitor from Apple.

     

    You better watch it!  I asked for this on a Mac users forum and was strongly criticized for even suggesting such a thing.  Essentially, if Apple doesn't have it, then Apple should never have it because it's not a product which should exist.  

     

    But, what I found is that MacOS doesn't even support touchscreens.  As in, you cannot go buy a touchscreen and plug it into your iMac or MacBook and use it.  Amazing.  EDIT: I should add that I mean standard, off-the-shelf touchscreens.  

  5. 4 hours ago, Miguel Barrera said:

    You can also use ODBC to connect to databases either from VW directly or programmatically with vectorscript. You can find a connection example at

     

    http://developer.vectorworks.net/index.php/VS:DBDocAddConn 

     

    and all routines at

     

    http://developer.vectorworks.net/index.php/VS:Function_Reference#ODBC

     

    I've been trying for more than a decade to get Vectorworks and Filemaker to talk using ODBC.  Not with Vectorscript, but just through their built-in options.  I was successful like one time many years ago for a brief trial on one file.  It amazes me how difficult it is to get that working.

     

     

    As for the OP, exporting all of your info should be a pretty simple script.  I have a large number of scripts which import information out in tab-separated files for import into Filemaker.  They all use the calls Sam Jones specified above:

    • Open(filename)
    • PutFile;
    • Write;
    • WriteLn;
    • Tab(1);

    A quick example of just the write lines:

            Write(GetRField(h,'LED Ribbon','ID'));Tab(1);
            IF GetRField(h,'LED Ribbon','Location')='' THEN WRITE ('-') ELSE Write(GetRField(h,'LED Ribbon','Location'));Tab(1);
            IF GetRField(h,'LED Ribbon','Position')='' THEN WRITE ('-') ELSE Write(GetRField(h,'LED Ribbon','Position'));Tab(1);

     

    These are all using the same record format, but you could use any number and mixture of them.

  6. 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. 

  7. 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?

  8. 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.

  9. 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?

     

  10. 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
  11. 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.  

  12. 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
  13. 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.

  14. 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.

  15. 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. 

  16. 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.

  17. 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.

  18. 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. :/

  19. 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.

  20. 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". 

  21. 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.

×
×
  • Create New...