Jump to content

Josh Loy

Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited

Everything posted by Josh Loy

  1. Sounds good, we'll add an enhancement request for that. With the eyedropper and color export we didn't see a need for this, Apple may not offer an API for it either, I'd need to check. We'll also add an enhancement request for this. That's a bit subjective but was chosen to save palette space. The new "Standard Vectorworks Colors" now have primary colors, I asked our content team about the order... The far left column is the pure hue of the color family and is based on HSV color theory which uses a full 360° circle to cover the pure hue spectrum using digital color mixing so the standard RGB that monitors use as opposed to the Red, Yellow, Blue of pigments. Each hue is 15° of arc on the circle starting at pure red which is 0° going all the way around to 345° which is why there are 24 hue families. Once the pure hue was established to create a color family row we then created the three color scales for that family. Starting at the pure hue and working across the row there are 5 tints using a 12% scale that goes towards a pure white. Essentially the Saturation decreases which is the equivalent of adding white to the pure pigment. The second column is the tone scale with 5 tones and it is the same 12% and this alters the saturation and value which is just like adding grey to the pure hue. The final 5 colors are the shades and this uses the same 12% scale which decreases the value which is the same as adding black to the pure color. We chose the pure hue and groups of 5 because we were limited by code to a fixed width of 16 colors and that was the easiest breakdown. Also remember that this palette was designed using scientific color theory to give a good base group of colors and to include pure yellow and a better separation of the greys and very dark colors which were the issues with the old color palette which is still included. https://en.wikipedia.org/wiki/Grid_illusion This is subjective and we tried to find the color that best contrasts the selection and doesn't get lost in the grid. Again, Apple uses a non-standard CMYK formula in their color palette which has resulted in inconsistent colors since we introduced CMYK a long ago, we have no way of working around it. Pick a color and go through the different sliders and you'll notice the values change from what you initially selected (the API only returns RGB). Sometimes the conversion gives different rounding results. In this video I was trying to modify the MacOS cursor color in the system settings... CursorColorPicker.mov
  2. Hey Christiaan, thanks for great feedback and pointing this out. We initially thought the color spectrum would be used in this case but I can definitely see the benefit of anticipating the color with the preview in the slider. With the eyedropper and document colors we didn't think this would be worth bringing along. Unfortunately Apple's color picker has a very limited API and we are no longer able to work around its issues. This is why most, if not all, professional graphic programs will create their own color picker. If you've ever tried to use CMYK with Apple's color picker you'll quickly realize something isn't quite right, because Apple has their own CMYK format which no one else uses and no one can correct. Windows' color picker, need I say more?
  3. @GarrettBurleson thanks for pointing this out and I'm unfortunately not able to reproduce the problem you describe. Just a couple of question and feel free to DM me; is this happening on Mac or Windows? If you reset the key mappings or choose a different workspace does that help?
  4. @Mike Wood this sounds like a bug but I was not able to reproduce it with the steps you mentioned. Would you mind sending me the file that shows the issue? Very much appreciated and thanks for pointing this out.
  5. @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.
  6. @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!
  7. 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.
  8. @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
  9. 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. 🙂
  10. @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.
  11. @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.
  12. @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?
  13. 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.
  14. 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.
  15. 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.
  16. @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.
  17. @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!
  18. 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.
  19. 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.
  20. @Mark Aceto After I posted I realized I forgot the "no" and added it, sorry for the confusion.
  21. @_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.
  22. @_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.
  23. @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.
  24. 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.
  25. 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
  • Create New...