Topological naming problem and TechDraw

[ToniTen]

The Topological Naming Problem has been the bane of my experience with FreeCAD in general, and yeah, I've since learned how to make stable models, plus now RealThunder has made the models more resilient to changes in his branch. However, the issue remains when it comes to TechDraw, where any changes to the geometry will result in all dimensions moving to random parts of the model. Unlike with 3D modelling, where there are a few good practices to make your model resilient to changes, I have not found a way to make my drawing similarly adapt to changes in the model.

Let's split the discussion in two parts:

• Is there any way, right now, to make TechDraw drawings not so fragile? I understand the problem, and I understand that if I say add an extra hole on a square face, or if I add an extra bevel, I'm adding edges and vertexes to the 3D projection, but for 3D geometry, by using datum objects, master sketches, etc, I've managed to make things not break that easily.
• Can the solution to the TNP that RealThunder is now trying to integrate into FreeCAD be adapted to also make TechDraw drawings less susceptible to the TNP? I understand that it's not just a matter of taking the same algorithm and applying to TechDraw, but maybe some of the ideas can be used in TechDraw?

One thing that IMHO would change the perception of users would be to not have all the dimensions dance around randomly when the geometry changes. Maybe just don't move them, unlink them from the geometry and flag them as having a problem in the tree view? I feel like detecting that there's a TNP issue should at least be easier than having a real fix, and leaving the dimensions in place, even if unlinked to geometry, would at least serve as a guide when re-creating them.

[domad]

.............
One thing that IMHO would change the perception of users would be to not have all the dimensions dance around randomly when the geometry changes. Maybe just don't move them, unlink them from the geometry and flag them as having a problem in the tree view? I feel like detecting that there's a TNP issue should at least be easier than having a real fix, and leaving the dimensions in place, even if unlinked to geometry, would at least serve as a guide when re-creating them.

Merry Christmas to FreeCad and the Community!
+1

[wandererfan]

[*]Is there any way, right now, to make TechDraw drawings not so fragile? I understand the problem, and I understand that if I say add an extra hole on a square face, or if I add an extra bevel, I'm adding edges and vertexes to the 3D projection, but for 3D geometry, by using datum objects, master sketches, etc, I've managed to make things not break that easily.

The only recommendation I've ever heard is to delay adding Dimensions until the 3D model is finished, or nearly so.

[*]Can the solution to the TNP that RealThunder is now trying to integrate into FreeCAD be adapted to also make TechDraw drawings less susceptible to the TNP? I understand that it's not just a matter of taking the same algorithm and applying to TechDraw, but maybe some of the ideas can be used in TechDraw?

I am definitely not an expert on @RealThunder's work, especially the TNP aspects. I suspect that maintaining shape history across the projection/hidden line removal step will be very difficult.

Maybe just don't move them, unlink them from the geometry and flag them as having a problem in the tree view? I feel like detecting that there's a TNP issue should at least be easier than having a real fix, and leaving the dimensions in place, even if unlinked to geometry, would at least serve as a guide when re-creating them.

One of the design principles for TechDraw was that drawings should change whenever the source geometry changed. Dimensions currently don't really remember their own location, Location is recomputed using the geometry references every time the view changes. If a reference no longer exists, an error is generated. If, for example, "Vertex4" is no longer the correct end point and "Vertex5" should now be used, this is not detected.

I'm afraid I don't see a quick fix to this problem.

[Roy_043]

Maybe a command can be created to attach existing dimensions to (special?) cosmetic vertices?

[ToniTen]

The only recommendation I've ever heard is to delay adding Dimensions until the 3D model is finished, or nearly so.

Yeah. I understand. However, let me explain why this is not always possible:

• You design your model as normal, finalize it, and then create your TechDraw sheet, following all the relevant local norms (ISO, etc), add all the relevant annotations, detail views, cuts, etc.
• You send your drawing to someone who will machine it as per your instructions
• The machinist then replies saying X feature is too complicated/he doesn't have the tools/the machine that does that part is booked for 3 months or is broken and the maintenance guy isn't available because of the pandemic
• You alter/remove that feature to suit the machinist's needs

The problem is that now, you basically need to restart the drawing from scratch

Code: Select all

I am definitely not an expert on @RealThunder's work, especially the TNP aspects.   I suspect that maintaining shape history across the projection/hidden line removal step will be very difficult. 

I don't expect the algorithm to work unchanged, but after reading how his solution works, I wonder if a similar scheme would be possible.

