Jump to content

Josh Loy

Vectorworks, Inc Employee
  • Content Count

  • Joined

  • Last visited

Community Reputation

49 Great

About Josh Loy

  • Rank

Personal Information

  • Location
    United States

Recent Profile Visitors

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

  1. Simple answer yes, both platforms have the core limit lifted and see performance improvements. Longer answer and staying devoid of any personal platform affinity; Windows does fare better due to better performance in its low level threading functions.
  2. Hey @Mark Aceto thanks for the feedback, I not exactly sure where you're going with this but any speedup for drafting/modeling/rendering seems like a win to me. This system is independent of Project Sharing and will have no impact on its performance. I wouldn't say anything has plateaued or that there are any lines to read between. We support a vast set of hardware and must provide support for a broad range of workflows while always providing the best experience. The more tasks we can multi-thread and multi-task the better. Awesome and I'm sure most users fall into this same category, the performance gains will absolutely help your large model workflows while working in wireframe and OpenGL. I would also agree and recommend higher clock speeds over core counts as long as you have at least 6 cores; I'm also on the Mac. It will use more storage 10 to 30% that I've seen up to this point, and if that's an issue for your broadband it can be easily disable just like "Viewport cache." I wouldn't make any choices or pass judgement until you try it and are happily surprised. 🙂 Some of this logic isn't quite correct. As clock speed increases the power demand isn't linear, meaning the same 'n' amount of work can be done on 4 cores at lower clock speeds in the same amount of time and using less power than a high clocked processor. Base clock speeds are pretty useless as the system will ramp up and down the clock speed depending on demand. You'd probably be better served looking at the single and multi-core turbo speeds since they're generally the limiting factor and usually not far apart. If you want to get really into it TDP will generally dictate the performance you'll see since cores can run at different speeds and in the end heat limits it all. Feel free to direct message me if you want to talk about this more or have any additional questions.
  3. @Mark Aceto After I posted I realized I forgot the "no" and added it, sorry for the confusion.
  4. @_James Renderworks has and will continue to use all available cores while rendering but I believe it is capped at 16. @Mark Aceto there is a little catch to file size because we needed to save some additional data to help with the threads efficiency. Our primary focus for VW2021 was improving the performance getting graphics data to the renderers and have seen great speedups switching layers and visibilities when in 3D views. All of this said we're always working to improve performance and have more gains to come in future versions. @Samuel Derenboim no improvements with hidden line this release but I wouldn't be surprised if it was next on the list.
  5. @_James Vectorworks had a core limit in the past which would throttle down tessellation to only use 3 cores; with Vectorworks 2021 it will use the available number of cores in your system.
  6. @milezee It's nerd speak and unfortunately prevents us from drawing small objects up close 😂; we want to fix it and will look at fixing it, but targeting a service pack may be a little aggressive.
  7. Perspective has an eye location with a near and far clipping plane, sometimes the near plane (projection plane always in front of the eye) intersects the model causing the clipping artifacts. Orthogonal projection has no eye position, it only has a viewing direction so the near and far planes can be set extremely far from the model bounds. It sounds like you're getting into an edge case with your perspective and running out of precision; we should be able to fix it or work around it. Just so you know OpenGL generally uses 32bit floats while the model is stored in 64bit floats requiring us to work with different spaces.
  8. Hey @SLFYSean, Thanks for the note and sorry for the disruption. Well our intention with the B&W only change was to fix an old bug and make the software more consistent. Unfortunately, we overlooked this particular workflow not realizing the wrong behavior was needed to pull off the effect. We’re currently looking at restoring the previous behavior until we can come up with a way to fix both bugs which would probably require some UI changes. Your other point about the multi-selection in the list browser is also being looked at and I’d assume it should also be fixed shortly. Thanks again, Josh
  9. Hey @lupin, sorry you're having issues with the line weights. A quick workaround would be to overlay a Top/Plan viewport with the property boundary visible over your existing viewport. We're constantly trying to make all these workflows as smooth as possible, can I contact you off list to get a better understanding of your requirements?
  10. Ouch. Technically this is possible; Jim was probably just trying to simplify the answer. All of the panes being used must all have the same active layer and all be either 3D views or all be Top Plan views. At this time users will not be able to start a tool in a Top Plan view and then finish that tool in a 3D view. The interactive feedback will also not show in 3D views while the tool is being used in Top Plan or vice versa, however the object created by the tool will show in both if it’s visibilities permit. I hope this helps clarify the multiple pane interaction, please let me know if you have any additional questions.
  11. This is an old known issue and is caused by a difference between computer and print graphics. There is a knowledge base article which at the bottom has a detailed description of the problem and various workarounds. Currently the ?Rasterize Print? option is not available on the Mac but until that becomes available you do have the option to ?Export Image File? then print the image. I hope this helps and please let me know if you have any additional questions or concerns. Knowledge Base Article
  12. You are absolutely right; Vectorwork?s had the ?Hardware Accelerated 2D Navigation? option and it was removed. That option was removed because it didn?t provide consistent results, did not scale well with large models, and sometimes the proxy was so different from the original it became disorientating. OpenGL also needed to be re-tasked to replace the old GDI/QD interactive XOR drawing with the colorful interactive stuff seen today. In doing this we laid the foundation required to move to a full OpenGL environment unifying our 2D and 3D. Currently the model is drawn using GDI+ or Quartz to a memory buffer which is then converted to a texture. This texture and everything else in the drawing window are imaged using OpenGL. Our goal here is to be efficient and effective it was decided that it would be better to initially drop the ?Hardware Accelerated 2D Navigation? and build it back into the interactive framework then trying to build an interactive framework from it. I assure you this was not meant to be malicious or haphazard but an unfortunate side effect of modernization. I hope this helps explain the reasoning and if you have any more questions or concerns please let me know.
  13. Vectorworks 2009 and 2010 utilize the graphics card for both user interaction and OpenGL rendered mode. While Vectorworks is not designed to directly take advantage of SLI or Crossfire it may indirectly benefit when working on large monitors or with complex OpenGL models. See the following Knowledgebase article for a more in-depth discussion of video card considerations: Video Graphic Card Guidelines for Vectorworks - 9/15/2009
  14. This statement is generally true. Large monitors require more VRAM and I would recommend at least 512 MB VRAM for a 30?. I would stress making sure you have enough video memory because once you run out thrashing happens and that will kill performance. See the following Knowledgebase article for a more in-depth discussion of video card considerations: http://kbase.vectorworks.net/questions/714/Video+Graphic+Card+Guidelines+for+Vectorworks+-+9%7B47%7D15%7B47%7D2009 Josh Loy Engineer Nemetschek NA


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.

  • Create New...