Discussion:
Tesselation
Guillaume Bouchard
2010-06-28 13:39:27 UTC
Permalink
Hello everybody.

Recently I have used python-OCC to convert STEP files into STL files with help
of the STL API.

But this gives me really crappy tesselation, with very little and very big
triangles on a really long time (approximately 1 minutes on the quad core i7 for
an object of only 400K entities). There is only one or two settings which are
little or undocumented (is there a doc somewhere ?), and changing these
settings from different values gives unpredictables results.

In fact I don't care about STL, I only wants a soup of homogeneous triangles
that represents my geometry. Is there a way to get the tesselated list of
triangles, with understundable settings and at a quicker speed ?

Thank you.
--
Guillaume
Thomas Paviot
2010-06-28 19:52:40 UTC
Permalink
Post by Guillaume Bouchard
Hello everybody.
Hi Guillaume,
Post by Guillaume Bouchard
Recently I have used python-OCC to convert STEP files into STL files with help
of the STL API.
But this gives me really crappy tesselation, with very little and very big
triangles on a really long time (approximately 1 minutes on the quad core i7 for
an object of only 400K entities). There is only one or two settings which are
little or undocumented (is there a doc somewhere ?), and changing these
settings from different values gives unpredictables results.
Do API Reference available at: http://api.pythonocc.org

The methods available from the StlAPI_Writer class, useful to customize the
generated STL files are SetDeflection() (default is 0.01) and
SetCoefficient() (default is 0.001) (documentation:
http://api.pythonocc.org/OCC.StlAPI.StlAPI_Writer-class.html).
Post by Guillaume Bouchard
In fact I don't care about STL, I only wants a soup of homogeneous triangles
that represents my geometry. Is there a way to get the tesselated list of
triangles, with understundable settings and at a quicker speed ?
The algorithm used to generate files is quite simple. You might have a look
at the MEFISTO2 mesher, that creates homogeneous triangles. But you will
have to write the STL exporter by yourself (in ASCII mode, it's not very
difficult). Have a look at the surfacig_mesh.py sample (
http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level1/SMESH/surfacic_mesh.py).
You can see a video of this sample here:

Post by Guillaume Bouchard
Thank you.
--
Guillaume
Best Regards,

Thomas
Guillaume Bouchard
2010-07-06 16:14:51 UTC
Permalink
Hello,

Sorry for the lag between your answer and my.
Post by Thomas Paviot
Do API Reference available at: http://api.pythonocc.org
The methods available from the StlAPI_Writer class, useful to customize the
generated STL files are SetDeflection() (default is 0.01) and
http://api.pythonocc.org/OCC.StlAPI.StlAPI_Writer-class.html).
Am I missing something ? Or the so-called documentation does not gives a clue
about what are the parameters ? (it is not a rant about the documentation, I
know that writing documentation is hard, boring and difficult ;) Currently It
is like "Call theses functions with a random value and guess why this change
something."
Post by Thomas Paviot
The algorithm used to generate files is quite simple. You might have a look
at the MEFISTO2 mesher, that creates homogeneous triangles. But you will
have to write the STL exporter by yourself (in ASCII mode, it's not very
difficult). Have a look at the surfacig_mesh.py sample (
http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level1/SMESH/surfacic_mesh.py).
Nice example. I have issues importing OCC.SMESH and OCC.StdMeshers with the
ubuntu pythonocc package available for ubuntu, I'll try tomorrow to use the
pythonocc from source, but I hate when it comes to compilation ;)

Thank you for your help.
--
Guillaume
Thomas Paviot
2010-07-07 06:15:59 UTC
Permalink
Post by Guillaume Bouchard
Hello,
Sorry for the lag between your answer and my.
Post by Thomas Paviot
Do API Reference available at: http://api.pythonocc.org
The methods available from the StlAPI_Writer class, useful to customize
the
Post by Thomas Paviot
generated STL files are SetDeflection() (default is 0.01) and
http://api.pythonocc.org/OCC.StlAPI.StlAPI_Writer-class.html).
Am I missing something ? Or the so-called documentation does not gives a clue
about what are the parameters ? (it is not a rant about the documentation, I
know that writing documentation is hard, boring and difficult ;) Currently It
is like "Call theses functions with a random value and guess why this change
something."
We do not aim at replacing the OpenCascade team. It is out of our objectives
to write a documentation of the OpenCascade kernel. It's the OCC team job!
Here is out you should process if you want to deeply understand what
happens:

