Topological Naming (another take)

[ezzieyguywuf]

Realthunder recently posted a potential solution for the Topological Naming problem. It is very impressive and, in my opinion, shows a lot of potential. I have posted previously a a potential solution (mostly a proof of concept) in python (though upon further inspection, there are some bugs in that code that I should fix...), as well as an approach (attempting to) utilizing OCC's built-in TNaming functionality.

This post is to showcase a c++ implementation (and improvement) of the python topo namer that I linked above. without further ado, here's a (very crude) gif showing it in action!

freecadTopoFix.gif (398 KiB) Viewed 5430 times

And here's a (equally crude) gif showing the current FreeCAD behaviour:

freeCadCurrent.gif (458.03 KiB) Viewed 5384 times

(If anyone can tell me how to resize these on the forum I can make them a bit smaller)

I'm very excited to show this! I originally wanted to also post a gif of the current behaviour (i.e. the fillet moves when the cylinder is made shorter) but my 'vanilla' version of FreeCAD isn't done compiling yet.(it finished) I also wanted to do a fancy screencast gif, but I wasn't able to make the screencast thing work, so I just took some screenshots and used gimp to make the gif.

Anyway, let me explain (briefly, and at a high level) how this works. I've created a library that (for now) I'm calling TopoManagers which describes a Topological Manager interface (ISolidManager) as well as two concrete implementations of this interface: PrimitiveSolidManager and CompoundSolidManager. This line in a test for the PrimitiveSolidManager shows how the manager can be used to obtain a "constant reference" to a topological edge. Note that this reference is a simple integer, but it is guaranteed to always return the same edge.

I have a TopoManager branch of FreeCAD that shows these managers in action (I have not rebased against master in a week or two, please excuse my excitement to post this as soon as possible.) In particular, notice that I've added a new member variable to Part::PropertyPartShape, as well as a getter and setter for that variable.

The use of this variable (a unique_ptr to an ISolidManager) is easiest shown in Part::Box. You can see that we retreive the ISolidManager, then either initialize it or update it as appropriate. The update is done using a helper class "Occ::ModifiedSolid" which carries information needed to keep track of which faces have changed (or been deleted or generated).

It's that simple! You can also look at Part::Cylinder for another (almost identical) use-case, as well as Part::Boolean for a more complicated use-case (this one uses CompoundSolidManager).

I don't want to get too deep into the technical details of how this works on this post for two reasons: one, my wife is hungry and I need to cook dinner And two...actually, that's the only reason. I will give a little bit of detail though.

The way this works is essentially by using <will insert link later> the method whereby each Edge is described by the two faces that make it up. As such, as long as we know how each Face changes, we can consistently refer to a given edge as "the common edge between FaceX and FaceY". It's that simple! My library simply provides facilities for (more) easily keeping track of these face changes.

I will also briefly mention that the TopoManagers library uses another small (and incomplete) library that I've named OccWrapper. This library provides a set of wrapper classes to Opencascade, namely (currently) TopoDS_Shape and it's derived classes, as well as some helper classes. The helper classes fall in two categories: specialized Occ::Solids (Occ::Box, Occ::Cylinder, Occ::BooleanSolid) that provide facilities for (more) easily keeping track of faces. And then factory classes: Occ::SolidMaker and Occ::SolidModifier (I'm considering merging these into one).

I wrote this wrapper library because I didn't want to keep using BRep_Explorer all the time. The library is imperfect, and wasteful (it makes tons of copies of TopoDS_Shape's). I mostly wrote it to make the writing of TopoManagers easier, but I also feel that it can be improved and extended for more general use in FreeCAD. That's a separate topic though.

So, please, let me know your thoughts, comments, (constructive) critiques and anything else! I can post instructions on how to build the two libraries as well as my FreeCAD branch if anyone is interested.

[ezzieyguywuf]

How to Compile my TopoManagers Branch of FreeCAD

1. Download the OccWrapper library. I'll refer to this downloaded directory as ${OccWrapperDir}
2. Download the TopoManagers library. I'll refer to this downloaded directory as ${TopoManagersDir}
3. Download my TopoManager Branch of FreeCAD. I'll refer to this downloaded directory as ${EzzieyFreeCADDir}
4. Compile OccWrapper
5. Compile TopoManagers
6. Update FreeCAD with OccWrapper and TopoManagers locations
7. Compile FreeCAD

You can download these three projects using git and bash with the following commands:

Code: Select all

~> git clone --recurse-submodules https://github.com/ezzieyguywuf/OccWrapper
~> git clone --recurse-submodules https://github.com/ezzieyguywuf/TopoManagers
~> git clone -b TopoManager https://github.com/ezzieyguywuf/FreeCAD-1/

The following will compile OccWrapper using bash and CMake. Please note, for the cMake find_package to work, these three projects must be located in the same folder. If you ran all three "git clone" commands in the same folder you should be good:

Code: Select all

~> cd ${OccWrapperDir}
~> mkdir build
~> cd build
~> cmake ..
~> make

The following will compile TopoManagers:

Code: Select all

