"to_stl" not creating STL output file

[sonofeft]

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.

[charles-sharman]

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

[sonofeft]

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.

[charles-sharman]

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.

[sonofeft]

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.

====================================================================== ERROR: test_fillet_common (model_unittest.TestSolidFunctions)

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

====================================================================== ERROR: test_offset (model_unittest.TestArbitrary)

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)

[charles-sharman]

Thanks. It looks like ccad has a few more bugs when using pythonocc 0.18:

1. Filleting newly created edges after a boolean common fails.
2. 3D offsetting a shape fails.
3. unittest ought to make sure to_stl creates a file.

More work for the 0.18 compatibility migration.