Jump to content

Robert Anderson

Vectorworks, Inc Employee
  • Posts

    3,233
  • Joined

  • Last visited

Posts posted by Robert Anderson

  1. Dimension markers are page-scale objects (as are all line markers). I can't imagine anyone needing one at 2". It's important to understand the Vectorworks concept of "Layer Scale", which is the property (of Design Layers) that controls the size of page-scale objects. (Layer Scale -- and page-scale objects -- do not exist in AutoCAD AFAIK.) If (say) you're going to be doing most of your drawings at 1:50, set your Layer Scale setting for your Design Layer at 1:50. Then set the size of your marker to 1/4" or whatever you want as an output size. You will still be working on all your objects in "World Scale" (the size of things in the world). One of the nice things about Vectorworks is it manages these two things (the size of things that belong only on the page and the size of things in the world) separately and (mostly) transparently -- once you understand it and quit trying to make your markers work as if they were real things.

     

    Somewhat deeper intro into "Layer Scale":

    The "Layer Scale" used by VectorWorks comes primarily out of "WYSIWYG" drawing, pioneered on the Mac (and therefore part of Vectorworks' history). "Layer Scale" exists to allow graphic properties of the drawing or model to be represented properly, as though you were drawing at a particular scale on a piece of paper. It is a scaling value used to allow proper representation for PAGE-SCALED (as opposed to WORLD-SCALED) attributes:

        -Line weight;

        -Line style (e.g. length of dashes);

        -Marker (arrowhead) size;

        -Text size;

        -Hatch scaling;

        -Page symbol scaling;

    In "WYSIWYG" drawing, in order to properly display these attributes, there has to be an intended output scale so you can see how the drawing will look at that intended format. The practical upshot of all this is that you should set your "layer scale" to be the same as the predominant output scale of your project. This will necessitate the least amount of attribute-scaling in viewports.

    But in all design layers, at all times, you are drawing in world scale. An inch is always an inch, a foot is always a foot, no matter the "Layer Scale". "Layer Scale" serves only to set page-oriented graphics.
     

    • Like 1
  2. What happened when you converted to NURBS? Did that work successfully (before the lofting)? If so, I would try this:

    Convert your mesh to NURBS. This will give you NURBS curves.

    In the 3D Powerpack menu, select your curves and choose "Create Surface from Curves". (you may have to do this in several sections to get everything). 

    Now try shelling from the NURBS surfaces. 

     

    Let me know if this works..

  3. Hi, TDM

    I would start by turning off textures and texture mapping and changing "Import other objects" to Meshes. I'm guessing (because i'm not an engineer) that this is the lowest-memory impact import. If that works in a reasonable time, try turning textures back on and re-importing. Good luck!

  4. It's far better to use the conversion process provided that start from scratch, IMO.  Then make any minor graphical adjustments needed (if any) and then copy the style symbol to a new file. Repeat for all your different title blocks, then put the file where you've collected your style symbols into the appropriate subfolder in the Object Styles folder in the Resource Manager. 

     

    The second thing to learn is to get friendly with the "Edit Plug-in Style" when you want to make changes to your TBB.

  5. I partly agree with Jonathan here.

     

    It's true we didn't include Sheet Border --> Title Block Border in Migration Manager. This was a conservative decision based on the fact that we wanted users to review the updates first hand to verify things would convert properly. And this approach has turned up some limitations quickly, many of which are fixed in SP1 and the other known ones will be fixed in SP2.

     

    The conceptual difference is that in VW_2017 and before, you used a symbol definition text-linked to a series of (rather cryptic) records to define the layout and textual content of the Titleblock. Now you use a Style-symbol to control everything about the Title Block Border, and of course the Vectorworks Style system for PIOs gives you full control over what you control by-style and by-instance.

     

    You can convert the old SB-PIOs to TBB-PIOs one at a time and, if they look right, they are right. Collect these style-symbols into your template files or (better) into a VWX file that you put into the Object Styles / Title Block Border and, as Jonathan might say, Bob's your uncle. (You'll have to ask him what that means, exactly.)

  6. I'm not 100% sure on this issue, so you might want to get in touch with Tech Support. But just guessing, you're running an 8-year-old version of the application software on a 2-year-old version of the OS. I'm guessing there may be a basic incompatibility and you may need to upgrade your Vectorworks. Apple is known for introducing incompatibilities from version to version of their OS, and we often offer an "SP5" to fix incompatibilities from the previous version. But 8 versions back is a little long in the tooth. Tech Support should be able to give you a definitive compatibility answer, though.

  7. @CJustinStockton,

     

    People often get confused about scale because our Design Layer environment has what is called "Layer Scale". 

     

    The "Layer Scale" used by VectorWorks comes primarily out of "WYSIWYG" drawing, pioneered on the Mac (and therefore part of Vectorworks' history). "Layer Scale" exists to allow graphic properties of the drawing or model to be represented properly, as though you were drawing at a particular scale on a piece of paper. It is a scaling value used to allow proper representation for PAGE-SCALED (as opposed to WORLD-SCALED) attributes:

        -Line weight;
        -Line style (e.g. length of dashes);
        -Marker (arrowhead) size;
        -Text size;
        -Hatch scaling;
        -Page symbol scaling;

    In "WYSIWYG" drawing, in order to properly display these attributes, there has to be an intended output scale so you can see how the drawing will look at that intended format. The practical upshot of all this is that you should set your "layer scale" to be the same as the predominant output scale of your project. This will necessitate the least amount of attribute-scaling in viewports.

    But in all design layers, at all times, you are drawing in world scale. An inch is always an inch, a foot is always a foot, no matter the "Layer Scale". "Layer Scale" serves only to set page-oriented graphics.

     

    If you have symbols, they are all stored in a 'hidden' part of the file called the "Library" that contains Symbols as well as other resources (such as hatches and textures). You access all these through the window called the Resource Manager. No need to put them on a layer.

  8. Beth and Martha,

    SP1 will fix many issues with titleblock conversion. However, in the short run, you should be able to convert titleblocks using the guidelines in this thread:

    • Do not use invisible classes in your titleblock symbol;
    • Do not shift the page or change the origin on your sheet layers;

    If you have followed these guidelines and are still seeing conversion problems, please send the files to me. Thanks!

  9. 4 hours ago, nrkuhl said:

     I dream of a day when Rhino's BIM / parametric plugins are fully production ready.

    This will no doubt be controversial, but who cares:

     

    I think it's easier to come up to speed with a computational design capability (as in Marionette) integrally applied to an existing BIM product rather than come up to speed with a BIM capability applied to a computational design product. (Discuss..)

  10. I have just received the following message from the engineer working on this problem;

     

    "I have investigated TB_Le_Pham.vwx and in the classes Signature and Stamp there are objects that are part of a Title Block Border Layout. In the test file these classes are invisible. That is the reason why the group boundary of layout is different from visible objects boundary. For the second problem with Drawing list worksheet the user have to update formulas to the new records of Title Block Border object. For example =('GEP Titleblock Record'.'S_Sheet Number_SN') has to be =('Title Block Sheet Data'.'Sheet Number'). Also the user has to edit the criteria. The field S_Drawing List is not added into new Title Block Sheet Data record because its value is not linked to text into Sheet Border symbol.

     

    The problems with file TB_John_Crosetti_v2018.vwx are fixed for 23.0.1 and with VW389180 the file is updated correctly.

    The problems with file TB_Andrew_Carr.vwx are fixed for 23.0.1 and with VW389180 the file is updated correctly.

    The problems with file TB_Crawford.vwx are fixed for 23.0.1 and with VW389180 the file is updated correctly."

    • Like 1
  11. Open a 2017 file in 2018. Select an old Sheet Border object. You will see on the Object Info palette the "convert" functionality. You should not have to rebuild entirely. There was a bug discovered that occured if the user had shifted the page on a sheet layer, but as long as your origin has not been shifted on a sheet layer, you should be fine.

  12. I am sorry you're having the problem with the incorrect conversion of the Title blocks. I believe it has to do with (as one poster suggested) the changing of the origin on the Sheet layers. I have created a bug report covering this issue and referencing this thread. If anyone is having trouble converting a v2017 Title Block, please send me a copy of a Vectorworks file with a single sheet layer and that title block in it. If we can reproduce the conversion error, we will fix it ASAP. Send to randerson@vectorworks.net and I will make sure the example files are attached to the bug for testing.

  13. Hi Joe, and thanks for posting on this timely topic. I think that my answer to your question lies in the way we've implemented our algorithmic design tool, Marionette. Marionette is an open source design environment that is 100% Python based and can make use of any Python library out there. So any library that you need (NumPy, SciPy, Pandas, MatPlotLib, GeoPy, etc., etc.) can be downloaded and included. I don't think the power of this can be overstated. 

     

    Sarah Barrett, one of our Marionette evangelists, has done a number of "infographic" Marionette definitions that you can see over at our Marionette page. Climate data, psychrometric charts, etc. Below is one of her popular ones that uses e.g. GeoPy.

     

    There are other advantages on using Vectorworks as an algorithmic design platform, not the least of which is the degree of integration that you can build between your BIM model and your algorithmic design functionality. Imagine a prototypical building that could be deployed across a region, and could optimize its sun shading and photovoltaic array automatically on each site. This can be done today using Vectorworks' Marionette tool.

     

    I'm working (as we speak) on a Marionette presentation for next month that I will vid-cap and share with the Marionette forum here. Look for it!

     

    Thanks again for posting and your kind words on Vectorworks.

    • Like 1
×
×
  • Create New...