OpenCascade 7.6 is released

Quaoar

Administrator
Staff member
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.

1636038727374.png

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 p105 schema is used together with many other schemas in AP242.

Application Protocols, as AP242, combines integrated resource schemas (for kinematics, geometry, product structures etc.) to one schema to cover the product data scope of the AP. The purpose of the STEP architecture is to have all Application Protocols sharing the same integrated resource schemas. For instance the widely implemented AP203 and AP214 represents geometry in the same way, as they both use the same integrated schema for it. As you may know AP242 have replaced AP203 and AP214 as those had bigger ang bigger overlap during their development.

The STEP documentation has a big room for improvement... There is alot of work going on to improve the usability but it is still far from good. For implementation work I find the SMRL [https://www.iso.org/publication/PUB100443.html] more useful than single AP documents.
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.

1636038816012.png
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.

1636038286106.png

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:
  1. Progress indication is now injected in a few more algorithms where it was not available before.
  2. 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?
  3. 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."
  4. And there're "numerous bug fixes and improved robustness of modeling algorithms." That sounds so bloody good.
Conclusion

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:

Jojain

CAD practitioner
Thanks for the summary, do you know how we can get the progress feedback from the algorithms ? I never have seen any of that yet ?
 

Quaoar

Administrator
Staff member
Thanks for the summary, do you know how we can get the progress feedback from the algorithms ? I never have seen any of that yet ?
That's a good question, especially because the progress indication mechanism has been recently reworked, and I just realized that I have no idea how to use it. For now, I added this subject to the TODO list for lessons. But you can probably give it a shot by yourself looking at Message_ProgressIndicator and how it's used throughout the code.
 

DanB

CAD community veteran
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.
That's funny. Well spent time implementing this last week.

EDIT: I was a little fast on the trigger there. They have not made it open-source. Also, what is the fuzz? I mean what is the difference by using a third party solver (e.g. https://www.orocos.org/kdl.html) and what they have implemented?
 
Last edited:

DanB

CAD community veteran
Did you follow these standard rules or how have you approached the problem?
Since the software I'm making was first intended to only work as a digital twin for visualization by real-time logging joint data I only needed to do forward kinematic(just multiplying the transformation matrix recurrently). And that worked absolutely perfect. After running through 20.000 joint updates I could not see any deviation. Then I started to play with inverse kinematics, and from experience, I do not try to implement any of it myself - so I'm using KDLs IK solver, haven't tested it properly yet.
 

DanB

CAD community veteran
This one, right? https://github.com/orocos/orocos_kinematics_dynamics

Do you have anything related to data exchange? I'm thinking what if to use the STEP file with kinematics declared and then employ the IK solver to make it live. That might be a good demo of how to communicate the motions of mechanisms. Just thinking loudly.
Yes, that one :)

My initial idea was to use OCAF/XDE for data exchange, but as discussed in a previous thread it would not be sufficient due to the rapid data stream. So I went with an XML-file kind of mimicking what's called TF in ROS http://wiki.ros.org/tf. Also, I decided to split the STEP-file into several STEP-files containing each link, and transform them freely. I expected this to be very slow, but it actually runs at 120FPS.
 

A-U

Active CAD practitioner
I'm working on OCP 7.6 and (again...) I see a lot of missing includes in some OCCT headers. Sloppy coding or am I missing something (i.e. some headers are not meant for consumption)?
 

Quaoar

Administrator
Staff member
I'm working on OCP 7.6 and (again...) I see a lot of missing includes in some OCCT headers. Sloppy coding or am I missing something (i.e. some headers are not meant for consumption)?
Might be that in the OpenCascade itself they are included in a different order? Not sure, I gave it up and stick with 7.4 for as long as I could.
 

natalia

Moderator
Staff member
I'm working on OCP 7.6 and (again...) I see a lot of missing includes in some OCCT headers. Sloppy coding or am I missing something (i.e. some headers are not meant for consumption)?
It would be helpful if you share a piece of your error output to know which classes are absent.
Have you checked that in your project dependencies there is the path to OCCT includes and in this directory these headers exist?
Why 'again'? On which version of OCCT it happened and have you fixed it already?
 

A-U

Active CAD practitioner
Random example when doing my static analysis:

Code:
[W 211205 11:52:10 translation_unit:47] ./opencascade/IGESSolid_ToolBlock.hxx
[W 211205 11:52:10 translation_unit:48] dummy.cxx:79:104: error: unknown type name 'Standard_OStream'

AFAIR I had similar issues whe wrapping 7.5. Every now and then there is a missing include and/or forward declaration. NB: It is not about OCCT not in the path (that results in a different error). If this looks like a bug, I can open an issue with more details. If not, I'm curious to hear what would be the canonical solution.
 

Quaoar

Administrator
Staff member
Random example when doing my static analysis:

Code:
[W 211205 11:52:10 translation_unit:47] ./opencascade/IGESSolid_ToolBlock.hxx
[W 211205 11:52:10 translation_unit:48] dummy.cxx:79:104: error: unknown type name 'Standard_OStream'

AFAIR I had similar issues whe wrapping 7.5. Every now and then there is a missing include and/or forward declaration. NB: It is not about OCCT not in the path (that results in a different error). If this looks like a bug, I can open an issue with more details. If not, I'm curious to hear what would be the canonical solution.
I don't think it's a bug. It more looks like these includes were never ordered the way you happen to have them.
 

A-U

Active CAD practitioner
I don't think it's a bug. It more looks like these includes were never ordered the way you happen to have them.

I don't want to go too much into semantics, but what you state sounds more like a reason why it was not caught by the OCCT devs and not a reason for it being or not being a bug. Either way, it is still not clear to me if this situation is intentional and I don't know how the "correct" order of includes is supposed to be known.
 
Last edited:

Quaoar

Administrator
Staff member
I don't want to go too much into semantics, but what you state sounds more like a reason why it was not caught by the OCCT devs and not a reason for it being or not being a bug. Either way, it is still not clear to me if this situation is intentional and I don't know how the "correct" order of includes is supposed to be known.
@A-U Have you sorted it out? Just thinking if reordering includes in OpenCascade is a somewhat that is maybe worth contributing back as a patch.
 

A-U

Active CAD practitioner
I did not really solve - just found a suitable workaround for the binding generator. The workaround being specifying extra includes for the problematic headers.
 
Top