Jump to content

shorter

Member
  • Posts

    1,769
  • Joined

  • Last visited

Posts posted by shorter

  1. 39 minutes ago, Christiaan said:

     

    Sure, but consider the problems I've identified. These are not in that category:

    1. Data Tags don't work in WGR files, so we can't tag windows in elevation views of the model.
    2. Adjustments can be made to gridlines in the Annotations layer of viewports in WGR files, but those adjustments are wiped out when updating the WGR.
    3. Bugs that have no workarounds, e.g. the foliage tool showing denser foliage in a WGR file compared to the original model file.

    And it's now my understanding that because of the way WGR works (i.e. deleting and replacing data) we can't expect these issues to be fixed with the current technology (at least not to 1 and 2). So perhaps Matt is right, the solution to my problem is to deal with the speed problems with large files. That may happen quicker than overhauling WGRing.

     

    A project I'm working on at the moment weighs in at 2GB if we keep everything in one file (I was working on one last year that would probably be 4GB). But file size is not the problem (in fact it's more space efficient to keep everything in one file); the problem is navigation through layers slows and working with the nav palette and organisation window slows down significantly.

     

    Of course, all tools should work whether referenced or not, and yes, referencing does need an overhaul.  Referencing in VW is different from Mstn, and I am not sure why, but I am pretty sure there are associative objects in Mstn that when you update a reference you don't lose the connection.  Walls and Spaces, for example, would be great in separate files but linked so that when the wall references updated the spaces did automatically.

     

    The biggest issue we see with referencing is resource conflict, and in particular now with styles, invisible resource conflict, like the title block record format.

     

    The fact that we even get resource conflict when referencing a wall from an IFC model, isn't ideal.

     

    Data Tags in Elevation views is an interesting one.  Where are you placing the tag?  Sheet Layer Viewport or Section Viewport in a Design Layer?  Have found that simply identifying the window using it's own tag, is better than a data tag, given all you really need in an elevation is the window number, or do you do something more elaborate?

     

    I would be very worried working in a file that big.  And you use project sharing?  How many people on the team are having to download/upload to that and how often do they do so, and how long does it take to save and commit and then refresh?

     

    I suppose there are two schools of thought.  You either keep it lean, with more, smaller files, or all in one big file.  We prefer the former.  What would you do if you had to rebuild that file?

     

    Our 400,000 sqft BIM is spread over 10 models, weighing in at a total of 600Mb, with no file bigger than 200Mb.  When combined into one model they are 200Mb.

     

     

  2. On 10/11/2021 at 8:40 PM, Christiaan said:

    All the specific problems with WGRing that I've identified above are strictly WGRing problems; they don't have anything to do with PS.

     

    most of the issues we have had with referencing we have 'managed' out of the system and we learn to be less pedantic about the loss of some functionality, which in some instances is just technology for technologies sake since there is often a simpler, and more efficient way of doing things albeit not according to the Vectorworks 'paradigm'.  Argh!  In fact, referencing often brings in other functionality not possible if you don't use it.

     

    if you expect the software to do one thing and that one thing suits you but is not something anyone else would do, is that the software's fault? (and when I say 'you' I mean 'one')

     

    the problem with referencing has often been the lack of understanding of how to use it, and what it is for and what it is good at.

  3. Hello

     

    Whilst we prepare an update to our ISO19650/Uniclass 2015 class libraries, thought you might like a useful tip when using Materials.

     

    Materials can be tagged with Uniclass 2015 classification and description.

     

    Out of the box, Vectorworks ships with whichever version of the Uniclass Pr table was current at the time, so you have to update it yourselves.

     

    To do this, either:

     

    Add the latest table to your Workgroup folder (good if working in a larger office) (We suggest adding Pr and Ss tables)

     

    or

     

    Add the latest tables to your workstation.

     

    The Uniclass classification tables live the 'Libraries/Defaults/Classifications' folder in the Applications folder on a Mac, or equivalent location on a PC, or workgroup folder location.

     

    e.g.

     

    /Applications/Vectorworks 2021/Libraries/Defaults/Classifications

     

    or

     

    /Workgroup/Vectorworks/2021/Libraries/Defaults/Classifications

     

    To add the latest table, download the XLS file from the Uniclass 2015 website, and save as a csv file, ensuring the formatting matches the existing Pr csv file shipped with Vectorworks.

     

    931570139_Screenshot2021-10-11at19_00_29.thumb.png.aa1327ad2fa560dbb53260537e068f51.png

     

    The tables should then be available when you click the 'Lookup' button in the 'Define Material' dialog.

     

    The latest Uniclass tables can be found here https://www.thenbs.com/our-tools/uniclass-2015

     

    Regards

     

    Steven

    • Like 1
  4. I have often thought that a fresh approach is needed since there are issues with both protocols, although we have few with referencing that mean we haven’t needed to use project sharing, and from what you’re saying the mixture of the two looks like a bit of a disaster.


    I have often thought that it would be interesting to see a software work on the basis of a finder within the software itself.

     

    I imagined it would work by defining a directory (much in the same way you define a file in PS) that contains many files and these files would appear in a directory tree within a dialogue within the software that would allow you to reference or work on any file in that tree and the software would

    automatically lock the file or treat it as a shared file without the need to announce it as such if you needed to work on it. It would probably need to be backed up by some sort of server application but by defining the directory as the ‘shared’ dataset all referencing and sharing of files would happen automatically without the current system of linking or working in individual files.

     

    large files which are far more common in PS are counter-productive. We prefer to keep files small and referencing is great for this.

     

    however, if I could simply click on a file to reference it within a defined data set in the same way I might show a layer…, or right click to open it and have it automatically become a file that is shared and can be worked on by many…

     

  5. if you view a model from the north and then from the south you will notice the elevation view will move along the x axis left or right in the elevation view.

     

    this is because of the relationship the model has to the z axis.

     

    change the direction of the section line and the section view will move. Keep the section line looking in the same direction and it shouldn’t.

  6. When we reference two files together most of the content and settings of the other file are imported, such as layers, sheets, layer elevation, layer wall height, along with geometry and data attached to geometry.

     

    However there are some critical omissions.

     

    Georeferencing

    User Origin

    Storeys

    Storey Levels

    Zone Parameters

    IFC export settings

     

    These are not transfered and, unfortunately, not only are they the most critical also the most tie consuming to set up.


    Wish: For there to be a model setup command where we can import settings from another file or when we reference another file to be able to import some or all of these settings.

    • Like 3
  7. Currently it is a very manual process to add custom property sets to IfcZones.

     

    Admitedly it does not happen every day but when it does, it is a pain.

     

    We have 9 floors, and 6 units, each of which requires it's own IfcZone.

     

    It would be a lot easier if we could select multiple zones and edit en masse or even duplicate an existing zone that already has the property set defined.

     

    Thanks.

    • Like 1
  8. This only helps finding the offending object. 

     

    You cannot delete the items because you have multiple items selected, so you end up deleting all selected. 

     

    It would be useful to have a 'Delete' button in the Object Info Palette to be able to delete the object selected this way.

    • Like 3
  9. You can also use custom selection to find similar objects, when there are objects that fail to purge.

     

    Once selected use the buttons in the top right of the object info palette to find the object you want to delete, and then delete it

     

    1282564378_Screenshot2021-09-29at09_37_50.thumb.png.a3e54c9d5831ba4fc399d6621f0bba90.png

     

    or

     

    create a worksheet and list all objects you are searching for, by layer and class, and when listed right click on row and ‘select item’ to locate the object in the file.

     

    61300695_Screenshot2021-09-29at09_40_39.thumb.png.f2d0d19a5e00bf42fc2d18e6afae2551.png

     

    However it is not unusual for objects to appear in the list of objects in custom selection yet but failed to register in the file, i.e. the object appears in the list, but when selected shows '0' objects in the file.

     

    This often happens after importing DWG.

    • Like 4
  10. I would concur with @jeff prince and @zoomer importing RVT will not give you the results you desire.  Only by building a model in VW, natively, will it work as you want.

     

    RVT and IFC import are merely coordination tools.  No more.  Always model natively.

     

    Use the IFC or DWG from RVT as a guide.  Forget RVT import.  It only registers project coordinates anyway.  You also get classes with DWG and IFC.

     

    That said this only really relates to parametric modelling. 

     

    We have had some fantastic results importing Rhino data, but that's because it's NURBS-based which, of course, Revit isn't.

  11. Hello

     

    We are looking for a German-speaking BIM Coordinator.

     

    Experience with Vectorworks would be beneficial, particularly the localised version, and also a good knowledge of Solibri Office.

     

    Send me a pm or email cv@stevenshorter.com

     

    Danke.

     

    Regards

     

    Steven

    • Like 1
  12. My first question is ‘what do you need the data in the DWG for?’ This would then give me an idea about how best to import it. What are you expecting to see in the DWG? Is it 2d or 3D? Metres or Inches? Do you have an existing user origin you need to align to? Is the data supposed to contain georeferenced data? Etc, etc.

     

    import DWG is a fine art and not one you can simply click ‘ok’ to and hope for the best.

    • Like 1
  13. Yes and no. We don’t advise using scales symbols so generally issues do not arise and when we receive DWGs with scaled blocks, we explode them since we have had issues with referencing scaled symbols previously and because they can so easily become true size again and no one os any the wiser.

     

    so in a perfect world we have no scaled symbols. We even have a script that looks for scaled symbols and explodes them!

     

    Revit is a huge problem when it comes to symbols but strangely there are never any scaled symbols.

×
×
  • Create New...