Jump to content

Josh Loy

Vectorworks, Inc Employee
  • Posts

    215
  • Joined

  • Last visited

Reputation

118 Spectacular

Personal Information

  • Location
    United States

Recent Profile Visitors

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

  1. @MaltbyDesign the by-class fill style of "image" on the "Millwork-Main" class is causing the extrude to become transparent. VW does not normally allow extrudes to take an image fill and applying via class override was missed. This will be fixed in the VW2022 SP4 release, thanks again for pointing this out.
  2. @Andy Broomell Just so we're clear, the shaded/opaque move preview is not being changed; just the bug that caused groups to incorrectly use their bounding box has been fixed. Let me know if moving anything else causes an issue and if you think a way to revert back to the old wireframe preview is necessary. Thanks!
  3. This should be fixed in the upcoming VW2022 SP4. In the meantime, pressing the 'b' key while dragging the group will activate x-ray mode, working around the problem until SP4 is released.
  4. @Daniel M71 Have Vectorworks Tech Support been able to help you resolve this issue? Do make sure you get the driver directly from NVIDIA, in the past we have seen problems with vender versions of graphic drivers like Microsoft, Dell, PNY, etc. it's better to get them straight from the manufacturer if possible. https://www.nvidia.com/Download/driverResults.aspx/186958/en-us
  5. Hey all, great conversation! If I understand correctly the issue is if I draw planar objects in top, copy them, and them paste them in a front view I only see a sliver because they're pasting to a plane parallel to the layer plane. Screen plane didn't have this problem since those objects are always perpendicular to the view. The "Screen Aligned Plane" is active in front, back, left, and right views even when modifying components; if we modified the paste code to switch layer plane objects to use the screen aligned plane instead would that address the issue? Thanks again for all of your feedback and suggestions, screen plane shouldn't be a workaround. 🙂
  6. @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.
  7. @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.
  8. @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?
  9. 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.
  10. 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.
  11. 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.
  12. @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.
  13. @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!
  14. 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.
  15. 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.
×
×
  • Create New...