1. Read the OCC documentation
2. Read the OCC headers (*.hxx files) to get documentation:

snippet from StlAPI_Writer.hxx:
"""
//! Sets the deflection of the meshing algorithm. <br>
//! Deflection is used, only if relative mode is false <br>
Standard_EXPORT void SetDeflection(const Standard_Real aDeflection) ;

//! Sets the coeffiecient for computation of deflection through <br>
//! relative size of shape. Default value = 0.001 <br>
Standard_EXPORT void SetCoefficient(const Standard_Real aCoefficient) ;
"""

When I started to work on the wrapper, I created a script that extracts the
docstrings from these headers and convert them to python docstings (you can
access with help(somehting) or something.__doc__). But this way to proceed
raises licensing issues: if I include original code from OCC into the python
wrapper, then pythonOCC falls under the terms of the OCCT public license.

3. Study the C++ code. For instance, the algorithmic part of the Stl meshing
is available in the file named StlTransfer.cxx (it's the method named
BuildIncrementalMesh).
Post by Guillaume Bouchard
Post by Thomas Paviot
The algorithm used to generate files is quite simple. You might have a
look
Post by Thomas Paviot
at the MEFISTO2 mesher, that creates homogeneous triangles. But you will
have to write the STL exporter by yourself (in ASCII mode, it's not very
difficult). Have a look at the surfacig_mesh.py sample (
http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level1/SMESH/surfacic_mesh.py
).
Nice example. I have issues importing OCC.SMESH and OCC.StdMeshers with the
ubuntu pythonocc package available for ubuntu, I'll try tomorrow to use the
pythonocc from source, but I hate when it comes to compilation ;)
SMESH and GEOM modules were not packaged by the ubuntu packagers. I recently
improved the way to build these libraries in order to make packaging easier.
This will be available in the next release. In the meantime, I suggest you
compile your own pythonocc from the subversion trunk.
Post by Guillaume Bouchard
Thank you for your help.
You're welcome,
Post by Guillaume Bouchard
--
Guillaume
Thomas
Denis Barbier
2010-07-07 06:37:24 UTC
Permalink
On 2010/7/7 Thomas Paviot wrote:
[...]
Post by Thomas Paviot
SMESH and GEOM modules were not packaged by the ubuntu packagers. I recently
improved the way to build these libraries in order to make packaging easier.
This will be available in the next release. In the meantime, I suggest you
compile your own pythonocc from the subversion trunk.
Hi Thomas, to help using packages on Debian/Ubuntu, it would be nice
to not require setting CSF_GraphicShr; I sent a patch a while back,
has it any chance to be applied?
Thanks.

Denis
Thomas Paviot
2010-07-07 06:50:55 UTC
Permalink
Post by Thomas Paviot
[...]
Post by Thomas Paviot
SMESH and GEOM modules were not packaged by the ubuntu packagers. I
recently
Post by Thomas Paviot
improved the way to build these libraries in order to make packaging
easier.
Post by Thomas Paviot
This will be available in the next release. In the meantime, I suggest
you
Post by Thomas Paviot
compile your own pythonocc from the subversion trunk.
Hi Thomas, to help using packages on Debian/Ubuntu, it would be nice
to not require setting CSF_GraphicShr; I sent a patch a while back,
has it any chance to be applied?
Thanks.
Of course! I already discussed that point with Oliver Born, any idea is
welcome.
Post by Thomas Paviot
Denis
Thomas
Denis Barbier
2010-07-07 07:17:46 UTC
Permalink
Post by Thomas Paviot
Post by Denis Barbier
[...]
Post by Thomas Paviot
SMESH and GEOM modules were not packaged by the ubuntu packagers. I recently
improved the way to build these libraries in order to make packaging easier.
This will be available in the next release. In the meantime, I suggest you
compile your own pythonocc from the subversion trunk.
Hi Thomas, to help using packages on Debian/Ubuntu, it would be nice
to not require setting CSF_GraphicShr; I sent a patch a while back,
has it any chance to be applied?
Thanks.
Of course! I already discussed that point with Oliver Born, any idea is
welcome.
Sorry if I missed something, but I am not aware of any issue with this
patch, can you please tell what has to be discussed? I resent here
the original patch, and the same updated against latest SVN.
Thanks.

