"Robust References" Redux

[tanderson69]

My intent with the "open" approach was to leave behind enough information and commentary such that if I don't finish, someone else has a good enough starting point to take it across the finish line.

If this is your goal, I would suggest that you get permissions and add your accumulated knowledge to the wiki. As you have already seen by werners links, most forum discussions get lost in cyberspace.http://www.freecadweb.org/wiki/index.ph ... ng_project


As far as your fusion problem, you can try to turn of automatically refine faces in the preferences and see if the problem persists. I don't have that problem here, but this might have been introduced with occt 7. I am on 6.9.1.

Sometimes I feel like no one is watching/listening, lol.

Please consider:

• occt is a beast with poor documentation
• topo naming is difficult problem
• you are relatively new to the forum and people come and go.

All these things way on other developers minds before they are willing to engage.

[ezzieyguywuf]

If this is your goal, I would suggest that you get permissions and add your accumulated knowledge to the wiki. As you have already seen by werners links, most forum discussions get lost in cyberspace.http://www.freecadweb.org/wiki/index.ph ... ng_project

Yes, I suppose I should probably do this. Guess I haven't gotten around to it.

As far as your fusion problem, you can try to turn of automatically refine faces in the preferences and see if the problem persists. I don't have that problem here, but this might have been introduced with occt 7. I am on 6.9.1.

What I showed in the image was actually a shape dump from my test program. I haven't actually done any integration into FreeCAD yet. I just took my best guess as to how to modify a TopoDS_Shape, I thing I used a BRepTool_GTrsf or something.

Sometimes I feel like no one is watching/listening, lol.

Please consider:

• occt is a beast with poor documentation
• topo naming is difficult problem
• you are relatively new to the forum and people come and go.

All these things way on other developers minds before they are willing to engage.

Yes, those are all fair points. I was not exactly complaining. Just thanking marco for his encouragement.

[tanderson69]

What I showed in the image was actually a shape dump from my test program. I haven't actually done any integration into FreeCAD yet. I just took my best guess as to how to modify a TopoDS_Shape, I thing I used a BRepTool_GTrsf or something.

Sorry I missed that. Yes I believe BRepTool_GTrsf converting planar surfaces to spline surfaces has come up before. I think shoogen went a few rounds with that?

[ezzieyguywuf]

Sorry I missed that. Yes I believe BRepTool_GTrsf converting planar surfaces to spline surfaces has come up before. I think shoogen went a few rounds with that?

No problem. I'm not too worried about it, b/c I do plan to eventually incorporate into FreeCAD, and FreeCAD already knows how to handle all that. I'm just doing this for testing purposes. Although, if the FreeCAD solution is to just make a new cylinder, that may make things more difficult, b/c I'd have to write my own functions for finding Generated, Modified, etc. Faces.

[ezzieyguywuf]

So, I've spent some time diving into the innards of the TNaming code (*shudder*) and I don't think it's feasible to create a way to Serialize the necessary data for later DeSerialization. One of the main reasons for this is that the TNaming_NamedShape construct has a TNaming_Node attribute that it calls myNode that seems pretty critical to it's life and operation. This myNode is private, so I don't have access to it. I'd have to modify the occ source code itself, which I don't think is is something we want to do (is it?).

After looking through one of freecad's fcstd files, I think it is reasonable to store enough information in the Document.xml file to re-build the Data Framework when the file is loaded, with minimal overhead. The reason I think this is because, as far as I can tell, the fcstd file is already storing a copy of each TopoDS_Shape in its history as a *.brp file and then reading those brp files back in as TopoDS_Shape. Since the TopoDS_Shape is persistent, all the hard work has been done. The Data Framework is merely a way of storing a tree/hierarchy of these TopoDS_Shapes, and re-building that hierarchy with recovered TopoDS_Shapes shouldn't be too hard (hopefully).

I think the Part Design wb will have a harder time, since I'm not sure if it saves all the solids involved in the boolean operations, or if it just saves the sketch. But at some point, when it rebuilds itself, I assume it has to extrude those sketches back out.

I'm going to focus a bit on trying to get a bare-bones version of this working with FreeCAD, and see where that takes me.

[tanderson69]

Although, if the FreeCAD solution is to just make a new cylinder, that may make things more difficult, b/c I'd have to write my own functions for finding Generated, Modified, etc. Faces.

There really isn't any tools for editing the primitives like we would want, so you will have to make a new cylinder and update the naming structure. Why would updating the naming structure after you have constructed a new cylinder be so much more difficult than the original cylinder construction?

[ezzieyguywuf]

Why would updating the naming structure after you have constructed a new cylinder be so much more difficult than the original cylinder construction?

Only because the BRepBuilderAPI_Transform implements the Modified, Generated, and IsDeleted functions from BRepBuilderAPI_MakeShape. Not a huge loss, I'll just have to duplicate the functionality from those methods.

[ezzieyguywuf]

Update: So, I've been working on incorporating the TNaming stuff into the FreeCAD code base. The current status is that I have successfully added a new class, TopoNamingHelper, which handles some Topological Naming stuff. So far, it can track changes for generated shapes, fused shapes, and filleted shapes.

This class is wholly accessed through TopoShape right now - so, I added an instance of the class to TopoShape and then some methods to TopoShape to access the TopoNamingHelper.

I'm still working on a resolution to this bug. I've made a lot of progress, but I'm stuck on an OCC error right now when the Fillet is recomputed after re-sizing the cylinder. I think it may be because the Edge that is getting passed back from my TopoNamingHelper is not from the same TopoDS_Shape that gets recomputed, but I'm not entirely sure.

