Here is the news: https://dev.opencascade.org/content/open-cascade-technology-760-released
Here is the corresponding FreeCAD forum topic: https://forum.freecadweb.org/viewtopic.php?f=8&t=62726
There are some neat features in this release that did not get much attention even in the official release notes. I'll comment on those that look interesting to me subjectively, although I'd expect that some folks might find all this visualization business (which seems to be the main spot) worth attention as well. So, here we go.
Kinematics in STEP
This thing is not quite dressed up in the release notes, although this is probably the most significant change that really deserves incrementing the version number. To give you some context, the STEP format allows for exchanging kinematics. By kinematics, we understand a declaration of joints and links that might be useful for exchanging the motion plans for robots, milling machines, etc. This whole thing is well specified but remains almost unsupported by CAD vendors developing their own walled gardens and not giving a shit about the open CAD world.
OpenCascade did not allow exchanging the kinematics as well, up to this point. Back in the day, I got in touch with Mikael Hedlind who contributed to kinematics and other parts of the STEP standard. For example, here is one of his papers: [Hedlind, M., & Kjellberg, T. (2014). Kinematical product specifications in engineering design. CIRP Annals - Manufacturing Technology, 63(1), 197–200. https://doi.org/10.1016/j.cirp.2014.03.097]. The kinematics is declared in what's called an "integrated resource schema" in STEP. I misunderstood the difference between application protocols and schemas, and Mikael made me a favor to explain this (on LinkedIn). Here's what he says:
So, equipped with that SMRL (STEP module and resource library) document (btw, I bought one for myself) OCC implemented base classes to communicate kinematics (ISO 10303-105:2019(E), STEP Schema AP242) to and from STEP files. However, if you're eager to start using it, I have bad news for you: all the XDE interfaces for readers and writers are not published in open source. In the open-source, you only have the transient classes which, if you are a black belt in OpenCascade, you could somehow use by manually parsing the STEP model. I have no idea how complicated that's going to be, and I'm thinking to prepare a lesson on it to investigate that matter a bit deeper. What's for sure is that it's far from being a "button click" solution and there's no single piece of documentation coming along on the kinematics support in OpenCascade. So, okay, kinematics is there, but not for the community. Maybe for the paying customers though.
That explains why the release notes do not emphasize that quite breaking improvement. And it is really breaking, no jokes: it's the first time STEP kinematics sees the light of day in an open-source translator, although there's this flavor of "unwanted child" feeling behind the scenes. But we don't know of course what was the motivation to do it that way.
New toys in a mesh
We read that OpenCascade now "stores deflection calculated upon triangulation along with parameters passed to a mesher to Poly_Triangulation." Actually, there's more than that. There's now something called "mesh purpose" in the Poly_Triangulation structure. The corresponding enum looks like that:
What I really love in this list is this "mesh marked as currently active in a list." Which list do they mean? It looks a little bit too much application-specific and I can guess it's all coming from some project or a product we're not aware of. Btw, your .brep files are now incompatible with the older versions of OpenCascade because of these neat little changes. There's however a workaround, but it's not the right time to speak about workarounds when celebrating the new release, right?
Something with OCAF
The release notes state something about the partial loading option in OCAF. Well, I'm not exactly sure about the possible use of such a feature, but it's maybe something that's worth trying out. However, the document says that we can lose about 15% of performance in the worst case, so I'm kinda confused. Still, the compatibility of OCAF documents is promised to be okay. It's a pity that .brep files did not deserve the same care.
Modeling?
Well, OpenCascade is the geometric modeling kernel after all. Here are the improvements in this core functionality:
You can come up with your own conclusions, of course, but I have this mixed feeling after reading the notes. It looks a bit like "we-wanted-to-release-something" release and I have the following questions:
Here is the corresponding FreeCAD forum topic: https://forum.freecadweb.org/viewtopic.php?f=8&t=62726
There are some neat features in this release that did not get much attention even in the official release notes. I'll comment on those that look interesting to me subjectively, although I'd expect that some folks might find all this visualization business (which seems to be the main spot) worth attention as well. So, here we go.
Kinematics in STEP
This thing is not quite dressed up in the release notes, although this is probably the most significant change that really deserves incrementing the version number. To give you some context, the STEP format allows for exchanging kinematics. By kinematics, we understand a declaration of joints and links that might be useful for exchanging the motion plans for robots, milling machines, etc. This whole thing is well specified but remains almost unsupported by CAD vendors developing their own walled gardens and not giving a shit about the open CAD world.
OpenCascade did not allow exchanging the kinematics as well, up to this point. Back in the day, I got in touch with Mikael Hedlind who contributed to kinematics and other parts of the STEP standard. For example, here is one of his papers: [Hedlind, M., & Kjellberg, T. (2014). Kinematical product specifications in engineering design. CIRP Annals - Manufacturing Technology, 63(1), 197–200. https://doi.org/10.1016/j.cirp.2014.03.097]. The kinematics is declared in what's called an "integrated resource schema" in STEP. I misunderstood the difference between application protocols and schemas, and Mikael made me a favor to explain this (on LinkedIn). Here's what he says:
The Application Protocol AP242 is said to be supported by OpenCascade for quite a while already. Therefore, the idea was to add the p105 schema to this support and enable communicating kinematics data using our old good STEP translator. During our conversation, Mikael recommended the following resource for anyone interested in developing a kinematics translator: "Meeting Minutes, Stockholm, Sweden, June 11-15, 2012". He said that at KTH University they made demo data examples on AP242 kinematics and used them in motion simulation software from STEP Tools.
So, equipped with that SMRL (STEP module and resource library) document (btw, I bought one for myself) OCC implemented base classes to communicate kinematics (ISO 10303-105:2019(E), STEP Schema AP242) to and from STEP files. However, if you're eager to start using it, I have bad news for you: all the XDE interfaces for readers and writers are not published in open source. In the open-source, you only have the transient classes which, if you are a black belt in OpenCascade, you could somehow use by manually parsing the STEP model. I have no idea how complicated that's going to be, and I'm thinking to prepare a lesson on it to investigate that matter a bit deeper. What's for sure is that it's far from being a "button click" solution and there's no single piece of documentation coming along on the kinematics support in OpenCascade. So, okay, kinematics is there, but not for the community. Maybe for the paying customers though.
That explains why the release notes do not emphasize that quite breaking improvement. And it is really breaking, no jokes: it's the first time STEP kinematics sees the light of day in an open-source translator, although there's this flavor of "unwanted child" feeling behind the scenes. But we don't know of course what was the motivation to do it that way.
New toys in a mesh
We read that OpenCascade now "stores deflection calculated upon triangulation along with parameters passed to a mesher to Poly_Triangulation." Actually, there's more than that. There's now something called "mesh purpose" in the Poly_Triangulation structure. The corresponding enum looks like that:
Code:
//! Purpose of triangulation using.
typedef unsigned int Poly_MeshPurpose;
enum
{
// main flags
Poly_MeshPurpose_NONE = 0, //!< no special use (default)
Poly_MeshPurpose_Calculation = 0x0001, //!< mesh for algorithms
Poly_MeshPurpose_Presentation = 0x0002, //!< mesh for presentation (LODs usage)
// special purpose bits (should not be set externally)
Poly_MeshPurpose_Active = 0x0004, //!< mesh marked as currently active in a list
Poly_MeshPurpose_Loaded = 0x0008, //!< mesh has currently loaded data
Poly_MeshPurpose_AnyFallback = 0x0010, //!< a special flag for BRep_Tools::Triangulation() to return any other defined mesh,
// if none matching other criteria was found user-defined flags should have higher values
Poly_MeshPurpose_USER = 0x0020 //!< application-defined flags
};What I really love in this list is this "mesh marked as currently active in a list." Which list do they mean? It looks a little bit too much application-specific and I can guess it's all coming from some project or a product we're not aware of. Btw, your .brep files are now incompatible with the older versions of OpenCascade because of these neat little changes. There's however a workaround, but it's not the right time to speak about workarounds when celebrating the new release, right?
Something with OCAF
The release notes state something about the partial loading option in OCAF. Well, I'm not exactly sure about the possible use of such a feature, but it's maybe something that's worth trying out. However, the document says that we can lose about 15% of performance in the worst case, so I'm kinda confused. Still, the compatibility of OCAF documents is promised to be okay. It's a pity that .brep files did not deserve the same care.
Modeling?
Well, OpenCascade is the geometric modeling kernel after all. Here are the improvements in this core functionality:
- Progress indication is now injected in a few more algorithms where it was not available before.
- We can now enable this sweety parallel mode in the validity checker. It's as simple as "just turn on the optional parameter theIsParallel," how about that?
- Well, quite a bit of space is devoted to prohibiting non-uniform scaling in TopoDS shapes. Now instead of getting the invalid shapes out of improper scaling, you'll get that bloody exception saying you're doing something stupid with your geometry. Still, if you feel like you know exactly what you're doing, there's that pro hackish "theRaiseExc" flag that you can turn on and off, depending on your situation. Just keep in mind that this option is not for mama's boys, and a "developer can use it at his own risk."
- And there're "numerous bug fixes and improved robustness of modeling algorithms." That sounds so bloody good.
You can come up with your own conclusions, of course, but I have this mixed feeling after reading the notes. It looks a bit like "we-wanted-to-release-something" release and I have the following questions:
- What's on the roadmap?
- What was really changed in the modeling part of the library? Are we invited to look through Git commits to get to know this?
- Was it so bloody necessary to break the compatibility of the BREP format that did not see any changes for decades?
- Is there anything that really deserves incrementing the version number? The new release inevitably introduces tons of headaches for those folks who try to stay up-to-date, and there should be a good reason to migrate. Just a reminder: OpenCascade versions are not binary compatible if you know what I mean.
- ...
Last edited:
