Jump to content

twk

Member
  • Posts

    884
  • Joined

  • Last visited

Posts posted by twk

  1. hmm this only seems to work for me if I put the py file in a root directory; C:\, D:\, L:\; etc

    #COMMAND;REFFILE;D:\stair_elevation_maker.py;

     

    once i put it in a folder it doesnt work:

    #COMMAND;REFFILE;D:\test_branch\stair_elevation_maker.py;

     

    error pops up saying:

    - the referenced file not found

    The specified file was found but could not be written to.
    Click Ok and made the file writable to save your changee 
    If you choose Cancel you scipt will be saved locally in the node 
    but these changes maybe lost when the scipt editor is opened next time 

    any thoughts on fixes?

  2. 2 hours ago, ericjhberg said:

     

    For example wood grain, posts/columns have a vertical wood grain, while horizontal slats have horizontal wood grain. Using Lumion textures, you can only map one direction per texture, but in VW you can manipulate the direction of textures per object.

     

    Insert here, a chance to show off a little...

     

    Nice..

     

    We do the same with our material workflow.

     

    FBX has been working quite well for us as well.

    Previous VW version exports to FBX caused problems with flipped normals. 2017 onwards fixed this.

     

  3. I would say its a bit less intuitive than twinmotion.

    +'s for Twinmotion:

    + Twinmotion has object editing of import objects (moving internal components of import model) whereas Lumion cannot manipulate imported models.

    + Twinmotion VR export is a much smoother process

    + 360deg Video export (animated path)

    + Object hierarchy helps with keeping model organised

    + Interior Renders

     

    -'s for Twinmotion:

    - render quality is not the greatest for exteriors

     

    Lumion is pretty much the opposite to the list above. Apart from the interior renders for Lumion are also very good.

     

    For me personally Lumion produced better quality renders than Twinmotion, albeit with a not-easy-to-get-used-to interface.

    Put it this way, I know someone who uses 3dsMax with VRay, and she dislikes the Lumion interface with a passion 🤣, and at the same time can't understand how it can produce renders at that quality, in under a minute. After a year, she's still getting used to the interface with complaints every now and then.

     

    However don't get me wrong, any of these programs are powerhouses in the right hands. 

     

    side note: this was when I trialed out the Twinmotion 2018 version. Havent tested the 2019 version. We are on Lumion 8.5

     

    I also +1 that vectoworks play nicely with these two rendering packages.

     

    • Like 3
  4. Never had to edit VS Studio search paths.

    When I did used VS Studio, the vs file was just kept in the root folder. (I use PyCharm Community Edition now, far superior)

     

    The vs.py file must be in your projects root folder.

    our folder structure:

    L:\Documents\VisualStudio Projects\Custom Vectorworks\Plugins\Custom Scripts\

    - "L:\Development\VisualStudio Projects" is our Projects folder in Visual Studio

    -  "L:\Development\VisualStudio Projects\Custom Vectorworks" is our one of the paths in our Vectorworks Preferences "Workgroup and Project Folders" paths

    - "Custom Scripts" is the root folder where all our scripts are

    Under the custom scripts folder we have other folders organised by vectorworks specific functions:

    \obj_wrappers

    \document_properties_wrappers

    \etc..

     

    When it comes time to coding, below is sort of the start off:(FYI example shows custom modules we've made to make coding in VW easier).

    Search for DLibrary in the forums for Dieter's amazing VW python library. 

    import vs
    from obj_wrappers import vw_Obj
    from document_properties import *
    
    OBJ = vwObj(vs.FSActLayer()) 
    # vw_Obj is a custom made class wrapper that contains every property a vectorworks object may have eg. width, height, layer, class, type, etc.."
    height = OBJ.height
    width = OBJ.width
    obj_layer = OBJ.on_layer
    
    alert_dialog(obj_layer)

     

    In my experience, VS Studio picks up intelli-sense for vs.py and my custom modules. Showing documentation, and auto-completion etc

     

    • Like 1
  5. Please add the ability to add labels to the Structural Member tool, just like the Framing Member tool. But with the ability to class said label, like the Column Tool.

     

    On 11/25/2016 at 3:00 PM, Itchy said:

    Trying to get a label on the structural member (SM) just like the Framing member (FM), ideally for it to pull the profile size direct from the object but I can't seem to find out how to?

     

    FM just selected Label text and I would then write in the size. With the SM there is a member ID, but then not sure how this gets displayed? I tried the ID label tool but it doesn't seem to pull any info from the SM?

  6. This is crazy! Trying to use the structural member tool in a real world project and just realised we can't show labels on the drawing! Oh the promise.. 2 years ago.

    Surely this is a simple thing that doesnt need to be wishlisted!? Maybe release it for a SP? Anyone else using the structural member tool to an advantage?

    • Like 1
  7. On 9/30/2018 at 11:47 PM, Amorphous said:

     

     

    Hey @twk since you are the only one reporting good success so far, can you tell us what your save and commit times are?

     

    I recorded a video of our save and commit, see below, and it is 6 minutes. 

     

    The file with the biggest issue is a 1000-sqm residential alt and adds , with 300+ pages of documentation. Everything lives in one single file, lots of hatches, wall types, slab types, worksheets etc. Is that the type of project you are using VW for? I'm interested to know.

     

    Save And Commit.mov

     

    Sorry for the late one, below is our refresh and then commit times for comparison. This is a six story building with 3 wings/towers. Separated files for plans and details. Working file sizes - 1Gb, Project File size - 400mb

     

    We had experienced slower commit times in 2017. Just updated the project to 2018 to make use of the multi-vew viewport feature, which is a major game changer for a project this size.

     

    Refresh time : 50seconds

    Save and Commit : 1minute

     

    What was being updated: Structural members for whole of level 5 (floor beams/roof beams/columns/etc)

     

    Pluses for 2018 Project Sharing:

    - less crashes than 2017 (relative term here)

     

    Minuses:

    - connection/link to master file drops sometimes. Solution is to save working file. Restart vectorworks, and then open the saved working file again, and we see the connection is restored. This is by turning on the project sharing options icon, we can see highlighted objects we have checked out.

    - terribly slow calculations for worksheets. This could be due to scripts used in the worksheet + the size of the project.

     

     

     

  8. Thanks for sharing @Matt Panzer. Your one's a bit different to the one I was talking about.

    Attached here (install as previously instructed by Matt in the previous post). It has a couple of useful parameters, shown in the video. If anyone knows the  dbelfm@sonic.net developer, please post his name here so he can be credited accordingly.

     

     

    I can't remember where I got it from, i think it was from the time the VectorDepot was up and running. Was a great place to see plugins by other people. Vectorworks really needs one for their 3rd party plugins. We actually need one like Sketchups Extension Warehouse.

    I mean the infrastructure is there isnt it? We've set one up for Marionette albeit it's through the forum. Would it be too much to set one up for the actual program? At the moment the library files in the Resource Browser are updated from an online repository, would be great if there was a system inside vectorworks where you could browse Vectorworks' official plugins and third party plugins and install them from some online repository (an official one). Making it easier to deploy plugins and encourage 3rd party developers to develop.

     

     

    Breaker_v1.vso

    • Like 3
  9. Hi Julian,

    Nice list!

    A1

    - our file sizes are similar but we dont experience the problem of save and commit times

    - we keep everything in one file (sheets/model elements); just a seperate DETAILS file (project shared as well, but in no intelligent way connect to the PLANS file, ie workgroup referencing)

    - save and commit times have improved with 2018 SP4; what used to take 5mins now takes 1min

    - We also dont have an issue with releasing a single element as you described. Releasing a wall its very quick. It doesnt do a full save and commit the master file when we do this.

    A2

    - Section viewports are slow

    A3

    - Same experience; terribly slow

     

    Good post; I shall upvote!

  10. Chiming in from the lower southern hemisphere:

    We started with project sharing the year it got released, 2016. Our experiences since then have been mostly the same as with everyone else, including;

    - crashes during commit,

    - commit reports as succeeded but opening the master file the next day shows no commits;

    - having to resave a master file every so often (a single project went through 4 master file re-saves during a 6 month period)

     

    These being said; we wouldnt have completed projects fast enough WITHOUT project sharing. We've managed to split our tasks to floor plan draftees; detail draftees and designers. So we need all 3 groups working at the same time on any project. We're quite a small office with the type of projects we're taking on, but the project sharing has allowed us to keep the tight-knit numbers and push out the projects.

     

    I'd add also our network server had to be upgraded from a 1gb to a 10gb switch to handle the network traffic of 5 people saving and committing multiple projects at the same time (projects' file sizes ranging from 600Mb to 1.5Gbmax); After the upgrade we have not experienced any crashes during save and commit (this is from 2017 SP4 onwards; 2018 is the most stable release so far); So I think the network infrastructure plays a big role. We tried onedrive for remote access, but it was way too slow. Any cloud solution failed actually (tried dropbox and google drive); meaning there would conflicts with file names etc.

     

    So they work for us now; after multiple headaches.. its been smooth sailing for us for a year now.

    • Like 1
  11. Thanks for this initiative VW( @Jim Wilson). Agree with everything already said.

    I'd add +100 to the LOD comment. That would be awesome to able to start with a basic stair and the ability to built upon that later(parametrically) if needed.

     

    On 9/15/2018 at 9:57 AM, zoomer said:

    So something like the Basic Editing Mode that German Windows have.

    You can set them up quickly and increase LOD and Features at any

    point later.

  12. 14 minutes ago, Boh said:

    Wow sounds pretty complicated. Multiple titleblocks on a single sheet but on different classes?

    How do you manage that? With saved views and worksheets?

     

     Yep, complicated is one word to describe it.. 

     

    We're using a combination of saved views, saved publish sets and a bit of scripting to manage the writing to the Issue and Revision parameters of each VAATB.

    And scripting for the worksheet drawing register..

×
×
  • Create New...