
Sun, 04/06/2025 - 00:26
Hey, everybody!
I am new to OCCT and just starting out. I am writing a node to import step file into Houdini. And there are some problems when working with XCAF
Houdini doesn't want to accept the code where XCAFApp_Application::GetApplication() is initialized - it just won't load my dll.
So it was decided to use more low-level access to step file entities. However, I realize that I'm doing it wrong. Because of this, the mechanism itself turned out to be cumbersome.
Now I just analyze the data from the Model, extracting all SHAPE_REPRESENTATION entities from it. Then I recursively build a tree of all geometric objects and related transformations. And then I build the geometry for Houdini, applying to it, also translated into Houdini format, sets of transformations. I manage to build all the objects, but when analyzing the surfaces, some of them are excluded as unsuitable (there is a certain loss of objects here)
But, I think such a mechanism is not the right one. Unfortunately, because of working with low-level entities, I don't understand if I can get the whole tree of entities directly, without using my recursive tree building. Whether I can also, without tracing relationships in the entities themselves, find immediately the geometry that applies to a particular object without having to assemble them from separate faces and shells. The same goes for finding all the transformations that need to be applied to a particular geometry entity in the hierarchy.
There are unfortunately very few examples in the documentation to help me understand the rather confusing step file format.
So I am asking for help from the community in terms of information where similar issues are addressed. But, exactly without using XDE and XCAF
Sun, 04/06/2025 - 00:40
>> XCAFApp_Application::GetApplication()
I assume some 3rd-party in real-time is not reachable. Please check PATH or LD_LIBRARY_PATH to find all necessary 3rd-party.
My apologies, you message not well clear for me, i do not get full scenario, you probably need to share code sample or more technical details, but extracting tree from the STP model is not a right way. And if you still want to do so, you can duplicate code from StepCAFControl_Reader.
Best regards, Dmitrii.
Sun, 04/06/2025 - 01:57
Hmm, you mean the path to the 3rd-party in the system is not spelled out?
I installed this distribution https://dev.opencascade.org/release/previous#node-84228
opencascade-7.7.0-vc14-64.exe
Can you tell me what exactly should be in the environment variables?
As for my code - unfortunately it's quite large and I can't pick out some pieces to show how I build everything...
It goes something like this:
. . . .
And so on.
By extracting the entities I need, analyzing their items or context or id, I look for matches, and finally collect the information in
std::map<int, ShapeRepsData>
And then, from this date, I take the collected information on all the “leaves” in the hierarchy tree and build the geometry in Houdini.
I agree - everything is not optimal, to put it mildly (
Sun, 04/06/2025 - 02:10
Do you mean these variables?
CSF_PluginDefaults points to sources of $CASROOT/src/XCAFResources.
CSF_XCAFDefaults points to sources of $CASROOT/src/XCAFResources.
But, there is no such directory in Open CASCADE installed through the installer....
Sun, 04/06/2025 - 11:44
I was meaning path to bin folders (resolving unresolved symbols/dependencies), like that (it is for VS Code, but you can adapt for bash or env variable)
{
"name": "PATH",
"value": "C:/work/projects/occt/3rdparty/tcltk-86-64/bin;C:/work/projects/occt/3rdparty/freeimage-3.18.0-vc14-x64/bin;C:/work/projects/occt/3rdparty/freetype-2.13.3-vc14-x64/bin;C:/work/projects/occt/3rdparty/tbb-2021.13.0-x64/bin;C:/work/projects/occt/3rdparty/vtk-9.4.1-x64/bin;${env:PATH}"
},
Best regards, Dmitrii.
Sun, 04/06/2025 - 10:06
What do you mean "doesn't want to accept the code"? Is there some code revision criterion for that? Or application is unable to load your DLL with some error (due to unresolved dependencies, etc.)?
Or maybe you are referring to a legacy plugin loading mechanism in OCCT for loading OCAF persistence drivers via plugins defined by
$CSF_PluginDefaults
environment variable andPlugin
file? There is no need to rely on this mechanism in the modern applications - just callBinXCAFDrivers::DefineFormat()
and addTKBinXCAF
library to linker flags:I cannot see how avoiding using XCAF would help loading OCCT in your environment.
Sun, 04/06/2025 - 12:00
Since I'm still a programmer, I'll try to describe what's going on )
In my code I write:
Handle(XCAFApp_Application) hApp = XCAFApp_Application::GetApplication();
...
I compile my dll, there are no errors.
Running Houdini. On startup, the program looks for all third-party dlls in the specified path (dso folder, this path is specified in environment variables).
As soon as houdini sees my dll, a message pops up, in which it is not possible to understand what the program does not like (picture in attached images).
This is not a critical error - it is just a message that shows that my dll will not be loaded. After that Houdini loads, but my node is not in it, of course, since the dll is not loaded.
I can't trace the reason because there is no situation to start debug mode.
Apparently, Houdini cannot find the modules that are needed.
On the side of my code, I also can't use debug mode because my code is not running yet.
What exactly am I doing wrong in this situation, I want to understand.
As I have already written above, most likely I am not working correctly with all the necessary dependencies. That's what I'm trying to figure out - how to write everything correctly to get around this situation )
Sun, 04/06/2025 - 12:03
Pleas use DUMPBIN utility and detect all missed dependencies for each TK* (Especially for TKService) and put then close to the OCCT's dll or update PATH variable.
Or something similar with: gkv311/checkdll: Command line tool for checking dependencies of DLL and EXE files
Best regards, Dmitrii.
Sun, 04/06/2025 - 12:24
Here is what checkDLL64 showed when analyzing:
Sun, 04/06/2025 - 12:27
Great, then move all these dll to bin folder, you can find them in the installation folder (in the subfolders).
Best regards, Dmitrii.
Sun, 04/06/2025 - 12:47
Oh! Great! It's all loaded! Oh, so much time was wasted! (
Thanks for your help, Dimitri!
Can you suggest a more rich resource on Open CASCADE with code examples exactly in the key of importing step files...
I need to get the entire hierarchy of geometric entities from a step file, properly named, and correctly positioned in space.
Sun, 04/06/2025 - 12:53
The main documentation: Open CASCADE Technology: Extended Data Exchange (XDE)
I'm not sure where to find more samples. At the moment, new article with tree iteration in progress and will be published as a calloboration with FreeCAD.
Best regards, Dmitrii.
Mon, 04/14/2025 - 12:26
Hi, Dmitry
As I said earlier, according to your recommendation with dll transfer of third-party modules - everything worked.
I have a question in this connection - I use only XDE and OCCT functionality to get references to final geometric entities and their attributes. The triangulation of the geometry and the subsequent output of this geometry is already done in Houdini.
And the addition of the ffmpeg, freeimage, etc. libraries is not quite clear in this way. What exactly do they do? Or is it just because the internal interconnections in OCCT itself require these third-party libraries, that's the only reason to add them to the project? And there is no way to do without them?
Mon, 04/14/2025 - 13:26
Serzh Iv wrote:
Take a look at documentation to figure out where particular dependency could be used. You may disable optional dependencies while building OCCT itself via CMake configuration flags like
USE_FREETYPE=OFF
,USE_FREEIMAGE=OFF
,USE_FFMPEG=OFF
and others.I may agree with you that you wouldn't need FFmpeg or FreeImage libraries for getting geometry from STEP file, although FreeImage could be used for make screenshots of the model.
Tue, 04/15/2025 - 10:55
Great, it all worked out. Now there are no unnecessary interconnections!
Sun, 04/06/2025 - 12:58
Thanks again! You have been a great help!
Tue, 04/15/2025 - 14:45
Another question )
Some step files are not imported completely. I know that there is geometry in the file, but when importing it is not there. I tried to open such a file with CAD Assistent - the same thing. Plus there are artifacts - broken pieces of surfaces ( both through my node and CAD Assistent ).
But, if you open the same file, say, in KOMPAS 3D - it will open completely, although there are artifacts there too - some surfaces are missing ( hole ).
If you write this step file from KOMPAS 3D, then CAD Assistent opens it normally ( just like KOMPAS 3D ). My noda can't cope with this file yet - it opens it the same way as before + small additions in the form of misplaced geometries.
What could be the problem - in the step file or something else?
The original step file (AP203) was exported from Solidworks.
Unfortunately, I can't provide the file for detailed analysis - it's under NDA ((
Tue, 04/15/2025 - 16:58
>>Unfortunately, I can't provide the file for detailed analysis - it's under NDA ((
In that case no options to us to validate or check anything.
Tue, 04/15/2025 - 20:42
Serzh Iv wrote
Data Exchange is very complex subject in CAD. Each CAD system has different requirements to tell if a particular model is valid or not in terms of the system. STEP format is a neutral format, which means that each CAD system tries to fit its B-Rep model into STEP standard on export (potentially loosing some information); another CAD system importing this model cannot just read model back - it has to also adjust model to fit into system requirements (perform shape healing), which may not succeed.
STEP export in some CAD systems is implemented not that good, so that they may write corrupted files or invalid models that they cannot read back themselves. So that to answer your question - the problem might be in the STEP file itself, in OCCT STEP reader, in OCCT Shape Healing algorithms or in some other algorithms (like BRepMesh, if you experience some visualization issues). The fact that some system is able to read STEP file doesn't necessary mean that file is valid, but it gives some higher chances that OCCT will be able to read this model after some improvements in it or by applied different STEP translation / shape healing options in OCCT.
If you curious what exactly might be wrong with the model - enable 'Verbose output' option in CAD Assistant and pay attention to warning and error messages in the Message Window. It may include useful messages from STEP parser, STEP translator and shape healing algorithms. You may also evaluate shape validity of imported model using
checkshape
tool in Draw Harness.Apart from that - you may share the model with OCCT developers so that they will be able to perform analysis on their own. Note that if you have similar problems on many models, then you/customer may try localizing which parts in the model cannot be translated well and weed out and reexport only a small part of them into STEP file, so that it could be shared publicly.