Josh Loy

@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.

@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?

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.

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.

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.

@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.

@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!

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.

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.

@Mark Aceto After I posted I realized I forgot the "no" and added it, sorry for the confusion.

@_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.

@_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.

@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.

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.

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

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?

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.

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

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.

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

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