Jump to content

JMR

Member
  • Content Count

    327
  • Joined

  • Last visited

Community Reputation

113 Spectacular

About JMR

  • Rank
    Journeyman

Personal Information

  • Occupation
    Architect
  • Hobbies
    Science, boats
  • Location
    Finland

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. JMR

    Vectorworks is REALLY SLOW lately!

    @Janvin Lowe We are running a PC-based WV office. Unfortunately, we face speed issues as well. Our machines are mostly i7700K @ 4.2GHz with Quadros and 1050Ti's. While some Mac-based users have reported some weird issues with Mojave, I don't think you'd see any significant performance increase in shifting to PCs. Currently hardware is not really what is making VW slow. IMHO it is pointless to invest large sums into hardware if that is making only a marginal difference. We have very slow performance with any elevation viewports, even hidden line viewports stripped of everything extra. 2019 is faster than 2018, clearly, but multi-threading somehow seems not be quite there yet: I see CPU utilization from 12.5-25% most of the time, although curiously, with the slow viewports it seems to be multi-threading more intensely, at 84%. I have an old 2012 Dell T3600 with a Xeon E5 1620 @ 3.5GHz at home; I started wondering why it seems to run 2019 practically at the same swiftness or slowness as the newer machines at the office. One reason could be the single-core performance speed, which hasn't increased so much. The number of cores have, instead. If you look at this benchmark chart, you can see that a high-end i9900 is only about 1.5 times faster than an old Pentium Gold, if comparing single-core performance: https://www.cpubenchmark.net/singleThread.html So it would seem that complete multi-threading combined with streamlining the code would be the answer. Maybe the tech people at VW can chime in with better knowledge on this. I'm seeing only about 25% CPU usage while doing everyday work. Maybe there is more to this than that though, but it would seem the program is not using that many cores, most of the time.
  2. I think Archicad has this capability, a video back from 2013: Something like this with the ability to lista data beneath the windows would be great indeed. What we do currently; we generate a simple front elevation from each window type, and then have all the dimensions and other data in a pretty massive worksheet. In the elevation sheet there is as little information as possible. This works well enough, but doesn't work for complex system windows, as mentioned previously, only for simple windows that one is able to generate in 3D with the VW window tool (we don't/can't have Windoor!! #¤%!).
  3. The workaround worked perfect! I was not able to set the text exactly to zero, but 0.01 was possible (nothing visible, practically). It's also possible to set the font color to white. Phew. Thanks. In the process it also came to my attention by accident that the revision number(letter) can be automatically attached to the published file name, great!
  4. Oh no...I see. We heavily use identifier data with the title block to eg. separate different drawing types for scheduling, preliminary, draft and construction. This identifier data is not linked to any visible text. We also use a data field to quickly mark changes for a housekeeping worksheet - this data is not linked to title block text either. I wonder if it's better to go back to our old custom title block, which is just a symbol...the title blockey things seem to be changing so often that our office quality system breaks down constantly...the title blocks are a "tread very, very carefully" area for an architect's practice! 🙂 Would it not be possible to be able to access non-linked data via the dialog? It's cumbersome to find the right sheet in the title block manager, much easier to click on the sheet title block and edit there. Someone's suggestion about being able to choose what is shown in the dialog is well founded. We too get confused with "forced" display of some data headers that don't match the local standards, and then also this issue of not being anymore able to edit the non-linked data. Thanks
  5. Hi all, I've ran into a little problem with title blocks: We use customized data with the title blocks. Works fine, no problem there. However, I think since 2019, when I go to the title block "sheet data" pane, I can't see all of my data. Please see attached. The data is there, but it won't show up in the dialog no matter how much I stretch the window. I can access and edit the data via a custom worksheet, but the data should be accessible here as well, no? It would seem as if after ~20 fields the rest are not displayed at all. Thanks
  6. JMR

    Revit Import

    Come to think of it, is there an application that imports Revit models properly? By someone else than Autodesk? IFC is the model-checking/interchange format, in architecture at least.
  7. JMR

    Revit Import

    The only Revit imports we've been successful with are files containing only a model of some piece of furniture. Even then it's like a coin toss whether it works or not. Currently, the Revit import feature does not work, from a professional's point of view. It's completely useless for a whole building.
  8. JMR

    Workflow for large projects

    We are only on a local NAS, it's probably very different with a cloud, as you say. On this setup we don't notice any lags, it's just like working on an ordinary .vwx file after having answered the first prompt. Thinking of all the multitude of issues we had, I'm rather surprised it has worked so much better now.
  9. JMR

    Workflow for large projects

    One thing we have noticed about project sharing is that it works much faster/better if we don't check out complete DL's, just objects on the fly with the "check out automatically" option checked when prompted. Then releasing the objects via "Custom release" by simply pressing ok. This has greatly reduces save/commit times and crashes.
  10. JMR

    Large Cumbersome PDF files

    If it is there, it's probably here:
  11. JMR

    Large Cumbersome PDF files

    One thing to check is the pdf export type setting, whether it is set to pdf or pdf/a. I've noticed that pdf/a drawings inflate to 45MB, while an ordinary pdf will be about 4MB. All this without any rasterizing, just vectors. Notable is, that if I convert the "normal" 4MB pdf to pdf/a using Nitro Pro, the same ballooning of size occurs. So it might not be particular to VW. Unfortunately the council demands pdf/a format, then the only option is to rasterize, which can get us to 15MB at 300dpi.
  12. JMR

    Polyline Lag, clip cube not working

    Not on a Mac myself, but this seems somewhat similar:
  13. JMR

    Sudden Blue Background

    We have seen this same phenomenon, but only a couple of times and the problem has not persisted so far (restarting helped). We run PC's with 1050Ti GPU's.
  14. JMR

    version 2019 quits without warning

    We frequently encounter this while committing and refreshing a 2019 SP2 project sharing file. It seems to have something to do with viewport operations. Sometimes the crash occurs also while working on a viewport as such, particularly interior elevations. We run PC workstations.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×