UnboundTypeError: Prs3d.GetDeflection_1

[qouv]

Hello,

When I try to use GetDeflection I get the error below. Do you have any idea how to solve this?

UnboundTypeError: Cannot call Prs3d.GetDeflection_1 due to unbound types: 16NCollection_Vec3IdE

[donalffons]

I believe that should work in the latest version 2.0.0-beta.ae74abe. Instead of Graphic3d_Vec3d (as in the function signature), you should be able to use Select3D_Vec3 instead (they're a differently named typedef's to the same underlying type).

[qouv]

Wow so fast :D

I implemented it like this and works without exception:

const BoundBox = new oc.Bnd_Box_1();
oc.BRepBndLib.Add(aCompound, BoundBox, false);
   
anAlgo.ChangeParameters().Deflection = oc.Prs3d.GetDeflection_2(BoundBox, aDrawer.MaximalChordialDeviation(), aDrawer.DeviationCoefficient());

I was thinking my conversion speed was about this. But nothing changed, it lasts forever for big parts.

How did this sview.ru guys achieved this speed? Do you have any idea, are they using high CPU server or etc. Because their speed is very okay for me.

At first I thought there must be an api or npm package for step2glb. But no :(

OCJS looks like the best option since I am developing nodejs app. I guess I cant run c++ code with my current knowledge.

[donalffons]

I believe this code might have no effect. Can you check if those changes get applied correctly?

anAlgo.ChangeParameters().Deflection = 0.123;
console.log(anAlgo.ChangeParameters().Deflection); // might print something else than 0.123;

This problem is tracked in #125 and I'm still in the process of figuring out how a good workaround would look like.

For meshing, I would recommend to use this syntax instead until that problem is fixed:

new oc.BRepMesh_IncrementalMesh_2(aCompound, linDeflection, false, angDeflection, true);

Generally, when there are things that currently cannot be implemented in JS, you should be able to work-around most problems with writing helper functions in C++ and creating a custom build.

Regarding your performance problems:

1. Did you do some actual time measurements? How much time does initOpenCascade / reading & transferring STEP / meshing / exporting to GLB take? If you're using NodeJS, maybe your problem is the time required for instantiation, i.e. initOpenCascade?!
2. Make sure you're using a recent version of NodeJS - the newer the better. Older NodeJS versions tend to suffer from extremely long startup times for large WASM projects. But even in newer NodeJS versions, startup times can be quite long. A good solution would be if NodeJS would be able to cache the compiled WASM, see this issue. But that still seems to be work-in-progress.
3. If you want you can share a STEP file here and I might have a look.

Generally if you want to convert large STEP files and you don't need to do that in a browser, C++ might be the better Option. OCCT has an example for that.

[qouv]

You are right.

console.log(anAlgo.ChangeParameters().Deflection); prints 0.001 instead.

And this one line saved me:

new oc.BRepMesh_IncrementalMesh_2(aCompound, linDeflection, false, angDeflection, true);

I guess it will do until we hire someone writes C++. Now I will just work on optimizing GLB file for 3D web view. Thank you very much.

1. Triangulating was the one takes time. Initiation (initOpenCascade) takes around 30 sec. I will try to initiate at first with node app start.
2. I will update Node version, if you say so! And share here if I see any difference.
3. Not a specific file. I tried many and decided it was about size. Small parts were no problem.

I know there will be always performance differences between C++ and JS. I need a quick solution for this project and found it. Also upgrade my AWS server to compute optimized one.

You guys are doing great job implementing OCC to JS for the community. Keep going!

[donalffons]

Maybe as a point of reference: I'm working on a browser-based STEP file viewer using OpenCascade.js right now. Loading a 520MB file takes around 13 min on my fairly fast laptop (10 minutes of StepCAFControl::Read and StepCAFControl::Translate and 3 minutes of meshing). I believe that file size is pretty close to the maximum feasible size...

Support for native WASM exceptions landed in Emscripten a couple of days ago. Once that improvement is integrated into OpenCascade.js, I expect loading times to improve significantly.

Not to try to make this into a sales pitch, but if your company ever needs support in OpenCascade-related topics, you can hire me ;-).

[qouv]

I think time is not a problem anymore. I am dealing with mesh count. Big files come up with over 10k+ meshes and creates unnecessary draw calls. I need to reduce mesh number somehow.

We are at a very early stage right now. But you are on my mind though. Maybe after the investment round :)