Then again, I find the way TechDraw does the projection and hidden line removal to be almost akin to black magic in how clean the end result is (I usually export to SVG and then tweak with Inkscape, and I almost cry when I see clean curves instead of polygons you often see from other CAD suites, or I see that there aren't eleventy bajillion lines stacked over one another, etc etc). It's so much nicer. It's part of the reason why I like working with TechDraw so much, despite it sometimes being a little rough around the edges.

One of the design principles for TechDraw was that drawings should change whenever the source geometry changed. Dimensions currently don't really remember their own location, Location is recomputed using the geometry references every time the view changes. If a reference no longer exists, an error is generated. If, for example, "Vertex4" is no longer the correct end point and "Vertex5" should now be used, this is not detected.

I'm afraid I don't see a quick fix to this problem.

I guess having some sort of caching mechanism on the projected view, and then if the number of edges/vertices in the view changes, halt the update to the view until the user manually triggers it? or a way to make a dimension "cosmetic" by unlinking it from the geometry, so if the geometry changes, the dimension doesn't change with it? I guess I'm just throwing ideas at the wall to see what sticks, and I don't think I'm qualified to do this, as I don't know enough of the internals.

[CarloGreen]

This topic is also closely related: https://forum.freecadweb.org/viewtopic.php?f=35&t=54897

[aapo]

Dimensions currently don't really remember their own location, Location is recomputed using the geometry references every time the view changes. If a reference no longer exists, an error is generated. If, for example, "Vertex4" is no longer the correct end point and "Vertex5" should now be used, this is not detected.

I think the best heuristics would be to save the 2D-coordinates of each endpoint of a Dimension when creating the Dimension. Then, when the 3D-model is updated, the heuristics would check whether the saved 2D-coordinates still match the 2D-coordinates of the Vertices of the Dimension.

• If yes, then the vertices are correct, continue as usual.
• If no, then either the update has mangled the vertice ordering, and it's a wrong Vertice for this particular Dimension endpoint; or the geometry has really changed, and we should move the 2D-coordinates accordingly.

In case the saved and newly computed 2D-coordinates don't match, deciding between whether the 2D-coordinates have really changed, or if it's just the dreaded topological shuffling problem, should be straightforward in most cases:

• If there is (any) Vertice at exactly in the position of the saved 2D-coordinates, then most likely the Vertice has not moved, but it's number has changed and it should be the one at the old 2D-coordinates. Update the dimension endpoint Vertice number accordingly.
• If there is no Vertice at exactly in the position of the saved 2D-coordinates, then the Vertice has really moved. Then, use the old Vertice index. If this also fails, find the Vertice having closest coordinates to the old saved 2D-coordinates.

The advantages of such algorithm would be:

• It would work perfectly when the Document would be updated, if the 3D-model has not changed. This would be an advantage after loading a Document with a different version of FreeCAD (e.g. compiled with different version of OCCT), or changing options for projection style affecting number of vertices and edges (hidden lines, etc).
• It would work pretty well, or at least as good as currently, when really editing the 3D-model: all the dimensions not affected by the 3D-change would stay unaffected by the topological problem, and there's at least as good change as before to end up with correct choices for the affected dimensions.
• No broken dimensions; as the algorithm would find a Vertice closest to the old position if all else fails.

Disadvantages would be:

• If the 3D-model is edited so that the bounding box of the model changes, it changes the center of the projection. Then, all saved 2D-coordinates would be wrong in regards to the new centerpoint, and the heuristics would work quite badly (as badly as the old heuristics, which always tries to just keep the Vertex indices).
• It is possible that a wrong new Vertice would be exactly at the coordinates of the old saved point, but this is very unlikely in practice.

Anyways, such a change would be possible to add, and it would help in many practical cases (when adding or removing stuff not affecting the model bounding box). Also, it'd give results that would be at least as good as current ones.

[-alex-]

I'm afraid I don't see a quick fix to this problem.

First, glad to see you're back on this forum, I hope everything is OK for you
About TD and TNP I've disscussed about a strategy, see this thread: https://forum.freecadweb.org/viewtopic.php?f=35&t=44786
I'm sure you and @Abdullah can help a lot to shortcut TNP. I have no time right now, I will ping you later if you have some time to give to this project.
Thanks for your attention.

[-alex-]

I'm afraid I don't see a quick fix to this problem.

First, glad to see you're back on this forum, I hope everything is OK for you
About TD and TNP I've disscussed about a strategy, see this thread: https://forum.freecadweb.org/viewtopic.php?f=35&t=44786
I'm sure you and @Abdullah can help a lot to shortcut TNP in TD WB. I have no time right now, I will ping you later if you have some time to give to this project.
Thanks for your attention.

[ToniTen]

I do not have enough knowledge of OCC to say if this would be an unfeasible idea, but maybe this has merit.

Could it be possible to have a "shadow projection" of the geometry that exists before the HLR but isn't visible, where each face, edge and vertex can be traced to the 3d geometry? Dimensions could be attached to this "shadow projection" instead of the result of the HLR algorithm.

Once RT's toponaming solution is merged, you could then attach the toponame tag from RT's work to the edges of this "shadow projection". Then after the HLR has created the cleaned projection, you can iterate over the resulting faces, edges or vertexes and assign all the toponames from the shadow projection that are identical to the new face, line or vertex. This could obviously result in a single geometry element having multiple toponames, but that doesn't seem to be a dealbreaker to me. Since then you would be able to trace back the lines in the post HLR projection to the original geometry, you could attach dimension lines to the projection in a TNP-safeish way. If due to changes in the model, you end up with the toponames given to a given geometry element ending up in 2 or more geometry elements (so for example, you're looking at the top face of a cylinder in the direction of the normal, that has the toponames of both the top and the bottom face of a cylinder, and then it becomes a truncated cone, so half the toponames end up in one projected circular edge, and half on the other), at least your dimension will move to one or the other, but not randomly on the drawing.

How do you determine if a geometry element is the same before and after HLR? for vertexes, you compare X and Y coordinates in 2D space. If they are the same, +/- epsilon (since I assume they're floating point numbers), then the vertexes are the same. For lines and faces, you could argue that if they have the same exact vertexes (using the definition of identity for vertexes presented before), they could be considered equal too.

Does this have any merit?