~> cd ${TopoManagersDir}
~> mkdir build
~> cd build
~> cmake ..
~> make

The following will compile FreeCAD

Code: Select all

~> cd ${EzzieyFreeCADDir}
~> git checkout TopoManager
~> mkdir build
~> cd build
~> cmake ..
~> make

[ezzieyguywuf]

I've updated my TopoManager implementation to deal with split edges. Here is the current behaviour in FreeCAD:

cutFilletCurrent.gif (287.78 KiB) Viewed 5206 times

And here is the behaviour with my TopoManager being used:

cutFilletFix.gif (326.31 KiB) Viewed 5206 times

The TopoManager branch of my FreeCAD github repo is up-to-date with this fix. I'll admit that my FreeCAD integration is a bit hackey: in particular, I could not figure out how use FreeCAD's Placement to update my solid manager so I just did it without Placement. I realize I could add some code to the appropriate place in Part::Feature, but the return value on this->getManager() is a constant reference, and since it returns a reference to an abstract base class, Part::Feature doesn't have enough information to make a new one.

This is a limitation in my own understanding of good programming design.

Any way, my FreeCAD integration was not intended to be complete or necessarily elegant. It was intended as a proof-of-concept, or maybe a proof-of-solution. My topological naming solution works irrespective of FreeCAD (though it does need more work, of course), and I merely wanted to show an example of how it could be integrated into FreeCAD to solve this issue that is so near and dear to all of our hearts.

My intent is to generate some conversation about:

a) Is this a good approach? Is this solution one that we feel could be integrated into the FreeCAD code base?
b) If so, what would be the correct way to do this? For now I've tapped into individual Part::Feature's (i.e. Part::Box, Part::Boolean, etc..) but would it make sense to implement my solution more generally?
c) If not, what doesn't work? What could be better/different?

It seems that perhaps there is not a lot of interest in this topic right now (due to the low level of commentary on my original post). I will hold off on future development until others have a chance to review and critique my work. I want to be sure that whatever I work on could eventually be accepted as a permanent fix in the FreeCAD code base, and at this point if I go much further along the path I'm on I feel it'd be too difficult to turn back and make any big changes to my approach.

[chrisb]

It seems that perhaps there is not a lot of interest in this topic right now (due to the low level of commentary on my original post). I will hold off on future development until others have a chance to review and critique my work.

Low interest might be only on the deveopers side. From a users point of view the whole topo naming stuff seems to be the biggest issue in FreeCAD - although improvements are at reach with the new Part Design concepts.

[ezzieyguywuf]

improvements are at reach with the new Part Design concepts.

Can you elaborate on this? Perhaps my time would be better spent getting the Part Design solution "over the finish line" rather than trying to implement something completely new from scratch.

[peterl94]

I am interested in topological naming as a developer, but I'm currently trying to get the mac builds ready for the 0.17 release. I'll have time to review your approach in the coming weeks.

The question on my mind right now is how your approach fits in with what realthunder is doing and with what ickby proposed. I also wonder if your "method whereby each Edge is described by the two faces that make it up" is too simple. I guess then we would also a need a separate facility for making robust references to elements of a sketch.

[ezzieyguywuf]

I am interested in topological naming as a developer, but I'm currently trying to get the mac builds ready for the 0.17 release. I'll have time to review your approach in the coming weeks.

The question on my mind right now is how your approach fits in with what realthunder is doing and with what ickby proposed. I also wonder if your "method whereby each Edge is described by the two faces that make it up" is too simple.

<3 these are exactly the sorts of conversations I'd like to have. Perhaps I am just being a bit impatient.

I think the "method whereby each Edge is described by the two faces that make it up" should be sufficient: topologically speaking, in a valid solid, any Edge should have precisely two faces which share that Edge. If this is not the case, then you have an invalid solid.

I guess then we would also a need a separate facility for making robust references to elements of a sketch.

You are correct. This would be the first step towards creating a "SweptSolidManager", we would first need a "ParametricSurfaceManager" or "PlanarSurfaceManager" or some such. I've already considered this and have a few ideas on how to accomplish this, but again I wanted to take a timeout from further development until I had a chance to discuss my approach with the broader community.

[chrisb]

improvements are at reach with the new Part Design concepts.

Can you elaborate on this? Perhaps my time would be better spent getting the Part Design solution "over the finish line" rather than trying to implement something completely new from scratch.

Your work is as valuable as ever!
What I was talking about is the possibility in PDN to use DatumPlanes and Sketches for external references. That makes a model much more robust by design. The problem which you are tackling still exists as before.

[Jee-Bee]

In creo They say as external references

1. planes
2. faces
3. edges

Just because in that way it is far more stable. By selecting a external reference (model) in sketch when possible Creo tries to get faces.

[emills2]

this looks really good. datum planes and other reference features outside of bodies and sketches help a lot and should be used, but they don't deal with filleting an edge in an obvious way. a lot of the reference features i use for production models (not FreeCAD) are based on existing Brep body features. so if the body features don't track, the reference planes and such won't track either.

i wish i knew more to help. good luck