FreeCAD|
|
@greyltc I am having a hard time reproducing this -- when you have a minute, could you use the OpenSCAD workbench to insert the following object and then save and attach the resulting FCStd file? |
|
|
I see the same error, built from commit 33cca2e6c6a6ace4b1203a9ad0f9002a6c841e99. Attached the requested FCStd file. |
|
|
Thanks, @floesche -- the object in your FCStd file has the correct bounding box, so probably the test just needs a recompute() before the check. What kind of system are you on? |
|
|
Very similar to @greyltc, just python is at 3.9.3 by now and the kernel at 5.11.15. Do you need any other information? |
|
|
Not sure if this is helpful, but if I step through the test, I see the following:I tried to do a recompute on the doc.ActiveObject, with no result: Let me know if I can test something else. |
|
|
In that FCStd file, when you view it from the top, are you seeing a circle, or an oval? |
|
|
It's a circle from the top, an oval from front. In the "Report view" window I am also seeing the following when creating the OpenSCAD element: |
|
|
…and the attached file is generated directly from the test_import.CSG.py file: I set a breakpoint at line 350 (after doc=self.utility_create_scad…) and the ran |
|
|
I wonder if the active object isn't what the test expects it to be. If you are seeing a circle from the top, then the bounding box being reported can't correspond to that object, since the reported box has different X and Y components. Can you verify that doc.ActiveObject is in fact giving you that spheroid, and not some other object? |
|
|
Sorry, how could I do that? |
|
|
That's what I expect to see. Can you recompute the entire document and see if the bounds changes? |
|
|
Is that how I can recompute a document?In any case, the XLength doesn't seem to be correct. |
|
|
Are you also on Arch, or are using using a different distro? It looks like I'm going to have to find a way of reproducing it locally, there's a disconnect between what you are seeing onscreen (and posting here in your FCStd files) and the reported bounding box, and I can't figure out what that could be. |
|
|
Yes, I am also on Arch. I don't know much about the data structures used in FreeCAD, but I know a bit about coding. So if you have ideas what I can try, I'd be happy to. |
|
|
First, thanks for all the help you've provided so far! Second: to be honest I'm at a bit of a loss about what's going on, but my first order of business will be to add some print statements around the matrix deformation to make sure that at least the values going in and out of it are being calculated correctly. |
|
|
The bounding box seems to originate from the OpenCASCADE transformation. The test code ultimately calls The most fundamental way I could replicate this, was to do the transformation directly in DRAWEXE: This creates the first bounding box: These numbers are basically the same as the test generates. Possibly all this is related to the (non)issue https://tracker.dev.opencascade.org/view.php?id=27042? |
|
|
After playing around with this for a bit, I have a few questions – maybe you can help with the answers? 1) I am guess, that the FreeCAD GUI is doing some additional steps when rendering the OpenSCAD parts. I might be on the wrong track, but is it possible, that OpenSCAD for FreeCAD GUI are converted from Part to Mesh and back to Part via "process3D_ObjectsViaOpenSCADShape" in OpenSCADUtils.py? 2) I am guessing, a similar transformation would defeat the purpose of this test. Alternatively, would a different mapping of "newsize" to another transformation in p_resize_action (importCSG.py L:494) make sense? 3) Is it possible to reproduce the test error or the DRAWEXE script on another system than Arch Linux? Apologies if these questions have obvious answers. Any hints welcome. |
|
|
I think the ci robot isn't even running this test case (maybe why it's been missed?). I just looked at a recent ci log: https://api.travis-ci.org/v3/job/770257561/log.txt and I can't see that OpenSCAD is even installed or configured in that environment. Is this test being run successfully somewhere else that I can look at? |
|
|
In case it's helpful, here's some more verbose output during the test failure on my system. Don't ask me what all the Token warnings or the permissions errors are about. |
|
|
Here is a screenshot of how it goes when I do this manually in the gui. Looks okay I think. |
|
|
attached? EDIT: I can't seem to upload a picture for direct attachment to the issue here. Maybe this works:  |
|
|
In case it wasn't obvious, I've bisected it and this is the commit that creates this issue: https://github.com/FreeCAD/FreeCAD/commit/69f24859b5cc51af788654c86c3438aa6cef11ef |
|
|
But when I do this on the command line via FreeCADCmd, I can see the failure appear clearlySo yes, it seems broken in the terminal and not broken in the GUI. |
|
|
That's very helpful -- I only ever run this test from the GUI (as you noted upthread, Travis doesn't run this test because it doesn't have OpenSCAD installed and currently that is required). I'll try running from the command line later this week and see if I can reproduce locally. |
|
|
Just to confirm: I can reproduce the issue with the example @greyltc provided. |
|
|
I think I have a fix for this, but would appreciate an additional check on my work. Can you edit line 494 of importCSG.py to read |
|
|
Thank you for this suggestion. Sadly for me it doesn't solve the problem.Not surprisingly, if I set a breakpoint right after the changed line and then check the size of the bounding box, it is the wrong size: |
|
|
A suggestion from the forums is to try addingbefore the transform, so it would then read: |
|
|
Just an update that the recompute suggestion does not work. I continue to try tracking this down... |
|
|
Finally tracked this one down to as issue with the way OCCT calculates bounding boxes when a tessellation is not available -- added explicit tessellation before any bounding box calculations in the importer in PR 4970: https://github.com/FreeCAD/FreeCAD/pull/4970 |
|
|
PR merged. |
- Anonymous