Denis
Thomas Paviot
2010-07-07 07:23:52 UTC
Permalink
Post by Denis Barbier
Post by Thomas Paviot
Post by Denis Barbier
[...]
Post by Thomas Paviot
SMESH and GEOM modules were not packaged by the ubuntu packagers. I recently
improved the way to build these libraries in order to make packaging easier.
This will be available in the next release. In the meantime, I suggest you
compile your own pythonocc from the subversion trunk.
Hi Thomas, to help using packages on Debian/Ubuntu, it would be nice
to not require setting CSF_GraphicShr; I sent a patch a while back,
has it any chance to be applied?
Thanks.
Of course! I already discussed that point with Oliver Born, any idea is
welcome.
Sorry if I missed something, but I am not aware of any issue with this
patch, can you please tell what has to be discussed? I resent here
the original patch, and the same updated against latest SVN.
Thanks.
It was a private discussion. Here is a snippet of this discussion, related
to the CSF_* stuff:
"""
Post by Denis Barbier
Post by Thomas Paviot
On my side, I also have a request: would it be possible to automate
the creation of the CSF_GraphicShr from the .deb package installation?
It currently has to be set manually.
If there is an automatic way to determine the location of the
libTKOpenGl*.so library if this variable does not exist I would prefer
ldd /usr/lib64/python2.6/site-packages/OCC/_Geom2dToIGES.so | grep -i
libTKOpenGl
Good idea.
Post by Denis Barbier
I have not checked the sources of pythonOCC, so it is not clear to me,
why this variable is needed.
It's required by OpenCascade itself. CSF_GraphicShr must be defined in order
to set up an open gl renderer.
Post by Denis Barbier
Best regards,
Oliver
Thomas
"""

Let me have a look at your patches. Thanks!

Thomas
Denis Barbier
2010-07-07 07:34:52 UTC
Permalink
On 2010/7/7 Thomas Paviot wrote:
[...]
Post by Thomas Paviot
It was a private discussion. Here is a snippet of this discussion, related
"""
Post by Denis Barbier
Post by Thomas Paviot
On my side, I also have a request: would it be possible to automate
the creation of the CSF_GraphicShr from the .deb package installation?
It currently has to be set manually.
If there is an automatic way to determine the location of the
libTKOpenGl*.so library if this variable does not exist I would prefer
ldd /usr/lib64/python2.6/site-packages/OCC/_Geom2dToIGES.so | grep -i
libTKOpenGl
Good idea.
Post by Denis Barbier
I have not checked the sources of pythonOCC, so it is not clear to me,
why this variable is needed.
It's required by OpenCascade itself. CSF_GraphicShr must be defined in order
to set up an open gl renderer.
Thanks for the input. This statement is true for upstream sources,
but I modified the Debian package (and thus the Ubuntu one also) to
not require setting environment variables.

Denis
Thomas Paviot
2010-07-07 08:45:41 UTC
Permalink
Post by Thomas Paviot
[...]
Post by Thomas Paviot
It was a private discussion. Here is a snippet of this discussion,
related
Post by Thomas Paviot
"""
Post by Denis Barbier
Post by Thomas Paviot
On my side, I also have a request: would it be possible to automate
the creation of the CSF_GraphicShr from the .deb package installation?
It currently has to be set manually.
If there is an automatic way to determine the location of the
libTKOpenGl*.so library if this variable does not exist I would prefer
ldd /usr/lib64/python2.6/site-packages/OCC/_Geom2dToIGES.so | grep -i
libTKOpenGl
Good idea.
Post by Denis Barbier
I have not checked the sources of pythonOCC, so it is not clear to me,
why this variable is needed.
It's required by OpenCascade itself. CSF_GraphicShr must be defined in
order
Post by Thomas Paviot
to set up an open gl renderer.
Thanks for the input. This statement is true for upstream sources,
but I modified the Debian package (and thus the Ubuntu one also) to
not require setting environment variables.
Denis
Hi Denis,

Could you please use the issue tracker to submit your patches? It will be
easier to trace your proposal:

http://code.google.com/p/pythonocc/wiki/ContributorsGuidelines

Thanks,

Thomas

Jelle Feringa
2010-07-07 07:24:18 UTC
Permalink
Post by Denis Barbier
Sorry if I missed something, but I am not aware of any issue with this
patch, can you please tell what has to be discussed? I resent here
the original patch, and the same updated against latest SVN.
Interesting idea. If the CSF_GraphicShr variable somehow doesn't need to be set, than that would make deployment a little easier.
Thanks for the suggestion.

-jelle
Loading...