Issues with opencascade union operations

[timbod7]

The opencascade.js project is impressive!

There's quite a few layers involved however, and it's hard to know how to debug issues that arise. An an example, here's a problem I don't understand in a model I built in cascadestudio:

zalo/CascadeStudio#115

This could be a problem in

• cascadestudio's usage of opencascade.js
• opencascade.js implementation of opencascade
• opencascade itself

I've subsequently seen similar issues with union operations on other models, so presumably the errors are not that unusual. Is there anything I can do to get more informative errors messages?

[donalffons]

Hey, it's great to have more people checking the project out.

Debugging with OpenCascade.js is currently not so easy. However, I will investigate the topic a bit more in detail and will probably post some updates here, soon.

Here are some hints:

• Some errors will arise when C++ code throws an exception. Exceptions can have a significant performance and size impact. That's why currently, exception support is disabled in OpenCascade.js. Last time I checked, the performance impact seemed to be extremely large (I experienced a 5 times increase in loading a STEP file). However, I recently made some other tests (different project with different build settings) and experienced almost no performance impact. So, maybe there is a set of build settings that will make exceptions work nicely. Also, "native" WASM exceptions with smaller performance and size impacts will arrive in browsers probably soon (it's already in origin trial in Chrome). As of right now, enabling exception support in OpenCascade.js would require you to fork the library, i.e. this is not something that could be enabled with a "custom build".
• The error ___cxa_is_pointer_type is not defined reported by you seems to be more of an Emscripten / build configuration issue (and not caused by C++ code throwing an exception). That error message has been reported a few times over at the Emscripten repository. Debugging these things can be hard and will most likely require a special debug build of OpenCascade.js
• CascadeStudio is using a rather old fork of OpenCascade.js which relies on an old version of Emscripten. Since then, there have been several improvements but also breaking changes. @zalo seemed to be open to upgrade to the newest version. But I assume that I would first have to release the next major version (i.e. non-beta) of OpenCascade.js, before they would even consider upgrading. So, I think the ball is in my field, here...
• Finally, there would be the option to enable debugging and assertions in Emscripten. Then you would probably get a stack trace including function names etc. for your errors. However, these things come with drastic file size and performance penalties and would require you to fork the library.

To sum this up: I think it should be possible to support Exceptions without too much effort. I have to finish a few things and finally release the next major version which would hopefully (among other things) allow an update to CascadeStudio. Distributing debug builds is not something I am planning to do as of right now.

[zalo]

Doesn't look like the new OC.js helps with this particular kernel error...

There's a workaround that I posted in the other thread, but I think it's just OpenCascade being weird and not any particular implementation detail...

[donalffons]

Thanks! I think I want to look at this error a bit closer at some point. I'm curious if OpenCascade itself gives more information on what's going wrong and why with some kind of exception message...

[timbod7]

Thanks for the reply.

cascadestudio (via hackaday) was my entrypoint to this space. But I'm keen to build some tooling of my own.

Next time I see an issue like this, I might try porting the code to a bare example in opencascadejs, so I can look at debugging in more detail.

[zalo]

If you're talking about the iterator syntax, there are a few examples of related things in CascadeStudio.

The aspect where I call oc.TopoDS.prototype.Solid() on the current element is just to get a version of that solid that can be used outside the loop (may not be necessary for adding to the BRep_Builder).

[donalffons]

I assume aRootLabels is of type TDF_LabelSequence?! In this case, the following might work (untested):

const aBuildTool = new oc.BRep_Builder();
aBuildTool.MakeCompound (aCompound);
for(let i = 1; i <= aRootLabels.Length(); i++) {
  const aRootLabel = aRootLabels.Value(i);
  const shape = oc.XCAFDoc_ShapeTool.GetShape_2(label);
  if(!shape.isNull()) {
    aBuildTool.Add(aCompound, shape);
  }
}

The TDF_LabelSequence::Iterator syntax is currently not supported directly by OpenCascade.js but if you need to access it, there might be a way usingadditionalCppCode (e.g. a typedef or some other construct).

[weepingtown]

It seems to work. I will test it next week. Thank you very much for your reply.

[weepingtown]

If you're talking about the iterator syntax, there are a few examples of related things in CascadeStudio.

The aspect where I call oc.TopoDS.prototype.Solid() on the current element is just to get a version of that solid that can be used outside the loop (may not be necessary for adding to the BRep_Builder).

Very helpful.
In fact, what I'm doing is reading a step file and rendering it in frontend with three.js. Cascadestudio provides rich examples, and I'll be reading your work carefully over the next few days. Thank you so much for your great job.

[weepingtown]

hi,
Just now, I verified your suggestions, and they all work properly. Thank you very much, @zalo @donalffons .
As zalo says, iterators and BRep_Builder are not really necessary for me. I actually just need aRootLabels.First().

During the test, I found an issue. When a node without triangulation data exists in the .stp file, the RWGltf_CafWriter will skip this node. However, in the generated .gltf file, the mesh index of this node is not updated accordingly. As a result, the gltf file cannot be parsed properly.
I used Open Cascade 7.6 to create a C++ demo program for verification and found that the problem did not recur.So I guess it's a problem specific to opencascade.js. I'll submit an issue later to explain this in detail.

[donalffons]

Just another remark about exceptions: I recently made some prototyping with "native" WASM exceptions (which is behind a flag in Chrome since a few days). I experienced a file size increase of 24% for a custom build of the library. Also, chrome crashed during most of my testing (v8 issue is here). When it did not crash, it seems like the performance impact was small.

That makes me very hopeful that we will have proper support for exceptions at some point in the not too distant future. However, I think we would either have to wait for other engines (firefox, node, safari) to catch up or distribute OpenCacade.js in different "flavors" (e.g. LTS, dev, multi/single-threaded, Wasm64-enabled at some point in the future, ...?). Not sure, but that's probably more of a long-term problem...