USER FORUM
(you are viewing a thread; or go back to list of threads)
replacing current geom library with opencascade (by walter steffe)
Hello,
not yet tried but, looking at the examples, solvespace seems to be a very interesting open source CAD.
It seems to have a good sketcher with a constraint solver.
Some basic CAD features (fillet, chamfer, extrude along a path...) are nevertheless not present (please correct me if I am wrong).
But all these missing features (and also faster boolean operations) are provided by the OpenCascade library.
So why not to replace the present geometrical library with OpenCascade ?
not yet tried but, looking at the examples, solvespace seems to be a very interesting open source CAD.
It seems to have a good sketcher with a constraint solver.
Some basic CAD features (fillet, chamfer, extrude along a path...) are nevertheless not present (please correct me if I am wrong).
But all these missing features (and also faster boolean operations) are provided by the OpenCascade library.
So why not to replace the present geometrical library with OpenCascade ?
(no subject) (by Jonathan Westhues)
(no subject) (by walter steffe)
Ok so I see that there is already an interest in this topic.
Then why non to explore possible ways to do that ?
In my view in the first place it is necessary to identify the clean existing boundary you (Jonathan) are speaking of.
I have just downloaded the sources from Whitequark repository trying to understand how it works and what can be done.
In the transition to OCC the SSurface class should probably be replaced with or become a subclass of TopoDS_Face (the trimmed face of OCC).
I did a search (using cscope) to see where the SSurface class is used inside Solvespace.
Of course it is used in many places but it is also used for things, such as ray-casting, which probably will not be needed once the OCC library is fully exploited.
OCC provides a lot of services (extrude operations, boolean, interference check, visualization in a graphic window, a selection mechanism, triangulation ...). I think it would be easier to use them than to rewrite the low level Solvespace algorithms using the data structure of OCC .
The parts which provide a clear added value must, of course, be kept. These are for sure the sketch, the constraint solver and the clean and logical path you have implemented for the definition of the CAD operation sequence.
walter
Then why non to explore possible ways to do that ?
In my view in the first place it is necessary to identify the clean existing boundary you (Jonathan) are speaking of.
I have just downloaded the sources from Whitequark repository trying to understand how it works and what can be done.
In the transition to OCC the SSurface class should probably be replaced with or become a subclass of TopoDS_Face (the trimmed face of OCC).
I did a search (using cscope) to see where the SSurface class is used inside Solvespace.
Of course it is used in many places but it is also used for things, such as ray-casting, which probably will not be needed once the OCC library is fully exploited.
OCC provides a lot of services (extrude operations, boolean, interference check, visualization in a graphic window, a selection mechanism, triangulation ...). I think it would be easier to use them than to rewrite the low level Solvespace algorithms using the data structure of OCC .
The parts which provide a clear added value must, of course, be kept. These are for sure the sketch, the constraint solver and the clean and logical path you have implemented for the definition of the CAD operation sequence.
walter
(no subject) (by Jonathan Westhues)
There certainly is nothing stopping you (or anyone else) from undertaking that work. It's just a big job, and it would replace ~5k lines of code with hundreds of thousands. Stuff like the raycasting would of course become unnecessary; that's used only to implement the current Booleans. To a (pretty good) first order, I'd expect everything in srf/... to get replaced, and everything else to stay.
(no subject) (by walter steffe)
Hello Jonathan,
But I do not think that this job can be so big.
The low level code in srf/ would be replaced with calls to higher level libraries (implementation details of booleans will be, in example, moved outside of Spacesolve).
So, the final result will be e reduction (not an increase) of the lines of code of Spacesolve.
From what have seen, I think it would be sufficient to reimplement the classes and functions declared in surfaces.h.
Even that work would not be completely necessary.
In example I have seen that the function Shell::CopySurfacesTrimAgainst() is not used outside of srf/.., so it is not necessary to reimplement it.
A good starting point would be to have a minimal version of surface.h which declares only the things that are really needed outside of srf/.
It would also help to have comments which clearly define all these things.
walter
But I do not think that this job can be so big.
The low level code in srf/ would be replaced with calls to higher level libraries (implementation details of booleans will be, in example, moved outside of Spacesolve).
So, the final result will be e reduction (not an increase) of the lines of code of Spacesolve.
From what have seen, I think it would be sufficient to reimplement the classes and functions declared in surfaces.h.
Even that work would not be completely necessary.
In example I have seen that the function Shell::CopySurfacesTrimAgainst() is not used outside of srf/.., so it is not necessary to reimplement it.
A good starting point would be to have a minimal version of surface.h which declares only the things that are really needed outside of srf/.
It would also help to have comments which clearly define all these things.
walter
(no subject) (by Jonathan Westhues)
You are correct that most of the functions in srf/surface.h are internal to the surface operations. If you wanted to undertake this work, then stripping that down to the functions that must be exposed would indeed seem like a reasonable starting point. That would mostly be a mechanical exercise, but in some cases need a bit of judgment, mostly as to where you switch from SBezier etc. (which you'd probably want to retain, since curves are manipulated in many places independently of the surface operations) to Open CASCADE's equivalents.
Let me know if you have any specific questions, and I'm glad to respond.
Let me know if you have any specific questions, and I'm glad to respond.
(no subject) (by walter steffe)
Thanks Jonathan,
I will see if I can find some time to initiate this job.
I am quite busy with the development (in my spare time) of the EmCAD code which I am soon going to publish as an open source.
As you can see from the annexed paper EmCAD is aimed to the electromagnetic modelization and it needs an external CAD to define the geometry.
Up to now, I have used Catia for that (which is available in the company where I am employed) but it is an overkill.
It is a long time since I am looking for an open source replacement and Solvespace could be a perfect solution.
So I am strongly motivated to see a progress in Solvespace towards the adoption of OCC which is used also in EmCAD. This would also eliminate the need of the translation into a step file (now used in the transfer from CATIA to EmCAD).
Unfortunately free time is a scarce resource.
So I will see.
Walter
I will see if I can find some time to initiate this job.
I am quite busy with the development (in my spare time) of the EmCAD code which I am soon going to publish as an open source.
As you can see from the annexed paper EmCAD is aimed to the electromagnetic modelization and it needs an external CAD to define the geometry.
Up to now, I have used Catia for that (which is available in the company where I am employed) but it is an overkill.
It is a long time since I am looking for an open source replacement and Solvespace could be a perfect solution.
So I am strongly motivated to see a progress in Solvespace towards the adoption of OCC which is used also in EmCAD. This would also eliminate the need of the translation into a step file (now used in the transfer from CATIA to EmCAD).
Unfortunately free time is a scarce resource.
So I will see.
Walter
(no subject) (by EvilSpirit)
We have a try to replace solvespace core with opennurbs+brlcad booleans, but our geometry-core-programmer fall into depressy, so he going to improve some basic mesh-booleans to be faster & perfect quality result. at the moment we have multy-core architecture. we have a cad of cad.
(no subject) (by walter steffe)
I have changed my mind about the strategy for moving to OCC.
I am trying to do it from button up starting with the OCC implementation of SBezier class.
At the moment I have just added a field to the beginning of the SBezier declaration (in surface.h):
class SBezier {
public:
Handle(Geom_BezierCurve) hCurve; //added field
int tag;
....
The following statements were added at the beginning of solvespace.h:
#if defined(HAVE_OCE_CONFIG_H)
#include <oce-config.h>
#elif defined(HAVE_OCC_CONFIG_H)
#include <config.h>
#endif
#include <Geom_BezierCurve.hxx>
Unfortunately it is not possible to include Geom_BezierCurve.hxx at the beginning of surface.h because this file is always embedded in the namespace "SolveSpace" and many errors are generated during the compilation.
The annexed file is the top level CMakeList.txt where I have added a section looking for the OCC libraries.
I have slightly changed also the src/CMakeList.txt and I wiil upload it in the next post.
walter
I am trying to do it from button up starting with the OCC implementation of SBezier class.
At the moment I have just added a field to the beginning of the SBezier declaration (in surface.h):
class SBezier {
public:
Handle(Geom_BezierCurve) hCurve; //added field
int tag;
....
The following statements were added at the beginning of solvespace.h:
#if defined(HAVE_OCE_CONFIG_H)
#include <oce-config.h>
#elif defined(HAVE_OCC_CONFIG_H)
#include <config.h>
#endif
#include <Geom_BezierCurve.hxx>
Unfortunately it is not possible to include Geom_BezierCurve.hxx at the beginning of surface.h because this file is always embedded in the namespace "SolveSpace" and many errors are generated during the compilation.
The annexed file is the top level CMakeList.txt where I have added a section looking for the OCC libraries.
I have slightly changed also the src/CMakeList.txt and I wiil upload it in the next post.
walter
(no subject) (by walter steffe)
This is the src/CMakeList.txt
w
w
(no subject) (by walter steffe)
I forgot to say that it was also necessary to rename:
TtfFont::Handle(int *dx, int x, int y, bool onCurve)
to
TtfFont::handle(int *dx, int x, int y, bool onCurve)
This is because OCC defines a Handle macro which would otherwise clash with TtfFont::Handle.
Having applied all these changes I have chaecked that the code is properly built on the ubuntu 14.04 platform.
On my system I have installed:
liboce-foundation-dev,
liboce-modeling-dev,
liboce-ocaf-lite-dev
iboce-visualization-dev
but I am not sure is all are necessary.
walter
TtfFont::Handle(int *dx, int x, int y, bool onCurve)
to
TtfFont::handle(int *dx, int x, int y, bool onCurve)
This is because OCC defines a Handle macro which would otherwise clash with TtfFont::Handle.
Having applied all these changes I have chaecked that the code is properly built on the ubuntu 14.04 platform.
On my system I have installed:
liboce-foundation-dev,
liboce-modeling-dev,
liboce-ocaf-lite-dev
iboce-visualization-dev
but I am not sure is all are necessary.
walter
(no subject) (by whitequark)
Walter, I am very glad to see you undertaking this work. Any chance you could make a fork of the repository on GitHub so we could follow your work more easily? (Also, my changes were merged upstream, so you can just use https://github.com/jwesthues/solvespace).
(no subject) (by walter steffe)
Hello whitequark
I have just created the repository:https://github.com/wsteffe/solvespace_occ
where I have imported from https://github.com/jwesthues/solvespace
and then added a few changes.
I have no experience with github and do not know if this is the correct procedure to make a fork.
Anyway at the moment I was trying to implement the creation of bezier curves using Opencascade (see the changes in curve.cpp).
It compiles but crashes when entering the Geom_BezierCurve constructor (line 37 of curve.cpp),
I have inspected the input parameters of this call and they seem to be OK.
So I think that the problem is a bug of OpenCascade.
I have reported it at the the forum on Opencascade.org.
Walter
I have just created the repository:https://github.com/wsteffe/solvespace_occ
where I have imported from https://github.com/jwesthues/solvespace
and then added a few changes.
I have no experience with github and do not know if this is the correct procedure to make a fork.
Anyway at the moment I was trying to implement the creation of bezier curves using Opencascade (see the changes in curve.cpp).
It compiles but crashes when entering the Geom_BezierCurve constructor (line 37 of curve.cpp),
I have inspected the input parameters of this call and they seem to be OK.
So I think that the problem is a bug of OpenCascade.
I have reported it at the the forum on Opencascade.org.
Walter
replacing current geom library with opencascade (by John Griessen)
Any response back from open cascade folks yet? I've been wondering how open to community input they are after using FreeCAD some. I've been able to import STEP output from solvespace to freecad, but that goes through open cascade code and has some differences with the way freecad groups objects.
Post a reply to this comment: