Recently I’ve spent some time on updating my OCCT samples demonstrating OCCT 3D Viewer integration into Qt and GTK frameworks. This small post is about some highlights of these changes and some background.

Recently I’ve spent some time on updating my OCCT samples demonstrating OCCT 3D Viewer integration into Qt and GTK frameworks. This small post is about some highlights of these changes and some background.

Recently, I’ve been pointed to the EGL_ANGLE_create_context_webgl_compatibility extension. To play with it, I’ve replaced existing libEGL.dll/libGLESv2.dll alongside OCCT build with updated libraries from ANGLE project. However, the process stuck at the very beginning – the new libraries worked just fine with my wglinfo tool, but not with OCCT. Surprisingly, eglGetDisplay() returned NULL in OCCT builds. How might this mystery happen?
As a developer of CAD software, one cannot underestimate the importance of a wireframe presentation (drawing B-Rep model with topological edges and surface isolines, not triangle boundaries). Most 3D-graphics API support rendering (poly)lines with thickness fixed in pixels like GL_LINES in OpenGL – and this is what most users expected to see.
But “drama” happened at some point – OpenGL 3 specification released in 2008 deprecated the possibility to change line width via glLineWidth(), and newer APIs like WebGPU don’t even expose this feature! OCCT users may experience unnaturally thin AIS_Wireframe presentation on some systems because of that.
So, what actually happened?

Handling file input/output in C++ framework API looks pretty straightforward from the first glance, but becomes more complicated when the developer wants to define custom streams, deal with virtual/remote files systems. An experienced C++ developer might have seen plenty of C/C++ libraries exposing various stream APIs, and multiple OCCT classes take standard C++ streams std::istream/std::ostream on input.
OCCT 7.6 introduced the new class OSD_FileSystem, which could be easily missed by the majority of OCCT users. However, this class is intended to solve numerous problems related to file system operations in OCCT, and might be useful to be aware of it.
Firefox 134 and Chrome 133 have finally pushed the WASM/Memory64 extension from development builds to stable releases. This annonce made me eager to try this WebAssembly extension on DRAWEXE.js.

It was a long journey started in 2014 with porting sView onto Android platform and taking a first look onto marketplaces for applications. I remember the first impressions from Google Play: plenty of rules, weird design of versioning APKs for different architectures, nice-looking detailed statistics and weird metrics that you cannot compare with existing applications…

Recently, I’ve run into a project using the Ninja + Visual Studio compilers combination in CMake Presets. I’ve compared this preset with the classical Visual Studio project generated by CMake and found the difference between the two amusing to me.
Whereas traditional Visual Studio projects suffered from usability issues (adding /MP to compiler flags resulted in swapping memory – 16 GB of RAM wasn’t enough for the project, and I have to tune flag to /MP8 to get reasonable behavior), Ninja builds were faster and more convenient. Then I’ve decided to check if this approach will bring any boost to OCCT building procedure.

BRepMesh is an essential part of Open CASCADE Technology, which handles generation of triangulated representation of analytical surfaces in B-Rep shapes. Whether you want to display a shape in 3D Viewer, to speedup some geometrical algorithm like collision detection, to convert STEP file into STL format for 3D printer or into glTF format for web application – BRepMesh is the first step to go. This post provides a short introduction to new BRepMesh users.

It’s very nice to meet OCCT users from development forum in person, once in a while – even when you don’t expect to ;). frank-pian is on the photo below.

Animation playback is an integral part of real-time graphics, and sooner or later any CAx application has to implement animation of some sort – would that be a simulation of robotics kinematics, embedded video playback, simulation of some process or just a smooth camera transition. These animations look very different, but raise common questions for managing smooth and timely viewer updates.
For a long while, each application utilizing OCCT 3D Viewer had to implement animation in its own way. These implementations were usually both complicated, error-prone, and suffered from bugs and limitations. At some point we’ve decided that animation logic could be generalized to some extent and put into the AIS framework.
AIS_Animation introduced in ‘2016 and AIS_ViewController introduced later on (landed in OCCT 7.4.0) – are two bricks of this animation API accumulating years of experience in development of CAx applications. This article provides a short overview of this API and animation in general, and briefly shares my background and ideas put into it.
Continue reading