some ocaf stuff

[ericsink]

I added some OCAF stuff to the lower layer. This is my first PR to this repo, so I'm not confident I am following existing patterns. Feedback welcome.

[ericsink]

I'm not sure I like the naming I chose for TDF_Label_Displace as a way to call TNaming::Displace.

[bschwind]

Hi @ericsink, thanks for the PR!

Out of curiosity, what functionality do you want from OCAF? Up until now I've been focused mostly on the geometric processing of OCCT, while writing my own stuff when I need 3D visualizations or other things.

Additionally, as I'm sure you have learned, the organization of these bindings is quite a mess, and involves a lot of manual work. I'm currently working on an approach to automatically generate bindings for opencascade so that you can simply point the build to a list of OCCT packages and the binding generator does the rest. That could allow for some interesting things, like using cargo feature flags to selectively include or exclude modules so that you don't end up building and linking things you don't need.

[ericsink]

Out of curiosity, what functionality do you want from OCAF?

I need (or think I need) a way to reference solids and their faces by names. I find the OCAF API to be ... extremely unintuitive, but it does seem designed to solve my problem.

[bschwind]

I need (or think I need) a way to reference solids and their faces by names

Might be naive of me, depending on the specifics, but could you store a HashMap<String, Shape>? Or do you need something that tracks features even if the topology has changed? From a brief skim it seems like the OCAF labeling stuff handles the latter case well.

[ericsink]

Or do you need something that tracks features even if the topology has changed?

I think the answer to this is "yes", but I'm not too familiar with OpenCascade, so I'm still figuring all that out. I was originally hoping that HashMap<String, Shape> would work, but I got the impression it would not, so I started down the OCAF path.

Example: Suppose I have a box B, a shape I got from Shape::box_with_dimensions(). Then I obtain a Shape reference F to one of the faces. If I translate or rotate B, is F still valid? How about if I do a boolean operation, like constructing a cylinder a drilling a hole through B?

I don't have clear answers, but I figure it makes sense to assume that any operation might cause the face reference to become invalid, so I needed a way to work with names, as a form of indirection.

[bschwind]

@ericsink makes sense, and in that case the OCAF functionality might be what you need. I'm pretty sure if you modify a face like that (drilling a hole, for example), then that F and the face with a hole drilled in it, would be different. Translating or rotating might be fine though, I've never tried that.

For most of the CAD stuff I've been doing with this library, after an operation that changes the shape, I then query it in some way to get a particular face I want. So if I drilled a hole in the face of a box, I would find that face again by requesting the farthest face along the direction the drill was made. That's not going to be fun to do in all cases, so I wonder how well the OCAF equivalent works.

[ericsink]

Those remarks raise my confidence that I'm on the right track with OCAF.

Anyway... based on what you've said about your new approach to the bindings, I'm guessing you can just close this PR? I can keep an eye on this repo and later figure out how to appropriately submit any changes if needed.

[bschwind]

@ericsink yes, the automated bindings are the next thing I hope to complete, so I'd recommend giving OCAF a try on your fork and revisiting this when that's done. I'll try to remember to update you on this PR once it's done. I'd be interested to hear what you discover with OCAF, too.

[ericsink]

I'd be interested to hear what you discover with OCAF, too.

I've been experimenting with non-OCAF approaches for keeping track of things, and I'm getting much better traction. OCAF seems like it was designed to solve the kinds of problems I have, but I just don't get along with its API very well.

[bschwind]

Yeah I've been skeptical of it from what I've seen so far. Thanks for the update on it!

[Ben-PH]

I've been looking into this. I'm building an application on top of OCCT using this crate to interface into it. Up to this point it's been mostly UI stuff with some super basic PoC calls to the geometry kernel, but I want to do things the "correct" way as soon as possible. I don't want to wind up in a nightmare scenario dealing with topo-naming headaches.

PR #222 Surfaces a minimal api into TdfData and friends, and have used undo/redo as a reference use case.

I'd be interested to hear what you discover with OCAF, too.

I've been experimenting with non-OCAF approaches for keeping track of things, and I'm getting much better traction. OCAF seems like it was designed to solve the kinds of problems I have, but I just don't get along with its API very well.

Here's my take and story: I went into this project of mine thinking it would be heavily constrained by the topological naming problem, and when that becomes too burdensome, at which point interface with the OCCT geometry backend in a way that it can be swapped out for something like parasolid, and eat the proprietary dependency shame/consequences. I've since learned that the topological naming problem isn't an OCCT thing, but a FreeCAD thing, because they made some design decisions back in the day, and everything has been a cataclysmic fuster-cluck when it comes to stability in topological labels. Things have improved dramatically with the upstreaming of realthunders work on this problem, but by my understanding, it's still fundamentally broken.

OCCT, however, surfaces an api that allows you to build an application that doesn't need to be broken. It doesn't solve the problem of not being able to read the mind of the designer, but when you modify the history in a way that breaks the "topology story", the data is all there to extract a clear understanding of what broke, why, where, how, etc. This allows the application to construct their own topology repair engine/story.

...and as far as I'm concerned, not having that available in idiomatic rust is effectively a hard-veto on my project being able to exit the "experimental and/or toy" catagory.

As for how the different toolings come together, this is my understanding. There's probably a few unintentional lies in there, but I'm confident it's "correct enough to illustrate the problem-space"

1. At the bottom you have geometry. These are just individual parts such as surfaces and edges. If you only have geometry, you cannot construct a cube, you can only collect some faces and give them places in space that their boundaries happen to coincide to look like a cube if you render it
2. geometry is wrapped by topology: here you have the following tower of mathematical properties

• a compound made up of multiple solids
• a solid is made up of at least one closed shell
• a shell is made up of at least one closed surface
• a surface is made up of at least one closed wire
• a wire is made up of at least one closed edge
• an edge is a line that is closed by 2 vertices (I think of a loop-wire as a single edge where the two vertices are coincident
• and a vertex is axiomatic: it just is

3. Sitting adjacent to a topology object are other tools, such as TdfData organises attributes in a way that records all the operation on a shape in a way that gives meaningful information, such as enabling undo/redo, feature selection, model healing
4. object that get passed around, such as deltas (produced by a transaction) which can be pushed to a TdfData structure to record an operation, or popped from it and applied to a shape to revert an operation.

Maybe there's a way to put something together that's better, or even use parts of OCCT with your own alternative inputs, but I was convinced to just go with OCCTs "canonical approach" when I learned that the french nuclear power industry uses applications built on top of OCCT for critical engineering work, and I'm assuming they do it the OCAF way: if it's good enough to meet their requirements, then that's good enough for me.

Here is probably where it gets really interesting for you, @bschwind : The OCAF way of doing things has a well-defined structure of encapsulating the evolution of a model. I haven't looked into the question of using that to build a git-like framework to provide version control and collaboration, but It seems to hold promise as a starting point for such a system that works in both the code-CAD and gui-style-CAD without being mutually exclusive. I don't think its a wild speculation that a robust implementation could serialize a Tdf object into a reasonably idiomatic domain specific language file, and visa versa.