Topological Naming

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Topological Naming

Postby jriegel » Sat Sep 15, 2012 10:33 am

Jrheinlaender and Werner brought it on the agenda, cause its a shortcoming of FreeCAD:
viewtopic.php?f=10&t=2656

Since a very important topic for a CAD modeler I started a development project docu:
http://www.freecadweb.org/wiki/index.ph ... ng_project

I did some research whats state of the art, and formulated some aims. For me its more important then the Assembly.
Cause the usability of the PartDesign depends greatly on a robust Naming. So I would put the Naming on the top of the list for 0.14.

As next I will gather some examples from the papers and from user.
Stop whining - start coding!
wmayer
Site Admin
Posts: 16649
Joined: Thu Feb 19, 2009 10:32 am

Re: Topological Naming

Postby wmayer » Sat Sep 15, 2012 11:48 am

(optional) memory optimized data structure to keep only changed faces/edges in each modeling feature. <p> This will become important when the models get bigger. Its not efficient to copy most of the shape just through. Would be much more effective to share the unchanged faces/edges between Feautures and copy only whats changed.
I just wonder whether OCC does this already internally with its T-shapes.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming

Postby jriegel » Sun Sep 16, 2012 7:46 pm

wmayer wrote: I just wonder whether OCC does this already internally with its T-shapes.
Yes I think so to. The main problem is that at the moment this kind of sharing is killed on saving/restoring the document, since
every Feature and PropertyShape saves a .brep. We would need an other kind of persistence to preserve this kind of sharing.
Also in some features we do copies of the shapes, and there we loose the also the sharing.

OCAF has a concept to store only one TopoShape for a couple of features. A kind of shape registry. We could do a similar concept for
the Body feature...
Stop whining - start coding!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Topological Naming

Postby jrheinlaender » Mon Sep 17, 2012 4:51 am

Here is another feature which I think we should support. It works like this in Pro/E if I remember correctly, and is called something like "replace reference".

Suppose you have sketched a simple square of four lines and extruded it to a box. Then you put a fillet on one edge of the box.

Now, you can go into the sketch, draw an arc, and choose "replace reference" to replace one of the straight edges of the box with the arc. The fillet will update and now execute on the curved edge.

This is one of the reason why I think that all references must ultimately be anchored in a sketch entity.
ivanzero
Posts: 30
Joined: Wed Jan 25, 2012 9:35 pm

Re: Topological Naming

Postby ivanzero » Mon Sep 17, 2012 9:19 am

Hi jriegel,
I'm glad that Naming is on the top of the list for 0.14. This is a big job, and if I may suggest, you should first start from Sketcher. In Sketcher this can be done quickly and can gain experience for the consideration of the whole problem, after all, almost all of the parent-child relationship starting from the Sketcher.

Ivan
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming

Postby jriegel » Mon Sep 17, 2012 11:29 am

Its right, a consistent naming nearly always starts with a Sketch. The first naming on the Sketch is the basis, but not that complicated.
All the cases later in the modeling history are somewhat more tricky.

@Jan
Yes it surly possible to question the user about a naming transition, but its IMO the last resort if the automatic is not able to determine it.
In the sketcher is asking maybe feasible, but if in recompute of a complexer modeling history every second feature ask for a substitution,
its not that funny.

In your example its rather easy, the newly created arc has the same boundary vertexes, so the automatic should do the substitution just fine.
But there may be examples where we want to give the Sketcher user more control about substitution of names....
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: Topological Naming

Postby logari81 » Mon Sep 17, 2012 11:36 am

one basic question:
do we want the name indexes to be contiguous or not?
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming

Postby jriegel » Mon Sep 17, 2012 12:30 pm

Continuity is not possible. If we want to keep the names stable we will have holes in case of deletion in the model sub-shapes.
But indexes in the current form will have to die anyway. The interface will be a string (sub-shape name) and this string can only
be resolved to a TopoDS_Shape by the owning Part::TopoShape class. All other access is not guarantied to work past a recompute.

And yes, that means we have then to eliminate all places in the code where the index of TopEX_Explorer is used to identify sub-shapes...

We can deliver list to iterate, but there we will have changes over time.
Stop whining - start coding!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Topological Naming

Postby jrheinlaender » Wed Nov 14, 2012 4:41 pm

OK, I have implemented a draft on github branch jrheinlaender/TNaming. It works about 90% for fillets on simple combinations of Pad/Pocket. But before I detail it further I'd like to open the design for discussion.

All the hard work is done in the TopoShape. For example, the workflow (simplified) in Pad::execute() is:

Code: Select all

// Initialize TopoShape
Part::TopoShape thePad(sketch->Shape.getShape(), Shape.getShape());

// Create face from sketch
thePad.makeFace(sketchshape);
thePad.move(invObjLoc);

// Make prism from face
thePad.makePrism(dir, L, L2, Midplane.getValue(), Reversed.getValue());

// Fuse with support if there is one
if (!theSupport._Shape.IsNull())
        thePad.makeFuse(theSupport);

// Store TopoShape
Shape.setValue(thePad);
This creates the geometry and the naming information inside the TopoShape. This is how PartDesign::Fillet makes use of the information:

In Command.cpp:

Code: Select all

Part::TopoShape TopShape = base->Shape.getShape();
...
// Register shapes for topological naming
TopShape.registerSubShapes(SubNames);
base->Shape.setValue(TopShape);
In Fillet::execute():

Code: Select all

Part::TopoShape TopShape = base->Shape.getShape();
...

// Update the topological naming information (modifies TopShape)
std::vector<std::string> shapes = TopShape.resolveSubShapes(SubVals, Part::TopoShape::method_Fillet);
SubVals.clear();
SubVals = shapes;
Base.setValue(link, SubVals);
base->Shape.setValue(TopShape); // Make sure the updated naming information is stored!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Topological Naming

Postby jrheinlaender » Wed Nov 14, 2012 5:03 pm

Attached an example of how I test it (sorry for the .zip, didn't have time to figure out web storage just now).

If you edit the sketch of the cylindrical pocket and move it around, the fillet will follow it anywhere.
Attachments
tnaming.jpg.zip
(17.27 KiB) Downloaded 58 times