State and completeness of bindings?

[gvcallen]

I am looking to write a MoM electromagnetics solver in Rust (or at least implement the very basics) for personal experimentation. What is the current state and maturity of the bindings, given that I will modeling relatively simple geometry, but will probably require computing some geometric intersections, unions etc.? Should I rather use opencascade-sys for now, or are the bindings at a state where I would be able to accomplish what I need to without too much hassle? Thanks!

[bschwind]

Hey, thanks for asking! opencascade-sys currently are the bindings, but they don't cover the entire OCC API.

I've been writing them with an "implement as needed" approach so coverage is very piecemeal right now. Simple geometry modeling and boolean operations should be well supported though. The best place to look at current supported features would be to browse through the examples directory.

I've been busy with a move and haven't had much time to devote to the project but I want to pick it back up again some time soon.

In the meantime, as you're implementing your solver and if you decide to use this crate, feel free to open PRs to add functionality you need in the bindings. I'm happy to test and merge them as you go :)

[gvcallen]

Awesome thanks for the reply!

Sorry, by bindings I initially meant the high-level wrapper API i.e. as in these docs. Im glad at least the low-level bindings (opencascade-sys) will support my use-case, so I will be using your library either way. My question is now whether or not the wrappers support the same functionality, and therefore should be preferred, or I should stick with the sys crate?

Cheers,
Gary

[bschwind]

Hey Gary, sorry for the late reply on this - just so I don't give any wrong impressions, you should know the sys crate is currently written by hand without any sort of automatic tool (aside from cxx.rs). So if you need a particular function from OCC and it's not already there, you'll also have to add the binding for it.

I'm hoping a better solution to this will come along and trivialize the problem, but until then that's the current state of things.

So yeah, currently a lot of manual work, and not very fun to use directly as the crate is quite large and takes awhile to compile.

I'm hoping to address the usability issues by having a thin, high-level API on top which compiles down to WASM and is interpreted by the viewer application, so code model iteration is quick and easy.

To answer your question directly, I would recommend using the high level wrappers as opposed to the sys crate. The sys crate bindings are not ergonomic to use and will quickly become a pain. Ideally if you add new bindings to the sys crate, a corresponding higher level wrapper would also be added.

I'm happy to guide you in writing those bindings if you choose that route. Let me know if you have any other questions!

Cheers,

-Brian