Open sonofeft opened 7 years ago
Thanks for trying ccad.
I believe your fix is not a good long-term solution, because BRepMesh_IncrementalMesh converts some faces to a mesh of triangulated faces, which could mess up subsequent operations. There's a reason people suffer the math difficulty of BRep instead of processing everything as triangulated faces. I think it would be better to understand why the original shape didn't create an stl file.
Does to_stl work on simple shapes like spheres, cylinders, and boxes for you, or does it fail for everything? If it fails for everything, I suspect a compatibility problem. ccad hasn't been enhanced for a while. It only works well up to oce and python occ 0.16.x. It breaks often (the viewer, particularly) with oce and python occ 0.17+ and 0.18+.
If it works on simple shapes but fails for your shape, when you view your shape, does it look right -- no improperly facing faces, no breaks at seam lines etc.? to_stl can break on improper shapes. Have you tried playing with the rel_deflection (in relative mode) or the abs_deflection (in abs mode) parameters? Tight bends can break to_stl unless you make the stl mesh fine enough.
If all else fails, and the model is not proprietary, you can email or dropbox a .brep representation, and I'll try to duplicate the problem.
Thanks, Charles
Hi Charles,
If it matters, you are correct that my viewer does not work. "import ccad.display as cd" throws an exception. "ImportError: cannot import name Visual3d_ViewOrientation" with OCC verion 0.18.
I'm sorry I was too lazy to implement the deepcopy suggestion in the first place, but this is what I would recommend. mesh_shape = copy.deepcopy( self.shape ) BRepMesh_IncrementalMesh( mesh_shape, 0.01 ) w.Write(mesh_shape, name)
also add "import copy" at the top. (I still worry about the 0.01 in the call to BRepMesh_IncrementalMesh)
The above fix works for me and addresses your concern of converting the original shape to a mesh.
Without the above fix, I tried both a box and sphere and neither one made an STL file (again no exception, just no STL file) My two 3-line codes which did not work are:
import ccad.model as cm s1 = cm.sphere(1.0) s1.to_stl('sph.stl')
AND
import ccad.model as cm s2 = cm.box(1.0, 2.0, 3.0) s2.to_stl('box.stl')
Hope this helps.
I assume the above 3-line codes work perfectly on your system, so it might just be my particular Windows 10 flavor to blame.
I also assume that some sort of "invisible" meshing call needs to be made by the OCC StlAPI_Writer in order to make an STL w/o modifying the self.shape. Perhaps delving into the OCC source would be enlightening.
Hi Charlie,
I looked at the OCE source and pythonocc 0.18. It seems like OCE's StlAPI_Writer still takes a TopoDS Shape as an input, but your experience shows it clearly wants a Mesh. It may be a Windows 10 only bug, but it could be universall. I'll keep this Issue open, and I'll look at it when I port ccad to use pythonocc 0.18. No promises when that will happen.
I would recommend you go to the unittest directory and run test_all:
python test_all.py
It tests every feature in ccad.model. to_stl might not be the only unexpected ccad.model failure under 0.18.
Here's the result of the python test_all.py Looks like 2 errors, neither of which involves the STL
Interestingly, when I run the unittest with my mesh addition logic, a tmp.stl file does appear, whereas when I run it with your original code, no tmp.stl appears.
Traceback (most recent call last): File "D:\Programs\ccad-master\unittest\model_unittest.py", line 219, in test_fillet_common s3 = cm.fillet_common(s1, s2, 0.25) File "C:\Anaconda\lib\site-packages\ccad\model.py", line 547, in fillet_common _BRepAlgoAPI.BRepAlgoAPI_Common(s1.shape, s2.shape), rad) File "C:\Anaconda\lib\site-packages\ccad\model.py", line 513, in _fillet_boolean return solid(b2.Shape()) RuntimeError: StdFail_NotDone BRep_API: command not done
Traceback (most recent call last): File "D:\Programs\ccad-master\unittest\model_unittest.py", line 1240, in test_offset s2 = cm.offset(s1, 1.0)[0] IndexError: list index out of range
Ran 129 tests in 3.922s
FAILED (errors=2)
Thanks. It looks like ccad has a few more bugs when using pythonocc 0.18:
More work for the 0.18 compatibility migration.
On my system (a Windows 10 machine) the "to_stl" did not create an STL file. (No exceptions thrown, but also no STL created.)
In the function "to_stl" (~line 1914) I added the new line (~line 1949): BRepMesh_IncrementalMesh( self.shape, 0.01 )
just above the following line (~line 1949): w.Write(self.shape, name)
and it now works for me. (also added: "from OCC.BRepMesh import BRepMesh_IncrementalMesh" at the top of the file)
I'm not sure if a copy or deepcopy might be required to prevent changes to the original "self.shape" Also, the default value of the mesh parameter "0.01" probably needs some consideration.