
Thu, 06/20/2024 - 03:21
When using RWGltf_Writer
, I am able to export glb files that contain one mesh entity per BREP face in my CAD models; however, it seems there is no support for encoding discretized BREP edges in the glb export, nor support for encoding vertices from the CAD models, despite the capability by the file format to do so per the glTF 2.0 specification. Am I missing a step in the meshing of my CAD model or in the usage of RWGltf_Writer
that would enable me to export discretized edges and vertices in addition to the faces?
For reference, I am basically doing the following:
std::string input_step_filepath = "path/to/step/file.stp";
STEPCAFControl_Reader reader;
reader.ReadFile(input_step_filepath.c_str());
Handle(TDocStd_Document) imported_document = new TDocStd_Document("BinXCAF");
reader.Transfer(imported_document);
Handle(XCAFDoc_ShapeTool) shape_tool = XCAFDoc_DocumentTool::ShapeTool(imported_document->Main());
TDF_LabelSequence root_labels;
shape_tool->GetFreeShapes(root_labels); // Assume for simplicity there is only one root label.
auto& root_label = root_labels.First();
TopoDS_Shape root_shape = shape_tool->GetShape(root_label);
IMeshTools_Parameters mesh_parameters;
mesh_parameters.Deflection = 0.01;
mesh_parameters.Angle = 0.5;
mesh_parameters.Relative = Standard_False;
mesh_parameters.InParallel = Standard_True;
mesh_parameters.MinSize = Precision::Confusion();
mesh_parameters.InternalVerticesMode = Standard_True;
mesh_parameters.ControlSurfaceDeflection = Standard_True;
BRepMesh_IncrementalMesh mesh_builder(root_shape, mesh_parameters);
TColStd_IndexedDataMapOfStringString gltf_metadata;
std::string output_filepath = "path/to/output/file.glb";
RWGltf_CafWriter gltf_writer(output_filepath.c_str(), true);
gltf_writer.ChangeCoordinateSystemConverter().SetOutputLengthUnit(0.001);
gltf_writer.ChangeCoordinateSystemConverter().SetInputCoordinateSystem(RWMesh_CoordinateSystem_Zup);
gltf_writer.Perform(imported_document, gltf_metadata, Message_ProgressRange{});
Thu, 06/20/2024 - 09:49
Hello, you are right. Current version of RW GLTF have no full support of some features available in specification. Curves, animation, points, text are not supported. If it important for your projects, you can share your needs by survive. It helps us to analyse the interest in different functions:)
https://dev.opencascade.org/content/shape-future-occt-your-opinion-matters
Best regards, Dmitrii.
Thu, 06/20/2024 - 19:08
Hi Dmitrii,
Thanks for confirming. I will submit a survey but I can't afford to wait a long time for this functionality to be implemented. What is the process to PR into the OCCT repository? I'm happy to add this functionality myself.
Thu, 06/20/2024 - 19:50
Nice to hear. The process for contribution described here: Get involved | Open CASCADE Technology If you have any quastions you are free to ask.
Best regards, Dmitrii.
Thu, 07/25/2024 - 10:30
Hi everybody,
i'm glad someone else faces the same problem. The edges are absolute neccessary for our usecase. Are there any updates on this topic?
Best regards, Max.
Sat, 02/08/2025 - 10:55
Hello. New OCCT 7.9 have that feature support. It was part of new "Bug fixing and improvements" request.
https://github.com/Open-Cascade-SAS/OCCT/issues/229
Best regards, Dmitrii.
Wed, 02/12/2025 - 16:22
Hey Dimitrii,
really nice to hear that. We're really looking forward for the final 7.9 release.
Were currently using OCCT via the pythonocc stubs - were running a python service on a k8s cluster and this works so far :-)
You may allow me another question here:
As i mentioned were using the pythonocc stubs for running a occt based backend application for the following purposes:
- Loading/merging multiple STEP files and arranging them
- Converting STEP files to GLB files to make our 3D models more usable within web applications
- (Planned) Export image of a loaded step file in isometric form to use them as "thumbnails" in web applications
Would you use this setup for our tasks or would you choose something other?
Best regards, Max.
Wed, 02/12/2025 - 16:47
The task is very trivial and can be done by any language wrappers, simple C#, Java (done by C PInvokes and pure C bridge) or some bash script + C++ application. I don't see a reason to use a huge pythonocc on that task.
Merging multiple step files without extra conversion better to do on c++ level (before wrapping), it is simpler.
Best regards, Dmitrii.
Wed, 02/12/2025 - 16:53
Some time ago we decided to go with this setup. But were open to change it if we see some "easier" solution. I've searched for the C# wrappers long time ago, but i did not find anything. Are you able to give me a link to them? Are they up-to-date? Is there something we can use in a commercial context?
I really appreciate your fast response!
Best regards, Max.
Wed, 02/12/2025 - 17:36
OCCT have C# wrapper (commercial extension). But in your case you can work with native PInvokes (wrap by C only high level API). Or just write a simplest console application on c++ with bash as an interface, it will work perfect and without any issues of wrapping. I plan to prepare sample about that, but have no time.
Commercial C# wrapper: Wrappers - OCCT3D No so much details, but it is C# wrapper around C++ code for Linux/Windows.
OpenSource Windows only sample: OCCT/samples/CSharp at master · Open-Cascade-SAS/OCCT
Best regards, Dmitrii.