New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More feedback on the offending object from SvgSerializer errors #4500
Comments
Can you please send some example triggering "RuntimeError: An unknown error occurred"? Got some idea for a script that will help narrowing it down. |
Yes, try and run The offending object is called out below... |
I haven't found a fast way to reliably pick up the source of the error. I have a hacky script which slowly culls elements until it finds a broken combination. |
Turned out syncing process takes too much time on large projects, so we can speed up the printing process by syncing just once. Also exposed option not to sync to operator's properties to allow debugging failing elements. A bit related to #4500
Operator can help narrow down failing elements when drawing is failing with "RuntimeError: An unknown error occurred". it's located in debug section - https://i.imgur.com/b03jmkZ.png The output is noisy but the results are highlighted: https://i.imgur.com/0ZA0u60.png https://i.imgur.com/oXzqIXU.png https://i.imgur.com/Y0nMRMz.png
I added some debug operator that can help. in 797e2e4 Making it I've learned that in large projects we actually have a bottle neck in syncing elements before drawing creating. In my case creating 1 drawing took ~25 secs and ~20 secs of them was syncing objects. Syncing iterates over all available blender objects, so it's expensive on large projects. Since all objects are synced already after first run, there is no point syncing them again for each drawing if printing multiple drawings at once, so printing multiple drawings should get faster after 5c36599. But still need to do something about that syncing process to optimize is. The syncing method is
and the most expensive part is running |
I thought it could be useful in some cases. When operator couldn't narrow down the set of elements any further it ends up with 2 elements that are failing - drawing any of them just by themselves doesn't produce errors but drawing them together produces an error:
So it could be either one of them is failing or both of them or combination of them (they fail only when they are both present).
But knowing that excluding some of the elements that fail together doesn't fix the issue could also be useful - in cases when they are both failing / failing when they are present together.
Full output from operator without noise:
|
Nice, clever bit of programming going on here! |
Is there something I can look into here? |
@aothms This one is resolved in the current build 👍 |
To speed up the drawing process in large projects and reduce time on syncing stage I've found that if object is already assigned to it's parent collection (both as part of blender collection and in IFC) we can skip assigning stage significantly reducing time on syncing in general (from 20-25 secs -> 9 secs). The only thing we'll be missing in that case that object won't be unlinked from other unrelated blender collections which shouldn't break anything in the case of drawing generation.
also fixed the issue with mixed up results at the end of the operator execution
Turned out syncing process takes too much time on large projects, so we can speed up the printing process by syncing just once. Also exposed option not to sync to operator's properties to allow debugging failing elements. A bit related to #4500
Operator can help narrow down failing elements when drawing is failing with "RuntimeError: An unknown error occurred". it's located in debug section - https://i.imgur.com/b03jmkZ.png The output is noisy but the results are highlighted: https://i.imgur.com/0ZA0u60.png https://i.imgur.com/oXzqIXU.png https://i.imgur.com/Y0nMRMz.png
To speed up the drawing process in large projects and reduce time on syncing stage I've found that if object is already assigned to it's parent collection (both as part of blender collection and in IFC) we can skip assigning stage significantly reducing time on syncing in general (from 20-25 secs -> 9 secs). The only thing we'll be missing in that case that object won't be unlinked from other unrelated blender collections which shouldn't break anything in the case of drawing generation.
also fixed the issue with mixed up results at the end of the operator execution
Thankful for this functionality. |
I get the following error quite a bit when running drawings.
To troubleshoot, i move the camera around until i don't get the error, and then move the camera incrementally back, until i get the error again. I then deduce which geometry might be causing the problem.
This takes quite a long time, to troubleshot.
Am wondering, if there could be an output of some kind that tells you which objects are causing the error, so you can dial into them quickly and fix them, if possible.
The text was updated successfully, but these errors were encountered: