-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notes from the TopoNaming Project team #92
Comments
Overview of the workMost of the work is contained within the Part module. Code from the RT branch is not just transferred, but modernized by updating the method names, cleaning up parameter definitions, removing legacy code, and using available c++ techniques. The primary method name change is from Other concerns being addressed are any linter errors, in particular refactoring methods with high cognitive complexity. Also removal of single character variables, which can get I nt ense (bad dad joke to see if anyone is reading). We also want to absolutely minimize the use of preprocessor features when possible. PR TechniqueIn order to maintain credit where deserved we're using a pattern for any transferred code: the first commit contains the code taken from the RT branch, with any simple changes like renaming the method applied. This PR is committed with An ideal PR contains a first commit with the RT code, and a second commit that resolves any remaining compile errors, completes all renames, reformats the code as needed, updates any code using legacy techniques, and add tests. That results in a minimal final commit log. Individual commits should be prefixed with "Toponaming/Part: " as well as the overall PR so that the single line git logs are easy to read and understand. PerformanceWe know by definition that when enabled this code will be slower than the existing code. As Chennes pointed out "we're doing more work, it's going to be slower". With that said, we believe that the effective use of cacheing and other performance improvements along the way should result in an acceptable result. The Realthunder fork is not unreasonable in its performance. However, it would be useful to quantify how much slower it is, what types of files / operations trigger slowness, and where to look for optimizations. There is a proposal from Bgbsww to do this by providing a script that can download selected documents from the FreeCAD-library and run FreeCAD recomputes on them with measured performance. Perhaps even with profiling. There is also a thread with other potential example files. Shape history/ancestry/infoThe toponaming algorithm depends on keeping track of the history of how a shape was created, and using that history to form the internal name of the shape. The information required to create this history is available from OCCT, although it does not track it. OCCT thinks that a shape is Generated if you create it from another shape and it has a higher dimensionality. E.G. a MakeFace from a Wire, for example, or Vertex -> Edge, Edge -> Face, Wire -> Shell, Face -> Solid, Shell(s) -> Compound. OCCT sees a shape as Modified if you transform or translate it, so moves, rotates, etc. The dimensionality remains the same, but the shape is located somewhere else. Initial TestsThe googletest "gtest" framework located at The key difference in a Attempting an operation ( compound, boolean, etc ) against There is a GotchasSome of the The other Sometimes the github builds ( particularly the MacOSX one ) fail with timeouts on perfectly good code. Check the fail logs, and you can request a rebuild from any maintainer. For self service, kickstart a new build with a trivial commit. Most likely irrelevant by the time this is read: if you're working with a version of OCCT ahead of what the official builds use ( 7.8.0 ) as of this writing, be sure to test any failing builds against an official build version. Particularly when splitting off a new source file, but in general, it is critical to check the Hintsgtests can be run with One notable issue is that using the We're using There is a TEST_WRITING_TUTORIAL.cpp file in draft that when submitted gives help on how the API works and how to write tests for it. The earliest version of OCCT that still needs supporting is 7.6.3. Code ( often in an #ifdef ) from before that version can be discarded. Changed Stuff
Future issues to address
Temporary things during the transfer processThe TNP branch code has a series of |
Great work @bgbsww! I'll contribute with my discoveries/modifications. By now I think we can add: Changed Stuff
Obviously there'll be other points that will be added as long as the project continues |
This issue is to capture knowledge and notes as the topological naming problem fixes are transferred from the Real Thunder branch to the main one.
Markdown format is preferred for convenience in a future collation of this information, but not required.
We are preserving author credit by waiting to merge comments. Each author is welcome to keep editing their comment, or use multiple comments as they see fit.
The text was updated successfully, but these errors were encountered: