Topological naming problem and TechDraw

[aapo]

Does this have any merit?

For vertices, this would work. For edges and other more complicated entities it does not work, because edge endpoints are not necessarily the same before and after HLR. This is kind of the idea of the HLR, that you sometimes get truncated edges, because some other geometry is hiding some part of the particular edge or face on a given view direction. However, for vertices one can correctly assume that they are either completely visible or completely hidden.

[ToniTen]

For vertices, this would work. For edges and other more complicated entities it does not work, because edge endpoints are not necessarily the same before and after HLR. This is kind of the idea of the HLR, that you sometimes get truncated edges, because some other geometry is hiding some part of the particular edge or face on a given view direction. However, for vertices one can correctly assume that they are either completely visible or completely hidden.

True, I had not considered that some edges might not have visible endpoints. I guess checking that the after HLR edge overlaps exactly some parts of pre HLR edges to grab their toponames could be an option, but that could become computationally expensive rather fast. Then again, any fix will be more computationally expensive than the current situation, with the added advantage of being more robust. I can't gauge how much the increase in robustness would cost in terms of performance and memory use.

As for faces, I guess it's not needed, since I can't think of any cases where TechDraw objects reference faces directly.

[wandererfan]

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.

In order to have a map from shadow geometric entities back to the source 3d geometry, you would have to project each 3d entity individually. Then you would have to look through the edges delivered by HLR and try to match them to the projected edges. That's n projections plus n x m edge comparisons on top of the current processing. So we would be making a slow process slower.

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.

Remember that HLR does not produce faces or vertices, but only edges. We have code that tries to build faces from the pile of edges (EdgeWalker.cpp).
Sometime this doesn't work and we have no faces on the drawing.
Also remember that the edges that come out of HLR are not identical to the input edges as they may be trimmed by an occluding face.

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.

Comparing 2 vertices is straight forward. Comparing 2 curves, no so much. A circular arc and a bspline could both have the same end points.

A simple before and after dimension end point comparison could be used to guess if a dimension is still valid. The difficulty is in determining if the new values accurately reflect a changed model or are the result of scrambled names.

[wandererfan]

As for faces, I guess it's not needed, since I can't think of any cases where TechDraw objects reference faces directly.

Off the top of my head, hatching and centerlines

[ToniTen]

Thanks for your quick reply. I see that my lack of knowledge of the internals has tripped me yet again.

In order to have a map from shadow geometric entities back to the source 3d geometry, you would have to project each 3d entity individually. Then you would have to look through the edges delivered by HLR and try to match them to the projected edges. That's n projections plus n x m edge comparisons on top of the current processing. So we would be making a slow process slower.

I realize this. Specially when dealing with geometry from imported STEP files, the process can be painfully slow. The result is often of excellent quality, BUT making it slower doesn't look promising. Specially when each modification to the 3d geometry causes everything to be re-projected again (I know you can set keep updated false to avoid this).

Remember that HLR does not produce faces or vertices, but only edges. We have code that tries to build faces from the pile of edges (EdgeWalker.cpp).
Sometime this doesn't work and we have no faces on the drawing.
Also remember that the edges that come out of HLR are not identical to the input edges as they may be trimmed by an occluding face.

Extracting endpoints from the pile of edges to generate the new vertices doesn't seem overly costly. Problem is, of course, with things like closed curves (circles, ellipses, etc), where you might end up with different "endpoints" while keeping the same geometry. Still, another step that will cause slowdown, but probably something acceptable.

Comparing 2 vertices is straight forward. Comparing 2 curves, no so much. A circular arc and a bspline could both have the same end points.

A simple before and after dimension end point comparison could be used to guess if a dimension is still valid. The difficulty is in determining if the new values accurately reflect a changed model or are the result of scrambled names.

Yeah, comparing two curves would be extremely tricky, but the point would be to at least provide a best effort "fix". If a circle arc and a bspline overlap completely, and have the same end points, at least the dimension would not move that far right?

I assume this wasn't something that was easy to fix, or it would have been fixed already. I'm just trying to see if I can help in some way to make it better. I guess I should really just leave this to the ones that really understand the internals.

[-alex-]

IMO the strategy is to workaround totaly OCC elements by using coordinates of constraint's points in sketcher, in order to import some clones of said constraints in related TD views. This way you shortcut both TNP and HLR instabilité, you shortcut OCC at 100% from sketches to TD views.
Ok you can not dimension a TD view at 100% with this methode, however you can get 80% of the dimensionning. Then remains 20% to dimension with standard TD constraints tools.
That's what I talk about here https://forum.freecadweb.org/viewtopic.php?f=35&t=44786

[wandererfan]

guess I should really just leave this to the ones that really understand the internals.

Please keep making suggestions. They make people think, and who knows, maybe your suggestion could spark a solution.

[wandererfan]

IMO the strategy is to workaround totaly OCC elements by using coordinates of constraint's points in sketcher, in order to import some clones of said constraints in related TD views. This way you shortcut both TNP and HLR instabilité, you shortcut OCC at 100% from sketches to TD views.
Ok you can not dimension a TD view at 100% with this methode, however you can get 80% of the dimensionning. Then remains 20% to dimension with standard TD constraints tools.
That's what I talk about here https://forum.freecadweb.org/viewtopic.php?f=35&t=44786

This is a bit like the intent of Landmark Dimension - base the measurement on known, fixed points.

[-alex-]

This is a bit like the intent of Landmark Dimension - base the measurement on known, fixed points.

yes it is, but without doing the job twice, then with no cluttering of tree view.
Lets continue this discussion here if you want.

[user1234]

Hello!

I like TechDraw and i am an often CAD (and very often FreeCAD) user, but let me play devil's advocate and let me make a suggestion.

In the python2 times, there was an external WB called GDT, see https://github.com/juanvanyo/FreeCAD-GDT. All references all set in 3D, but also worked in planes in 3D, so you can deviate them in 2D.
So you can add dimensions, auxiliary lines, axis of symmetry, GD&Ts, text -, welding -, surface -, treatmentinformation direct in 3D. Maybe this is a way to handle this? Because there are some pros (also cons).

pros:

- there is a ISO 3D drawing norm called jt, see https://en.wikipedia.org/wiki/JT_(visualization_format). I have seen then not much in the industries, but when it was pretty nice. Also one founder who left FreeCAD, jriegel, seemed to want implement this, see https://github.com/jriegel/FreeCAD/tree/dev-occ-jt. So it fits a norm and can be used valid (and maybe even better then classic 2Ds).

- sections are (not only in FreeCAD TechDraw) hard to handle. Also i work much on turbomachines. Also in commercial programs the sections for that are often a pita. Section in 3D are much more easier to handle. uwestoehr worked some times ago on a 3D section element, see https://forum.freecad.or/viewtopic.php?t=52441. So a 3D section element fits well in such a kind of implementation.

- on big parts details are much easier to illustrate in 3D.

- reference objects are the to annotate objects, so no diversion (also if the TNP issue is solved in 3D, it is also solved in this case).


cons:

- 3D drawings are not widespread today (just said: if someone say "paper drawings need no electricity" then it is OK, but without you can not produce parts either, but it is valid that not very workshop have tablets for every worker).

- uncommon, need a little bit thinking around a corner and maybe not favored from people, that use CAD not often and just want a sheet of paper

- a litle bit extra work to deviate the 3D elements to 2D.


Is this a valid suggestion?

Greetings
user1234