STEP loading assumptions

[g-rauhoeft]

As mentioned in issue #2 I'd like to start implementing STEP loading functionality for truck. I've spent the last week getting reacquainted with ruststep and truck and I've built a set of assumptions that I hope you can confirm for me.

1. STEP parsing currently only loads the data in to a generic structure consisting of Records with Parameters, not in to the concrete structs generated by ruststep, meaning a CARTESIAN_POINT currently looks like this: Simple { id: 22245, record: Record { name: "CARTESIAN_POINT", parameter: List([String(""), List([Real(66.1), Real(-23.2), Real(0.0)])]) } } instead of like this: CartesianPoint { point: "", coordinates: vec![66.1, -23.2, 0.0]}. This would have to be implemented before actually starting STEP importing in to truck.
2. The concrete entity structs are the preferred representation of STEP entities for any programmatic interaction with them.
3. Conversion of the generic structure to the concrete entity structure must be generated for any given EXPRESS schema and output by the ruststep code generator.
4. Work for conversion between concrete STEP structures and their corresponding truck types has begun in truck-stepio/{parse_primitives.rs, impl_curve.rs, impl_surface.rs}

Are these assumptions correct and sufficient to begin implementation?

Best regards and thank you so much for your amazing work!

[ytanimura]

There are several problems with the current ruststep. The biggest problem is that Complex Entity conversion is largely untouched. This problem requires some ad hoc implementations to address. There are other deserialization issues such as Option, Boolean and Logical that will need to be fixed.
In fact, I started a similar implementation just the other day; I can't merge it in right now because I haven't passed CI, but I will try to prepare and merge it in now.

[ytanimura]

Since the scale of development was a bit large, we made a special exception to release the branch we are currently working on, although we do not usually do this. https://github.com/ricosjp/truck/tree/163-step-geometry-manually-primitive
The module "in" in truck-stepio is the relevant implementation. test" module is also being implemented. We would be happy to share something work with you.

[ytanimura]

There is no way to deal with Complex Entity because the problem is inherently difficult, but it seems to be relatively easy to solve for Option, Logical, and Boolean deserialization. Implementing them should make the code look a bit better, but as long as Complex Entity exists, manual implementation of from_data_section will be necessary anyway. This is an unavoidable problem because rationalized B-splines cannot be parsed without implementing Complex Entity.

[ytanimura]

Topology is also difficult, but STEP's requirements for shape are looser than truck's, so suddenly converting to Solid will not work. For example, truck does not allow for Edges with matching ends, and I plan to leave this one as is for a while longer.
I plan to convert the topological data to CompressedShell and CompressedSolid and write code to mesh them directly. For now, we are working toward the goal of displaying STEP in a browser first.

[g-rauhoeft]

Since the scale of development was a bit large, we made a special exception to release the branch we are currently working on, although we do not usually do this. https://github.com/ricosjp/truck/tree/163-step-geometry-manually-primitive The module "in" in truck-stepio is the relevant implementation. test" module is also being implemented. We would be happy to share something work with you.

Thank you very much! I'll look in to it and do my best to get it working.

For now, we are working toward the goal of displaying STEP in a browser first.

That is something we are also trying to achieve. Our current pipeline converts STEP to GLTF via OCCT on the server which serves that to the browser. My aim is to mirror that functionality with truck. The possibility to display STEP files directly is very intriguing though.

There is no way to deal with Complex Entity because the problem is inherently difficult, but it seems to be relatively easy to solve for Option, Logical, and Boolean deserialization. Implementing them should make the code look a bit better, but as long as Complex Entity exists, manual implementation of from_data_section will be necessary anyway. This is an unavoidable problem because rationalized B-splines cannot be parsed without implementing Complex Entity.

Thank you for the pointers! :D

[ytanimura]

I wrote a test with what I have now, so I merged it once and deleted the branch 163-step-geometry-manually-primitive.

If you have something you are developing, please let me know in advance and I will not work on it for a while.

[g-rauhoeft]

Excellent, thank you! I'm still working on the STEP->Truck->GLTF Pipeline and plan on doing so until the end of this month at least. I have a large batch of STEP files that I use as evaluation cases, so if I find anything missing I'll add it and create a pull request. One specific thing I'm currently working on is a high-level API for the STEP->Truck phase.

Also thank you for your excellent examples of macro usage. You do things with them that I never thought feasible. I've learnt so much reading your code.

[g-rauhoeft]

I'm currently working on everything below AdvancedFace in the Entity Hierarchy. Quite a rabbit hole.

[ytanimura]

We created the code to convert OPEN_SHELL or CLOSED_SHELL to CompressedShell. Please refer to it if you still have trouble.