Jump to content

Tim C.

Vectorworks, Inc Employee
  • Posts

    115
  • Joined

  • Last visited

Everything posted by Tim C.

  1. @rjtiedeman did you ever try just replacing the Line with a thin poly in 2020? That seems to be the easiest workaround. -Go into the Sweep -Activate the Offset tool with a really small offset distance and the "Close Open Curves" tool pref enabled -Offset the Line and give it a solid fill The texture should then show on the Sweep and it should have the same mapping as 2019.
  2. @archdaly are you using VW 2019 or VW 2020? Some of these problems still exist in later versions of VW 2019, but this should be fixed in VW 2020. Did you ever try the un-docking and re-docking of the OIP? This usually fixes the problem for the rest of the session. Hope this helps, Tim
  3. @rjtiedeman yes this looks like the problem that Andy mentions above, where Line objects aren't supporting a fill in 2020 and that's spilling over to any solids (Extrudes, Sweeps, etc) that are made from the Line. This is already fixed in a newer service pack but for now you'll just want to replace that line with a thin polygon and the fill should then show. Sorry for the inconvenience. Tim
  4. @sixthflick thanks, I'll pass this info on to the engineering team that's looking at this.
  5. @sixthflick can you try something on your end which will help us diagnose the problem? -Launch the Console app (in Applications/Utilities) -In VW, select the Callout or do whatever operation is causing the lag -While the lag is occurring, look in the Console app and note what messages are showing Do you see lots of consecutive messages that say "EXCEPTION" or something along those lines? If so, this looks like the same Mojave problem we've been running into. From my understanding, Apple made a change to how exceptions are handled in 10.14, and this causes issues with our Object Info Palette. The problem seems to be much-improved in SP3 due to some changes we made, but we're finding that it still happens for some users in certain cases. If this is the problem you're seeing, un-docking and re-docking the Object Info Palette will typically fix the problem for the rest of the session. If this isn't the problem you're seeing, the next step would be to get a sample of the slowdown. This can be done through the Activity Monitor application. While the lag is occurring, highlight the VW 2019 app in Activity Monitor and choose "Sample Process" from the utility menu at the top. This will create a Sample file that we can look at on our end. Thanks for your help!
  6. @Kevin McAllister would it be possible to PM me the file so we can take a closer look?
  7. @bjoerka next time you see this can you check the RAM usage and see if you're maxing out your RAM when the slowdown occurs? Once the RAM gets used up your machine will start offloading data to the hard drive or SSD, which can really slow things down. On Mac you can check the RAM usage through the Activity Monitor, and on Windows you can do it through the Task Manager. Best Regards, Tim
  8. Good to hear!! We're working on a fix for this so that you can keep the OIP docked, but this should help out a lot in the meantime. Let us know if you still see any problems.
  9. @Alan.AHA are you using Mojave (10.14) on Mac? If so, can you try undocking the OIP and see if that helps at all? Best Regards, Tim
  10. @912345678 it looks like we have other reports of this problem and are working on a fix, but I'd like to add your example if you wouldn't mind messaging me a copy of the file? From what I'm seeing the problem is worse if you update the viewports and then edit the Annotations. So one workaround might be to get the viewports in an updated state, then save/close/reopen the file, and then edit the VP Annotations. I'm not sure how much it'll help, but it might be the best approach until we can get this fixed. Best Regards, Tim
  11. @Brittany I'm thinking this has something to do with using page-based units (for either the Hatch or the symbol itself), but it's hard to be sure without seeing the file. It's been awhile since you posted this but if you're still looking for a solution please message me a file containing the 2D objects that are being converted to symbols. Best Regards, Tim
  12. @Jeremy Best @mjm we're looking into this bug, but you should be able to cancel the RW render by changing the active render mode. For example if you just choose Wireframe from the rendering menu, the RW render should stop immediately. HTH
  13. @Alan.AHA as you experience the slowdown can you create a sample file from the Activity Monitor? This will give our engineers something to look at so we can investigate. It should take less than a minute: -Launch the Activity Monitor -While the slowdown is occurring in VW, highlight the Vectorworks 2019 app in the Activity Monitor and choose "Sample Process" from the pull-down menu at the top -This will generate a text file that you can save and upload Thanks for your help! Tim
  14. @Asemblance we're looking into this now and will get back to you asap. Best Regards, Tim
  15. @twaikin Thanks for the info, I've submitted bug reports for both issues. Best Regards, Tim
  16. @Liene Cikanovica just to confirm, are you saying that you choose "Cancel" in the first dialog that appears (when you open the file in 2019), and VW still converts it to 2019 format? I'm not seeing this on my end so I just wanted to be sure I understand the issue. When the conversion occurs the 2018 file should get placed in its own folder (in the same directory as the original file) named "Old Version Vectorworks Files", so that you still have access to it. Are you not seeing the 2018 file get moved to this folder?
  17. @K MAC would you mind messaging me a copy of the file so we can take a closer look? Thanks!
  18. @Christiaan I don't think there's any magical fix for this. This is just a suggestion but you could put a corresponding Bitmap in the viewport's Annotations, so that it overlaps the Image Prop. -Extract the image from the prop texture -Enter the viewport's annotations -Import the image as a transparent Bitmap -Move/resize it so that it overlaps the original prop It's not ideal, but you'll still get the shadows cast by the original prop while getting rid of the unwanted lines. Hope this helps, Tim
  19. @line-weight from my testing it looks like holding down Shift during a resize has always constrained the operation to the line's current angle (tested back to VW 2010). If you have the "Snap to Angle" constraint enabled you can snap to the 30/45/90 angles without pressing the Shift key, though. If you're using the Reshape tool on a poly segment you'll get constrained to 30/45/90 angles while holding Shift, but the resize feature seems to work a bit differently than Reshape. Hope this helps, Tim
  20. @Sam Lee you could probably get away with just one symbol by using design layer Viewports and class visibilities, though the workflow is a bit unusual: -Create one symbol that includes all the different variations for the downlight, and place the variations in their own classes within the symbol -Place the symbol on its own design layer -Create a design layer Viewport that shows only that layer -Use the viewport's Class visibilities to control which of the downlight variations you want that instance to show -Duplicate the viewport and change the visibilities as needed for other configurations This seems to work pretty well in my testing, though it might not be for everyone. Other than that, the only way to really do this is with lots of different symbols (as Mark said).
  21. @mbft just a heads-up this should be fixed in SP2, so if you're still seeing problems please let us know.
  22. @Jackson99 Good to hear! If you happen across it again please let us know. Thanks!
  23. @lgoodkind I looked through our database of known bugs and didn't see anything along these lines, so we definitely need to look into this. Would you mind messaging me a copy of one of the VW files where you're seeing the problem? Thanks for your help!
  24. @Jim Smith much thanks, Jim. I do see the problem with the Bitmap (in the Notes-Stamp class) not showing in the VP and I've submitted a bug report to our engineers. I wasn't able to duplicate the other issue (where the "EX RM 1" symbol wasn't showing in the VP), but since the problem resolved itself I'm guessing it was related to graphics caching (always tricky to troubleshoot). We'll definitely keep a close eye on this, and if you see the problem again please let us know. For future reference though you can often fix graphics issues like this just by deleting the object (in this case the viewport) and then Undoing the delete. Thanks again!
  25. @Jim Smith would you mind messaging me a copy of the file so we can take a closer look? I did some tests with a setup similar to what you described but didn't see any problems, so there might be something more specific that's causing the problem. Thanks for your help!
×
×
  • Create New...