Anywho, you can check out the tnaming_ezziey branch on github if you want to take a look. It should compile and run. I rebased it earlier today with the most current FreeCAD/master commit, so the code base should be pretty fresh., It'll throw an error when you resize the cylinder, b/c I'm still working out how to resolve that bug,but in the background, a topological history is being tracked properly, which is pretty neat.

If you want an 'entry point' to the code I've added/changed, I'd take a look at TopoNamingHelper.h as well as FeatureFillet.cpp:81. On line 81 in FeatureFillet.cpp you'll see where I retrieve an TopoDS_Edge from the TopoNamingHelper via TopoShape rather than using the id integer.

[ezzieyguywuf]

Update: Turns out the OCC error was because of some dumb things I was doing. I've refactored the code a bit, the most obvious of which is how I've integrated into FreeCAD. In short, I've minimized the changes to the FreeCAD codebase, so if you do a diff between the tnaming_ezziey branch and the master branch it should be pretty obvious what I've changed and why.

Also, though it may be hard to notice, I've made a huge step forward - I finally understand the TNaming_Selector/Select stuff with the OCC TNaming thing, and I'm finally using properly. I'll probably have to update my TNaming explanation/summary at some point. Right now the next biggest hurdle is I need to figure out a consistent, reliable way of determining which Faces on a solid have been modified/generated/deleted, as right now I have that hard-coded in. This is relatively easy to do if you use one of OCC's BRepBuilderAPI_MakeShape ancestors, but in FreeCAD's case we normally just create a brand new TopoDS_Shape and call that a 'modified' shape. So, that means that I have to somehow compare the geometries and figure what has changed and where.

Either that, or I'll have to tinker quite a bit with the underlying FreeCAD stuff in the Part workbench so that, for example, when Part::Box::execute() is called for a recompute, instead of creating a new TopoDS_Shape it uses some sort of gp_Trsf and a BRepBuilderAPI_MakeShape ancestor so that I can access the Generated/Modified/Deleted methods. I'm not so sure this is a great approach though - I've prototype it, and maybe it's b/c I don't understand gp_Trsf and OCC that well, but my modified shape ended up having a bunch of bspline stuff that didn't quite make sense to me.

Well, that's the current state! Just wanted to bump this thread so that y'all know I'm still on this, albeit at a slower pace. If you checkout the tnaming_ezziey branch, commit 1d28ce9df12c9b8cad1f0e137c25a6c774919037 is the latest as of today. To see the latest changes in action, make a Cube, then fillet any edge/edges except for on the bottom face. You can now resize the cube to your heart's content and the fillet remains in the same place.

Now, I know what you're thinking: that already works in the legacy FreeCAD code. This is true, but in the tnaming_ezziey branch, rather than storing and using an int to refer to the proper Edge when rebuilding, the OCC TNaming stuff is used to store and retrieve the appropriate Edge, so this is the first step to a final Robust Reference solution.

Edit: Rebased tnaming_ezziey branch to latest FreeCAD. Proper commit is now b5a67e90256e88c3926cda5c21799b903d435980. Haven't build it yet to make sure it compiles without errors, but it should...

Edit: yea, it compiles.

[ickby]

Also, though it may be hard to notice, I've made a huge step forward - I finally understand the TNaming_Selector/Select stuff with the OCC TNaming thing, and I'm finally using properly.

Good to hear, I think you are one of only very few people around the globe that understand that framework

I'll probably have to updating my TNaming explanation/summary at some point. Right now the next biggest hurdle is I need to figure out a consistent, reliable way of determining which Faces on a solid have been modified/generated/deleted, as right now I have that hard-coded in. This is relatively easy to do if you use one of OCC's BRepBuilderAPI_MakeShape ancestors, but in FreeCAD's case we normally just create a brand new TopoDS_Shape and call that a 'modified' shape. So, that means that I have to somehow compare the geometries and figure what has changed and where.

That is not exactly true. Basically all TopoShape functions internally use BRepBuilderAPI_MakeShape or derived functions. Then those Generators are queried for the new generated shape and this new shape is returned. You caan easily access the Generator and all modified/generated/deleted Faces etc. inside the algorithms. As it is an enourmus and error prone task to reimplement that logic just move the history building directly into the TopoShape functions. That is the best anyway, as then history is automatically builded and the user cannot forget it.

Either that, or I'll have to tinker quite a bit with the underlying FreeCAD stuff in the Part workbench so that, for example, when Part::Box::execute() is called for a recompute, instead of creating a new TopoDS_Shape it uses some sort of gp_Trsf and a BRepBuilderAPI_MakeShape ancestor so that I can access the Generated/Modified/Deleted methods. I'm not so sure this is a great approach though - I've prototype it, and maybe it's b/c I don't understand gp_Trsf and OCC that well, but my modified shape ended up having a bunch of bspline stuff that didn't quite make sense to me.

Again, I'm not sure why you do not build up the history automatically in TopoShape. Is there any good reason to let it be done in the calling code everytime again and again for every method call to TopoShape?

Well, that's the current state! Just wanted to bump this thread so that y'all know I'm still on this, albeit at a slower pace. If you checkout the tnaming_ezziey branch, commit 1d28ce9df12c9b8cad1f0e137c25a6c774919037 is the latest as of today. To see the latest changes in action, make a Cube, then fillet any edge/edges except for on the bottom face. You can now resize the cube to your heart's content and the fillet remains in the same place.

Definitely awesome work! Thanks for going on with this!