Jump to content

Josh Loy

Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited


101 Spectacular

Personal Information

  • Location
    United States

Recent Profile Visitors

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

  1. @Christiaan I'm not sure why we've never had an Unshaded Polygon No Lines option (probably some historical reason) and it seems like it would be pretty easy to add one moving forward. When you talk about efficiency are you mostly talking about update time or file size? Does it ever matter that RW and Shaded(OpenGL) create raster images whilst the Polygon modes create polygons? I guess I'm just asking if the images ever get in the way and if users just want only geometry. We might be able to get the desired effect by adding a unshaded option to RW and/or Shaded(OpenGL.) All of this said it would probably be easy to add an Unshaded Polygon No Lines if that would be helpful to users. The polygon modes have definitely received the least amount of love as we've been focusing on the others and I'll definitely look into your polygon performance concerns.
  2. @Florin please feel free to direct message me with any questions or if you can share the file. It's a little difficult to say from the image but do you only see the issue while zooming/panning or is it visible all of the time? My guess, if it's visible all of the time, there is a corrupted object like a space object or a polygon; going through the file and hiding objects or layers may help narrow down a problematic object. If it's only visible while panning and zooming it might be a total object count issue, importing things like the cars may import as a group of lots of little lines instead of just a couple polygons. The Compose command with a bunch of lines selected should convert them to less polygons and help reduce the total object count. Let me know if this helps.
  3. @HewnSmith Please verify that "Snap to Working Plane" is disabled. If that's not a factor could you attach a VWX file or short video so we can reproduce the problem?
  4. This is a know issues and should be addressed in SP2. The algorithm for draw edges depends on both the model bounds and the precision allowed in the hardware, the rendering team has tightened it down which should remove these artifacts.
  5. Much appreciated, we'd thought about having "Fit to Page" and "Fit to Objects" apply to all panes when double clicked or to just add more buttons; but waited to see if there would be a large demand before adding more complexity to the UI. As you know we're always trying to find the sweet spot for the best user experience between complexity and usability. Yes, so that when you move your mouse up to the "Fit to Page Area" button in the View Bar for example, you know that the pane B will have its view changed (and not pane A which you accidentally moved your mouse through on the way up to the button.) The mouse can be anywhere and will definitely not be in the drawing window or a view pane when clicking on buttons, drop downs, or menu commands, so we both have to know where the command will and should happen and the selected highlighted pane seems like the best compromise. Clicking and scroll wheeling of the mouse are very cursor position driven events, you place the cursor over objects in the drawing to selecting and zooming so we know to change the view pane selection at that point. The Spacemouse is independent of the mouse cursor so when you manipulate the puck, the only way we know which view you want to manipulate is by manipulating the currently highlighted a view pane. This is one of those things that we could change the view pane selection when the Spacemouse is manipulated and the mouse cursor is over a view pane but that will confuse a whole different set of users. I hope I explained this well and please feel free to DM me if you have any additional questions.
  6. Thanks @line-weight I've reached out to the Platforms team here a Vectorworks to see what kind of options we have for the floating view panes moving forward. I believe they modeled floating view panes to work like pallets. One so they would always float over the drawing window and not get lost behind it and second so they wouldn't clutter up the monitor when Vectorworks wasn't being used. We're always trying to find the most optimal solution and in this case it seems like we need to add the ability to "pin" floating view panes so they don't automatically hide.
  7. @line-weight we did struggle with that on the initial design. It was really the shared user interface elements that required clicking on and blue highlighting the selected pane. For instance changing the class in the Navigation Pallet, which pane would realize the change? All of the viewbar controls also require "selecting" a pane. To account for all of this we decided we needed the concept of a selected pane and an active pane. The shared menu commands (view changes, visibility changes, modification commands, keyboard shortcuts, etc.) apply to the selected pane, whilst mouse commands like wheel zooms and context menus go to the active pane. All of that said I'm sure there are cases where we're using the wrong one and if you notice them, please let me know.
  8. @Tobias Kern, @Mark Aceto thanks for the great feedback. If you're not happy with the default 4 view in new documents, you can lay it out as you'd like and save a new default template document. I'm not sure how obvious it is but Saved Views are currently apply to the selected pane (blue highlighted one), so creating Saved Views with the visibility options disabled, for each pane, could be used to speed up setting up the layout. (But it's still a little bit of work since you have to select each one and apply) But it sounds like Tobias wants to lock the view for a particular view pane so it can't be changed, do you think adding a "Lock View" or "Disable View Changes" menu checkbox (placed near the "Use Same Visibilities in All Panes" checkbox) which would disable all view changes in that selected pane would satisfy? I would also think adding an indication that the view is lock in a particular pane would be necessary as well. We did design a Multiple View Pane Manager but omitted it with the original task to simplify the User Interface. If you find the current controls too limiting we can definitely look into adding that kind of functionality. Thanks again!
  9. 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.
  10. 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.
  11. @Mark Aceto After I posted I realized I forgot the "no" and added it, sorry for the confusion.
  12. @_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.
  13. @_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.
  14. @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.
  15. 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.
  • Create New...